企业服务总线 系统集成的核心平台 Nov, 2008

内容 什么是企业服务总线 IBM的企业服务总线 如何进行系统集成 实例参考

关键概念 SOA通过明确的定义和松散藕荷来提升系统间的弹性: Service：服务 Service 交互 Service 编排 任何事情都可以是一个服务, 一个实现了唯一功能的自包容的实体 Service 交互 外部用户调用服务 服务可以彼此交互，调用操作和交换数据 Service交互可以是间接的 Service 编排 通过调用服务, 可以编排实现业务流程 Service 发现 一个注册的服务可以在构建时或者运行时被发现 Service Requestor Discovery Agency Find Publish Interact Client Provider Description Registry Of all of these dynamic Service Discovery at runtime is probably least used at the moment

Enterprise Service Bus Service Interaction Enterprise Service Bus Service Client 企业服务总线(ESB)概念经常用来表示服务互相交互的机制，它提供 了通信的基础架构 企业服务总线应当提供: 一致的、位置透明的、协议独立的手段来实现交互 一致的、位置透明的交互意味服务消费者和提供者之间可以是间接的 无论何种通信服务，应提供端到端的连通保证

解决的问题 先进构架 面向服务体系架构 SOA 过渡架构 企业应用整合 传统架构 基于消息传递的模式 Flexibility 通过企业服务总线实现服务的整合集中和流程实现 借助标准的接口灵活地连接，实现真正的随需应变 通过HUB模式实现应用之间的整合 很容易管理大量的连接和系统 The desire to make IT more flexible is not new. Indeed, it is as old as the IT industry itself. Each of these integration techniques has its place and is appropriate for handling certain situations. SOA blends the best of all these concepts into one new architecture. But it’s important to recognize that SOA is not the end of the road either, It’s the next step in the evolution of flexible infrastructures. 应用之间点对点的连接 实现简单、基本的信息交互和数据传递 Flexibility

SOA – ESB:Enterprise Service Bus 企业服务总线

企业服务总线（ESB）是用于集成应用和服务的灵活的连接基础设施。 形状 = 传输协议 颜色 = 数据格式 ESB在请求方与服务之间发挥以下作用： 切换 不同的传统协议之间进行切换 匹配和路由 　服务间的通信 转换 不同的数据格式之间进行转换 识别和分配 商业事件

内容 什么是企业服务总线 IBM的企业服务总线 如何进行系统集成 实例参考

IBM ESBs WebSphere MQ 稳定易用的数据传输解决方案: WebSphere MQ 为用户和应用开发人员提供了一种直接，简单的手段以实现应用系统在不同操作系统平台之间稳定可靠地传递，交换重要的数据和信息，确保消息不丢失/不复传。 1、WebSphere Enterprise Service Bus – 入门级企业服务总线解决方案: 针对中小企业的入门级ESB产品，能够帮助简化IT架构，降低运作成本，提升业务灵活性和市场响应速度，最终提升企业的竞争优势。 2、WebSphere Message Broker - 业界最强的企业服务总线: WMB通过提供对多种平台、语言、协议和传输方式的支持，帮助客户迅速部署企业服务总线，整合遗留应用，构建SOA架构的信息传输龙骨。 3、WebSphere DataPower XI50 – 快速/高效/便捷/安全地构建信息整合与XML高速处理的企业服务总线: 特别推出的IBM专属硬件ESB产品，通过内嵌强大的XML/WebService加速引擎及安全保障机制，帮助客户快速、高效、便捷、安全地构建面向大交易量任务关键（Mission Critical）型企业服务总线。

IBM ESB 产品组合根据您的需求提供各种选择 企业服务总线 WebSphere Message Broker 异构 IT 环境中的通用连接和转换 WebSphere DataPower Integration Appliance XI50 专用硬件 ESB 简化了部署并加强了安全性 WebSphere ESB 构建在 WebSphere Application Server 的基础上

Enterprise Service Bus ADVANCED Enterprise Service Bus 两种关键需求决定了两种不同的ESB解决方案 If all your applications conform to the Web Services standards… If not all your applications conform to the Web Services standards… 1 2 Travel Reservation Process Check Traveler Service Travel Reservation Process Check Traveler Application Check Credit Service Book Flight Service Check Credit Application Book Flight Application Enterprise Service Bus ADVANCED Enterprise Service Bus If all your applications conform to the Web Services standards, you may only need an ESB focused on the integration of these standards-based interfaces. However, if not all your applications conform to the SOA standards, you may need something more advanced that can mediate between the SOA standards and everything else. Hotel Availability Service Flight Availability Service Book Hotel Service Book Car Service Hotel Availability Service Flight Availability Application Book Hotel Application Book Car Application …then all you may require is an ESB focused on standards-based service integration. …then you may require a more advanced ESB focused on the integration of services with existing non-services assets.

Platform-Specific ESB WebSphere Message Broker 1212 WESB,WMB and DataPower Platform-Specific ESB Appliance ESB Universal ESB WebSphere ESB WebSphere Message Broker WebSphere DataPower Speed Fast Faster Fastest Built on WebSphere Application Server Wide Range of Platforms Rack-Mountable Appliance Web Services (SOAP/HTTP) Transport Switching & Database Support Adapters for Enterprise Applications This chart graphically shows two of the ESB offerings available for z, WS ESB, built on WAS, and WS Message Broker, which leverages WS MQ capabilities. As you can see, WS Message Broker is more appropriate if you have an extensive heterogeneous infrastructure, which we believe many of our customers attending these roadshows will have. When do I use WebSphere ESB, WebSphere Message Broker or WebSphere DataPower? When to Use WebSphere ESB? You use WebSphere Application Server and/or your team has skills with WAS Administration and Java coding You are now or planning on developing business process using WebSphere Process Server (WebSphere ESB and WPS have common tooling, programming model, and runtime) You are integrating with ISV business applications hosted on WAS or 3rd party solutions which extend and support WAS You are focused on standards based interactions using XML, SOAP, and WS You want to mediate between Web services and existing systems using JMS and WebSphere JCA Adapters Reliability and extensive transactional support are key requirements You want to minimize your server investment by co-hosting WebSphere services and ESB in one application server When to Use WebSphere Message Broker? You are currently using WebSphere Message Broker but not as an ESB You have extensive heterogeneous infrastructures, including both standard and non-standards-based applications, protocols, and data formats You have extensive MQ skills and infrastructure You are using Industry formats such as SWIFT, EDI, HL7 You are implementing a wide range of messaging and integration patterns Complex event processing, message splitting and aggregation You need extensive pre-built mediation support You have very complex transformation needs To achieve very high-performance with horizontal and vertical scaling When To Use WebSphere DataPower? Ease of use is a pre-dominant consideration Simple experience of drop-in installation and admin-based configuration with no or minimal development required You are transforming between XML-and-XML or XML-and-any other format Your interaction patterns are relatively simple Your mediation requirements are met by the existing DP mediations and minimal extensibility is needed You are using XML-based or WS-Security extensively You require use of advanced Web services standards You need to minimize message latency when adding an ESB layer You are doing extensive XML processing combined with high performance requirements Your ESB must be in production very quickly XML Data Format Non-XML Data Formats Complex Event Processing Content-Based Publish/Subscribe Mobile and Telemetry Devices Multicast Third Party Messaging Systems

内容 什么是企业服务总线 IBM的企业服务总线 如何进行系统集成 实例参考

提供应用到应用的连接可能很复杂 系统平台 编程模型 编程语言 传输协议 标准和消息格式 错误恢复与事务完整性 异步消息传递 同步 RPC Intel pSeries iSeries Sun HP zSeries 移动设备 异步消息传递 同步 RPC 发布/ 订阅 RPG ACORD - The insurance industry nonprofit association dedicated to improving the way insurance companies do business through the use of technology. HIPAA - The Health Insurance Portability and Accountability Act ebXML - Electronic Business using eXtensible Markup Language, commonly known as e-business XML FIX - The Financial Information eXchange ("FIX") Protocol is a series of messaging specifications for the electronic communication of trade-related messages. It has been developed through the collaboration of banks, broker-dealers, exchanges, industry utilities and associations, institutional investors, and information technology providers from around the world. AL3 - the ACORD Automation Level 3 (known as AL3), which focuses on the communication between property & casualty insurers, their agents and other trading partners. EDI-FACT - is a formal language for machine readable description of electronic business documents. SWIFT - Society for Worldwide Interbank Financial Telecommunication supplies secure messaging services and interface software to wholesale financial entities. EDI-X12 - the American National Standards Institute (ANSI) chartered the Accredited Standards Committee (ASC) X12 to develop uniform standards for interindustry electronic exchange of business transactions-electronic data interchange (EDI). HL7 - Health Level Seven (HL7), is an all-volunteer, not-for-profit organization involved in development of international healthcare standards. Web Services WebSphere MQ JMS FTP TCP/IP HTTP SMTP Multicast SWIFT ACORD HIPAA EDI-X.12 ebXML COBOL Copybook Word/Excel/PDF Custom Formats XML FIX AL3 EDI-FACT HL77

点对点连接的维护成本可能很高 应用支付 支付系统 服务之间彼此紧密相连 一处更改需要更改多处 网上银行 SWIFT 现金管理 工资 自动 1515 点对点连接的维护成本可能很高 应用支付 支付系统 网上银行 SWIFT 现金管理 工资 自动 清算中心 顾客账户 单一 欧元支付区 (SEPA) 财政部 The red delta is a disruptive change. This shows how a company would transfer funds to another company-They don’t write a check. Example: SEPA requests a field specification change from 4 bytes to 6 bytes, this would have to be propagated to each of the applications that communicate with it. This isn’t necessarily SOF. Could be Retail or Dist or Finance. This is still at a high level. The senders and the receivers have to understand each other’s formats and transaction protocols. 消息格式更改 美联储 (Fedwire) 公司支付 服务之间彼此紧密相连 一处更改需要更改多处

企业服务总线提供集中调解服务，可减少成本 1616 企业服务总线提供集中调解服务，可减少成本 应用支付 支付系统 工资 现金管理 网上银行 SWIFT 自动 清算中心 企业服务总线 调解服务 基于 内容的路由 数据转化 传输切换 数据放大 复杂 事件处理 You just change the field mapping in the ESB, not in the original application. 顾客账户 财政部 公司支付 美联储 (Fedwire) 单一欧元支付区 (SEPA) 消息格式 更改 一处更改只需要更改 ESB 调解服务的一处 可以独立地创建和维护服务

调解服务：基于内容的路由 示例：基于支付量的支付路径 高价值 接收方 基于 内容的路由 发送方 低价值 > 100 < 100 企业服务总线 > 100 XML <amount> 274.25 </amount> < 100 发送方 高价值 接收方 低价值 56.83 基于 内容的路由 This is point to point. ESB determines which ONE receiver will get it. MQ couldn’t do it - it only cares about sending messages to the destinations it's been told to, so the 发送应用 would have to have the decision logic built into it, whether to send to one queue for high value receiver or a different queue for low value receiver. WS MB lets you extract that logic out of the application and put it "in the network", or in the ESB. In that way the sending app only deals with its business logic, preparing and sending one message without having to think about the details of who is going to get it. In addition, if something changes, such as the split point between "high" and "low", you just change it in the MB and the sending app doesn't know or care.

调解服务：数据转化 示例：将 XML 转化成二进制格式 接收方 发送方 数据转化 其他常见转化 二进制格式 XML 格式 企业服务总线 <amount> 56.83 </amount> 接收方 二进制格式 Binary 0100110 数据转化 FIX and SWIFT are Finance Industry protocols. 其他常见转化 一种 XML 模式向另一种 XML 格式转化 特定于行业的转化（例如，FIX 向 SWIFT 转化）

调解服务：传输切换 示例：从 SOAP/HTTP 切换到 JMS 消息 接收方 发送方 传输切换 JMS 应用 Web 服务 企业服务总线 XML <amount> 56.83 </amount> SOAP 信封 SOAP/HTTP 点到点或 发布/订阅 JMS Message Binary 5683 传输切换 企业服务总线 .

调解服务： 数据放大 示例：添加外部数据库的顾客信息 发送方 接收方 数据放大 查询地址 客户 和电话号码 数据库 企业服务总线 名称 账户 name account address phone 数据放大 查询地址 和电话号码 企业服务总线 Add customer information from another data source, in this case, a customer database that contains address and phone numbers.

复杂事件处理 示例：欺诈检测和警告 接收方 复杂 事件处理 发送方 异常 其他示例 企业服务总线 执行常规限制 周期性地报告累计支付 异常路由 同一天同 同一个发票号 支付两笔以上 普通路由 继续跟踪以往的支付 接收方 异常 复杂 事件处理 企业服务总线 Example-there are more examples below, not just fraud detection. The payment demo includes this. Routing, transformation, and complex event demo. So if the demo is cut off before you get to this function, you can hide this slide. If you don’t, you can’t hide this slide. Demo does this one, but don’t have to show it if crunched for time. 其他示例 执行常规限制 周期性地报告累计支付 服务水平协议监控和通知

事务流调解服务 示例：多个数据库和消息传递操作 发送方 接收方 所有更新要么提交，要么在一个事务中一起回滚 企业服务总线 准备提交 如果接收方发生故障则回滚事务 日志 数据库 支付 账户 记录支付 账户消息 更新 支付数据库 企业服务总线 所有更新要么提交，要么在一个事务中一起回滚

将调解服务组合到一起，以满足连接需求 以任何顺序组合调解服务 构建调解流以连接服务 数据转化 传输切换 基于 数据放大 内容的路由 企业服务总线 This puts it all together. This entire tube is a message flow. Within this message flow there are 6 nodes in this message flow. What if after we did the data transformation, and before we went out on the transport switch, we needed to do some additional manipulation/programming logic. We do that via a “Compute Node”-Another node in addition to these 6 nodes. They can be executed using either Java or ESQL programming logic. So if it is in Java, it could be offloaded to zAAP.

应用场景-举例 WebSphere Message Broker 网上银行支付根据数量的不同路由到不同的支付系统 2424 应用场景-举例 SOAP/HTTP JMS MQ 普通 事件检测 支付 > 100 < 100 IFX 转化为 SWIFT 转化为 ACH WebSphere Message Broker 记录传入支付消息 原始消息 （IFX 格式） SWIFT ACH 复杂事件处理 基于内容的路由 客户服务警告 网上银行 WebSphere Web 服务 客户端 This demo should take approx. 3 minutes. The bullets explain the flow of the demo. It may be a customer mistake-why would they pay three times on the same invoice. They may be paying the same amount 3 times, like triple paying the same amount. Msg Broker and MQ could run on z-in middle. Upper left Web Banking is a Visual Basic client. All the applications on the right are VB applications. We would need to run WMB and the queues on z, then have a simple VMWare clients for the 3 on the right hand side, as long as they have VB. WebBanking on the left could be running on VMWare or z. Web Service client is being exposed on z. SWIFT and ACH have their own formats/layouts. Think of it as an EDI type of transaction. . 网上银行支付根据数量的不同路由到不同的支付系统 使用 WebSphere TX 地图从 IFX 转化为 SWIFT 和 ACH 格式 同一天对同一个发票号支付 3 次即生成客户服务警告 对于 Web 服务客户，处理支付的方式完全相同

WebSphere platform messaging IBM 企业服务总线可连接所有内容 设备 遥感设备 移动设备 数据格式 XML COBOL Copybook SWIFT Custom Binary HL7 EDIFACT X12 C Header IDoc MIME ACORD HIPAA TLOG 消息传递系统 WebSphere MQ WebSphere platform messaging TIBCO EMS TIBCO Rendezvous Sonic MQ Any JMS 数据库 SQL Server Oracle Sybase DB2 文件系统 IBM 企业服务总线 平台 z/OS AIX Linux Appliance IBM ESB offerings can handle almost all of your connectivity backbone issues. We can handle almost all data formats, message formats, protocols, etc. And we have different solutions depending on your requirements. Why do we say “almost.” This can be a rapidly evolving field-hard to guarantee 100% coverage. Do I need WebSphere MQ if I have WebSphere Message Broker? WebSphere Message Broker and WebSphere MQ address different business needs. WebSphere MQ provides secure and reliable connectivity between application and systems, supported on more than 80 platform configurations. This provides the ability to move data unchanged between virtually all business environments likely to be deployed in a business infrastructure. WebSphere Message Broker is used as a transport for moving data between applications, but it is capable of performing additional tasks through understanding of data formats, allowing it to provide intelligent routing and transformation of XML data formats. Businesses will still see a need for WebSphere MQ to connect up the multiple different environments that make up the typical IT infrastructure deployed around an enterprise, but are likely to see a need for an ESB to add value in environments where it can act on the structured data being exchanged between standards-based applications. 企业应用 Ariba JD Edwards i2 Oracle PeopleSoft SAP Siebel SunGard WebSphere Adapters Solaris HP/UX Windows 协议 SOAP HTTP FTP TCP/IP Sockets LDAP SMTP 广播 一个消息副本 同时交付给 多个订阅人

内容 什么是企业服务总线 IBM的企业服务总线 如何进行系统集成 实例参考

银行综合前置IBM ESB解决方案 服务系统 ESB 服务总线平台 服务系统 应用 服务 中介 服务 ESB业务接入 基础 服务 Call Center 短信平台 前置系统 终端服务器 中间业务 网银系统 ESB 服务总线平台 应用 服务 服务数据字典 服务授权控制 组合服务实现 服务冲正处理 适配器框架 中介 服务 应用服务处理 服务信息路由 传输协议转换 消息格式转换 业务事件响应 ESB业务接入 基础 服务 ESB数据传输 ESB应用开发维护 服务系统 存贷款核心系统 影像系统 信贷系统 大小额系统 银联中心

ESB解决方案 - 架构概要图 我们来看一下ESB解决方案的架构概要图。 这里给出的是一个银行企业的比较完整的架构图，从中我们可以看到企业服务总线系统在其中所处的位置。图中从做至右我们将一个银行的IT系统分为如下几层： 最终用户层，包括：柜面终端、网银浏览器、电话等。 服务请求系统层，主要包括内部系统的前置系统，如柜面前置、ATM前置、中间业务平台、网络银行等；以及外部系统的前置系统，如银联前置、支付前置等。 无论是内部系统的前置还是外部系统的前置，都可以通过多渠道整合平台整合后，统一的接入企业服务总线层。当然，如果尚未建立好完备的渠道整合系统，则各个系统可以通过开发独立的适配器接入企业服务总线。 服务网关的作用是完成整合请求与非整合请求的分流。 在企业应用整合层，核心的系统是企业服务总线层，以及各个系统接入的适配器。 企业服务总线系统完成服务组件的封装注册、服务执行的路由、服务状态控制等功能，也完成必要的报文协议转换功能。 适配器完成了原始系统的无缝接入，主要完成原始系统及ESB系统之间的报文及通讯协议转换。适配器并非必须的部件，用户也可以对现有的系统进行变更，使其能够来自于ESB系统的请求，这样适配器就不再需要了。 在服务提供系统层，包括了银行的核心业务系统，信贷系统、卡系统等，也包括第三方的外部系统前置，如，支付系统、银联系统。 值得一提的是，有些系统既做服务请求系统，又作服务提供系统，如，支付系统前置。 ESB系统并不单纯的提供面向前端请求的整合，也提供面向后端的服务系统之间的整合。

SOA ESB解决方案 - 核心功能实现 业务流程编排 服务组件封装 服务执行控制 数据协议转换 对现有系统的服务进行封装，使之能够被重用。 可基于被封装了的原始服务组件再次进行编排封装，使之实现复杂的业务流程。 服务执行控制 对服务的执行状态进行审核、控制、切换。 数据协议转换 对接入的系统实现统一的报文格式、通讯协议转换。 业务流程编排 服务组件封装 SOA 服务执行控制 数据协议转换 我们在ESB解决方案中提供了如下的核心功能： 首先是服务组件的封装。我们提供了一整套的数据规范来帮助用户对现有的服务进行封装。封装后的服务组件注册于服务仓储库中，供服务请求系统使用。 其次，可以对已经封装后的服务组件进行编排后再次封装，形成复合服务组件，实现复杂的业务流程。 再有，在服务执行的过程中，完成对服务的路由控制、步骤切换，以及状态审核处理等功能。 数据协议转换，我们提供了标准的适配器框架来帮助用户快速完成对报文格式、通讯协议的转换。另外，我们在ESB核心也完成了复合服务的报文分拆、合并的功能。

ESB解决方案 – 适配器框架 封装了典型的Adapter功能: 提供MQ接入功能 提供Socket等多种接入功能 提供完成报文格式转换的接口 提供多线程及线程池的管理接口 提供配置管理接口,用来配置参数信息 提供数据库信息访问接口 错误处理功能 提供日志记录功能 可以被方便的用来实现一个实际的Adapter: 前端Adapter 后端Adapter 封装了典型的Adapter功能: 提供MQ接入功能: 完成对ESB的接入功能, 也可用来接入其它的MQ系统. 提供Socket接入功能: 完成对使用Socket进行通讯的系统的接入. 可用来连接服务请求系统及服务响应系统. 提供完成报文格式转换的接口: 此接口将被用来实现ESB报文及原始服务系统之间的转换过程, 每个系统都有相对独立的报文格式, 因此此接口的实现逻辑也应有所不同, 用户需要自己去实现转换的逻辑. 提供多线程及线程池的管理功能: 对请求的接入可提供线程池管理功能,以提高并发处理效率. 提供配置管理接口,用来配置参数信息: 各个组件的功能接口都是可配置的. 比如,可对Socket接入IP及端口, 线程池的大小, JDBC连接配置等. 提供数据库信息访问接口: 在数据转换过程中，需要将交易的请求数据格式和响应数据格式存放到数据库中，适配器将从数据库中读取这些信息放入到缓存（Cache Manager）中。 错误处理功能: 错误异常处理接口（Error Handler）将错误代码直接打包到报文里面，并传送给ESB, 由EAI进一步处理（包括超时错误处理），适配器不对错误进行任何的逻辑处理与操作。 提供日志记录功能: 主要用于程序开发调试和错误跟踪，以及交易内容、适配器性能、守护类线程状态等的纪录，是一个基于文件的日志组件（Log）。 可以被方便的用来实现一个实际的Adapter: 前端Adapter: 接收来自服务请求系统的请求, 通过数据转换接口将请求报文转换为ESB格式. 然后发往ESB并同步接收响应抱文, 将响应抱文转换为服务请求系统格式, 并返回到服务请求系统. 后端Adapter: 接收来自于ESB系统的请求报文, 通过数据转换接口将请求报文转换为服务提供系统所需要的原始格式, 向服务提供系统发起请求并同步接收响应报文, 将响应报文转换为ESB格式, 并返回至ESB系统. 此框架对于上述两种Adapter的实现均能够很好的适用, 只需要在配置时指定是做哪种Adapter用即可.

ESB解决方案典型业务场景－ATM取款交易 客户 <<Business Actor>> <<Business Use Case>> ESB 银行核心系统 ATM前置系统 渠道整合系统 <<第一步>> <<第二步>> <<整合业务请求>> ATM 服务网关 <<Business Use Case>> 银行卡系统 让我们来看一下ESB解决方案所应用的一个典型的业务场景。 这是一个ATM取款的交易。服务请求系统为ATM前置系统，服务提供系统有两个，一个是银行核心业务系统，一个是银行卡系统。 这是一个复合服务请求，分为两个步骤，第一步，银行核心系统记帐，第二步，卡系统记帐。 服务发起后，经过渠道整合系统，判断为整合业务请求，转换为标准的ESB报文规范，发送至ESB系统。 ESB系统收到该请求，根据服务仓储库的定义，判断为复合服务，加载完整的服务控制信息，并组织第一步骤银行核心系统的请求报文，然后发送至银行核心系统处理。 银行核心系统处理完成后，将报文返回至ESB系统。ESB系统控制发起第二步骤至银行卡系统的请求。同时完成向银行卡系统的请求的报文格式转换及路由。 银行卡系统处理完成后，将第二步骤的结果返回至ESB。 此时ESB系统判断为服务执行成功完成。将两步骤的结果合并后返回至于服务请求系统。 前端ATM用户收到交易处理的结果。

跨业务系统的组合交易状态（整合前） 用户需要和三个相互独立的系统进行交互

跨业务系统的组合交易过程（整合前） 当用户要进行一个跨系统的复杂交易时

跨业务系统的组合交易过程（整合后） 用户只需要和企业服务总线进行一次交互

IBM ESB解决方案的优势 保护客户投资, 充分利用各种平台和环境, 减少对现有系统的改造 利用适配器连接各种应用系统 提供对传统应用的连接能力，如 CICS等. 优异的处理性能 在业界同类产品中的性能是无可比拟的，它内部用于数据处理的消息流 是以多线程方式工作的，同一个消息流还可以分配到不同的执行组，从 而提高整个系统的运行效率 完善的整合功能 消息格式转换及适配器, 不是一切皆Web Services 交易完整性保证 支持不同层次的交易完整性要求，例如：可以设定整个消息流为一个完整的交易，当某一环节发生错误时，整个消息流回滚，保证数据一致性 高可靠性和高扩展性 多节点：强大的Cluster功能 具有理解和管理各类系统的能力 支持统一的监控和管理框架：Common Event Infrastructure 具有广泛的成功案例和强大的实施支持团队

回顾 什么是企业服务总线 IBM的企业服务总线 如何进行系统集成 实例参考

请提问题！