SOA and ESB(WMB)

1、企业服务总线技术方案建议 目目 录录 第第 1 章章概述概述.1 1.1读者对象.1 1.2定义.1 第第 2 章章面向服务的体系架构简介面向服务的体系架构简介.2 2.1SOA 的业务驱动力.2 2.2什么是面向服务的体系架构.4 2.3面向服务的体系结构所带来的好处.5 2.4应用系统的的整合与 ESB.6 2.4.1企业应用整合与ESB .7 2.4.2ESB的要素.9 2.4.3ESB的功能.10 2.4.4ESB的实现模式.12 2.5应用系统整合的国内外现状.14 2.5.1项目案例.16 某国内著名通信公司方案概述.16 客户需求：.16 建设方案：.16 产品选择

2、：.17 2.5.2某较大型商业银行ESB项目简介.17 第第 3 章章关键技术分析关键技术分析.19 3.1与现有系统的集成.19 3.1.1与基于J2EE系统的集成.19 3.1.2与基于MQ系统的集成.20 3.1.3与基于CICS系统的集成.21 3.1.4与基于邮件系统的集成.22 3.1.5与基于C/S架够系统的集成.22 3.2平台扩展性与高可用性的实现.23 3.3平台安全性的考量.24 附录附录 A：产品技术文档和白皮书：产品技术文档和白皮书.26 A.1 WEBSPHERE MQ 产品简介 .26 什么是 WEBSPHERE MQ?.26 WEBSPHERE MQ 重要特点

3、：.28 其它特点.30 为什么要用 WEBSPHERE MQ 产品？.31 A.2 WEBSPHERE MESSAGE BROKER 产品简介(GU).33 WEBSPHERE MESSAGES BROKER 亮点和概括.34 WEBSPHERE MESSAGES BROKER 产品商业应用范围和功能.34 实时与您无处不及的企业共享信息.34 可靠、一致地管理业务事件.35 利用定制的信息流优化响应.35 集成无界限.36 图形化的开发环境加快部署速度.37 快速启动.37 利用市场领先的业务集成解决方案满足要求.37 MESSAGE BROKER 是一个战略性的开放框架.38 应用程序格

4、式转换和智能路由功能.38 企业服务总线技术方案建议 强大的数据处理功能.39 对各种应用系统的接口功能.39 WEBSPHERE MESSAGES BROKER 产品特点 .39 IBM WEBSPHERE MESSAGE BROKER解决方案的优势.41 产品构架优势.41 网状结构到星型结构的改变，大大简化 MQ 的配置和管理 .41 不同格式的数据转换.42 WMB 全面支持 XML.42 各种Processor Node组成的 Message Flow.42 与 Database 紧密集成.43 功能强大的发布预订系统.43 企业服务总线技术方案建议 - 1 - 第第 1 章章 概述

5、概述 1.1 读者对象读者对象 预期阅读人员包括负责科技管理的各级领导、负责科技管理的业务人员、 ESB 项目管理人员、ESB 平台实施人员、ESB 平台运维人员和其他需要阅读 本报告的项目经理、IT 架构师等。 1.2 定义定义 SOAService Oriented Architecture面向服务的架构 ESBEnerprise Service Bus 企业服务总线 WMBWebSphere Message BrokerIBM 高级 ESB 产品 企业服务总线技术方案建议 - 2 - 第第 2 章章 面向服务的体系架构简介面向服务的体系架构简介 目前，大多数企业都有各种各样的系统、应用程

6、序以及不同时期和技术的 体系结构。同时，网络的发展，使得跨机构和组织的应用系统越来越普遍。另 一方面，政策和业务方面的压力要求 IT 系统能够方便灵活地适应不断的变化。 如何集成来自多个厂商跨不同平台的产品和应用系统，以满足业务上灵活多变 的要求，一直是企业 IT 部门的主要挑战。面向服务的体系结构(Service Oriented Architecture, SOA)为解决这一问题提供了良好的途径。 2.1SOA 的业务驱动力的业务驱动力 虽然 IT 经理一直面临着削减成本和最大限度地利用现有技术的难题，但 是与此同时，他们还必须不断地努力，以期更好地服务客户，更快地响应企业 战略重点，从而

7、赢得更大的竞争力。 在所有这些压力之下，有两个基本的主题：异构和改变。现在，大多数企 业都有各种各样的系统、应用程序以及不同时期和技术的体系结构。集成来自 多个厂商跨不同平台的产品简直就像一场噩梦。但是我们也不能单单使用一家 厂商的产品，因为改变应用程序套件和支持基础设施是如此之难。 在当今 IT 经理面临的问题之中，改变是第二个主题。全球化和电子商务 加快了改变的步伐。全球化带来了激烈的竞争，产品周期缩短了，每个公司都 想赢得超过竞争对手的优势。在竞争产品和可以从 Internet 上获得的大量产品 信息的推动下，客户要求更快速地进行改变。因而，在改进产品和服务方面展 开的竞争进一步加剧了。

8、 为了满足客户提出的越来越多的新要求，技术方面的改进也在不断地加快。 企业必须快速地适应这种改变，否则就难以生存，更别提在这个动荡不安竞争 激烈的环境中取得成功了，而 IT 基础设施必须支持企业提高适应能力。 因此，企业组织正在从上世纪八十年代或更早的时期的相互隔离的垂直业 企业服务总线技术方案建议 - 3 - 务部门，到上世纪八十年代和九十年代关注业务流程的水平结构，向新的生态 系统业务范例发展。重点是扩展供应链，支持客户和合作伙伴访问业务服务。 下图展示了企业的这种发展。 我如何使我的 IT 环境更灵活且更快地响应不断改变的业务需求呢？ 我们 如何使这些异构系统和应用程序尽可能无缝地进行通

9、信呢？我们如何达到企业 目标而不使企业走向破产的深渊呢？ IT 响应者/支持者是随着企业的这种发展而并行发展的，如下图所示。现 在，许多 IT 经理和专业人员都同样相信，我们真的快找到了一种满意的答案 面向服务的体系结构。 为了减少异构性、互操作性和不断改变的要求的问题，这样的体系结构应 该提供平台来构建具有下列特征的应用程序服务： 松散耦合 位置透明 协议独立 基于这样的面向服务的体系结构，服务使用者甚至不必关心与之通信的特 定服务，因为底层基础设施或服务“总线”将代表使用者做出适当的选择。基础 设施对请求者隐藏了尽可能多的技术。特别地，来自不同实现技术（如 J2EE 或 .NET）的技术规

10、范不应该影响 SOA 用户。如果已经存在一个服务实现， 企业服务总线技术方案建议 - 4 - 我们就还应该重新考虑用一个“更好”的服务实现来代替，新的服务实现必须具 有更好的服务质量。 2.2什么是面向服务的体系架构什么是面向服务的体系架构 面向服务的体系结构是一个组件模型，它将应用程序的不同功能单元（称 为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立 的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。 这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。 这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服 务之间的松耦

11、合。松耦合系统的好处有两点，一点是它的灵活性，另一点是， 当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够 继续存在。而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功 能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更 改时，它们就显得非常脆弱。 对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加 灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、 合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业 务的性质。我们称能够灵活地适应环境变化的业务为随需应变的（On Demand）业务，在随需应变的业

12、务中，一旦需要，就可以快速地对完成或执 行任务的方式进行必要的更改。 值得注意的是，Web Services 并不是实现 SOA 的惟一方式。例如 CORBA 是另一种方式，同样，面向消息的中间件（Message-Oriented Middleware）系统（比如 IBM 的 MQ）也是一种选择。但是为了建立体系结 构模型，用户所需要的并不只是服务描述。用户需要定义整个应用程序如何在 服务之间执行其工作流。尤其需要找到业务的操作和业务中所使用的软件的操 作之间的转换点。因此，SOA 应该能够将业务的商业流程与它们的技术流程 联系起来，并且映射这两者之间的关系。例如，给供应商付款的操作是商业流

13、企业服务总线技术方案建议 - 5 - 程，而更新您的零件数据库，以包括进新供应的货物却是技术流程。因而，工 作流还可以在 SOA 的设计中扮演重要的角色。 此外，动态业务的工作流不仅可以包括部门之间的操作，甚至还可以包括 与不为您控制的外部合作伙伴进行的操作。因此，为了提高效率，您需要定义 应该如何得知服务之间的关系的策略，这种策略常常采用服务级协定和操作策 略的形式。 最后，所有这些都必须处于一个信任和可靠的环境之中，以同预期的一样 根据约定的条款来执行流程。因此，安全、信任和可靠的消息传递应该在任何 SOA 中都起着重要的作用。 2.3面向服务的体系结构所带来的好处面向服务的体系结构所带来

14、的好处 如前所述，企业正在处理两个问题：迅速地改变的能力和降低成本的要求。 为了保持竞争力，企业必须快速地适应内部因素（如兼并和重组）或外部因素 （如竞争能力和顾客要求） 。需要经济而灵活的 IT 基础设施来支持企业。 我们可以认识到，采用面向服务的体系结构将给我们带来几方面的好处， 有助于我们在今天这个动荡的商业环境中取得成功： 利用现有的资产利用现有的资产 SOA 提供了一个抽象层，通过这个抽象层，企业可以继续利用它在 IT 方 面的投资，方法是将这些现有的资产包装成提供企业功能的服务。组织可以继 续从现有的资源中获取价值，而不必重新从头开始构建。 更易于集成和管理复杂性更易于集成和管理复

15、杂性 在面向服务的体系结构中，集成点是规范而不是实现。这提供了实现透明 性，并将基础设施和实现发生的改变所带来的影响降到最低限度。通过提供针 对基于完全不同的系统构建的现有资源和资产的服务规范，集成变得更加易于 管理，因为复杂性是隔离的。当更多的企业一起协作提供价值链时，这会变得 更加重要。 更快的响应和上市速度更快的响应和上市速度 从现有的服务中组合新的服务的能力为需要灵活地响应苛刻的商业要求的 组织提供了独特的优势。通过利用现有的组件和服务，可以减少完成软件开发 企业服务总线技术方案建议 - 6 - 生命周期（包括收集需求、进行设计、开发和测试）所需的时间。这使得可以 快速地开发新的业务服

16、务，并允许组织迅速地对改变做出响应和减少上市准备 时间。 减少成本和增加重用减少成本和增加重用 通过以松散耦合的方式公开的业务服务，企业可以根据业务要求更轻松地 使用和组合服务。这意味资源副本的减少、以及重用和降低成本的可能性的增 加。 说到做到说到做到 通过 SOA，企业可以未雨绸缪，为未来做好充分的准备。SOA 业务流程 是由一系列业务服务组成的，可以更轻松地创建、修改和管理它来满足不同时 期的需要。 SOA 提供了灵活性和响应能力，这对于企业的生存和发展来说是至关重 要的。但是面向服务的体系结构决不是灵丹妙药，而迁移到 SOA 也并非一件 可以轻而易举就完成的事情。请别指望一个晚上就将整

17、个企业系统迁移到面向 服务的体系结构，我们推荐的方法是，在业务要求出现或露出苗头时迁移企业 功能的适当部分。 2.4应用系统的应用系统的的整合与的整合与 ESB ESB（Enterprise Service Bus，即企业服务总线）是传统中间件技术与 XML、Web 服务等技术结合的产物。ESB 提供了网络中最基本的连接中枢，是 构筑企业神经系统的必要元素。 企业服务总线 ESB 就是一种可以提供可靠的、有保证的消息技术的最新方 法。ESB 中间件产品利用的是 Web 服务标准和与公认的可靠消息 MOM 协议接 口(例如 IBM 的 WebSphere MQ)。ESB 产品的共有特性包括：连接

18、异构的 MOM、利用 Web 服务描述语言接口封装 MOM 协议，以及在 MOM 传输层上 传送简单对象应用协议(SOAP)传输流的能力。大多数 ESB 产品支持在分布式应 用之间通过中间层如集成代理实现直接对等沟通。 企业服务总线（Enterprise Service Bus，ESB）的概念是从面向服务体系架 构(Service -Oriented Architecture， SOA)发展而来的，与以服务为导向的应用架 企业服务总线技术方案建议 - 7 - 构体系（SOA）紧密连接在一起， 是 SOA 核心组成部分，是 SOA 架构中应用 整合的骨干。SOA 描述了一种 IT 基础设施的应用

19、集成模型，其中的软构件集 是以一种定义清晰的层次化结构相互耦合，其中，一个 ESB 是一个预先组装的 SOA 实现，它包含了实现 SOA 分层目标所必需的基础功能部件。在 SOA 架构 上发布的业务服务是 ESB 的“用户” ，这些基于 SOA 架构的业务系统所开放出 来的服务通过 ESB 进行交互。它们的交互请求被以事件的方式进行发布和订阅。 2.4.1企业应用整合与企业应用整合与 ESB 企业应用整合(EAI)的概念在 IT 界提出和讨论已经有几年的历史了，最初 大家谈到的 EAI 的概念，相对后来 EAI 的发展来看，可以说是一个狭义上的 EAI，正如其字面上的含义Enterprise

20、Application Integration，即企业应用整合， 仅指企业内部不同应用系统之间的互连，以期通过应用整合实现数据在多个系 统之间的同步和共享。 伴随着 EAI 技术的不断发展，它所被赋予的内涵变得越来越丰富。现在大 家谈到的 EAI 的概念，具有更为广义的内涵，它已经被扩展到业务整合 (Business Integration)的范畴，业务整合相对 EAI 来说是一个更宽泛的概念，它 将应用整合进一步拓展到业务流程整合的级别。业务整合不仅要提供底层应用 支撑系统之间的互连，同时要实现存在于企业内部应用与应用之间，本企业和 其他合作伙伴之间的端到端的业务流程的管理，它包括应用整合，

21、B2B 整合， 自动化业务流程管理，人工流程管理，企业门户以及对所有应用系统和流程的 管理和监控等方方面面。 EAI 的目标是支持对现有 IT 系统的重新利用，通过 EAI 技术能够将不同的 软件和系统串联起来，延长这些应用系统的生命周期。传统的 EAI，往往使用 如 CORBA 和 COM 等的消息中间件进行分布式，跨平台的程序交互，修改企 业资源规划以达到新的目标，使用中间件、XML 等方法来进行数据分配。因此， 实际上传统的 EAI 是部件级的重用。很不幸的是，基于部件的架构没有统一的 标准，因此，各个厂商都有各自不同的 EAI 解决方案，你会看到各种各样的中 间件平台。如果 EAI 碰

22、到了异构的 IT 环境，就必须分别考虑怎样在各个不同 企业服务总线技术方案建议 - 8 - 的中间件之间周旋，来实现合理的互联方式，你不得不考虑各种复杂的可能性。 因此，你所见过的大多数传统 EAI 解决方案都比较笨重。 如果我们选择传统的 Hub 模式来构建 SOA 基础架构，从纯粹逻辑的角度， 可能会出现哪些问题呢？首先，整个 SOA 架构的性能，如果每个服务的请求都 经过中央 Hub 的中转，那么 Hub 的负担会很重，速度会随着参与者的增多而愈 来愈慢；其次，这样的系统会很脆弱，一旦 Hub 出错，整个 SOA 架构都会瘫 痪；最后，这样的架构会破坏 SOA 的开放性原则，参与者运行在

23、一个相对封闭 的环境中，扩展起来十分麻烦。因此，这也不是理想的 SOA 架构。 ESB 为基础的架构与前面的 Hub 结构有什么不同呢？首先，它比单一 Hub 的形式更开放，总线结构有无限扩展的可能；其次，真正体现了 SOA 的理念， 一切皆为服务，服务在总线(BUS)中处于平等的地位。即使我们需要一些 Hub， 那么它们也是以某种服务的形式部署在总线上，相比上面的结构要灵活的多。 这就是 ESB，我们需要给它一个明确的定义：ESB 是一种在松散耦合的服务和 应用之间标准的集成方式。它可以作用于： 面向服务的架构 -分布式的应用由可重用的服务组成 面向消息的架构 - 应用之间通过 ESB 发送

24、和接受消息 事件驱动的架构 - 应用之间异步地产生和接收消息 用一句较通俗的话来描述它：ESB 就是在 SOA 架构中实现服务间智能化集 成与管理的中介。而它与 SOA 的关系要相对好理解一些：ESB 是逻辑上与 SOA 所遵循的基本原则保持一致的服务集成基础架构，它提供了服务管理的方 企业服务总线技术方案建议 - 9 - 法和在分布式异构环境中进行服务交互的功能。可以这样说，ESB 是特定环境 下(SOA 架构中)实施 EAI 的方式：首先，在 ESB 系统中，被集成的对象被明确 定义为服务，而不是传统 EAI 中各种各样的中间件平台，这样就极大简化了在 集成异构性上的考虑，因为不管有怎样的

25、应用底层实现，只要是 SOA 架构中的 服务，它就一定是基于标准的。 其次，ESB 明确强调消息(Message)处理在集成过程中的作用，这里的消息 指的是应用环境中被集成对象之间的沟通。以往传统的 EAI 实施中碰到的最大 的问题就是被集成者都有自己的方言，即各自的消息格式。作为基础架构的 EAI 系统，必须能够对系统范畴内的任何一种消息进行解析。传统的 EAI 系统 中的消息处理大多是被动的，消息的处理需要各自中间件的私有方式支持，例 如 API 的方式。因此尽管消息处理本身很重要，但消息的直接处理不会是传统 EAI 系统的核心。ESB 系统由于集成对象统一到服务，消息在应用服务之间传 递

26、时格式是标准的，直接面向消息的处理方式成为可能。如果 ESB 能够在底层 支持现有的各种通讯协议，那么对消息的处理就完全不考虑底层的传输细节， 而直接通过消息的标准格式定义来进行。这样，在 ESB 中，对消息的处理就会 成为 ESB 的核心，因为通过消息处理来集成服务是最简单可行的方式。这也是 ESB 中总线(Bus)功能的体现。其实，总线的概念并不新鲜，传统的 EAI 系统中， 也曾经提出过信息总线的概念，通过某种中间件平台，如 CORBA 来连接企业 信息孤岛，但是，ESB 的概念不仅仅是提供消息交互的通道，更重要的是提供 服务的智能化集成基础架构。 最后，事件驱动成为 ESB 的重要特征

27、。通常服务之间传递的消息有两种形 式，一种是调用(Call)， 即请求/回应方式，这是常见的同步模式。还有一种我 们称之为单路消息(One-way)，它的目的往往是触发异步的事件， 发送者不需 要马上得到回复。考虑到有些应用服务是长时间运行的，因此，这种异步服务 之间的消息交互也是 ESB 必须支持的。除此之外，ESB 的很多功能都可以利用 这种机制来实现，例如，SOA 中服务的性能监控等基础架构功能，需要通过 ESB 来提供数据，当服务的请求通过 ESB 中转的时候，ESB 很容易通过事件驱 动机制向 SOA 的基础架构服务传递信息。 企业服务总线技术方案建议 - 10 - 2.4.2ESB

28、 的要素的要素 ESB 连接和企业的 IT 基础结构，可以跨越不同的地域，支持不同的传输协 议，它可以自动路由消息并且提供系统级的功能（例如，消息的格式自动转换） ， ESB 的实现必须是基于标准的规范, 并且这些实现必须是安全的、可靠的，并 且在非常高的流量压力情况下可管理。 在 遵循 SOA 架构的 ESB 模式中，服务交互的参与方并不直接交互，而是通 过一个总线交互，该总线提供虚拟化和管理功能来实现和扩展 SOA 的核心定义。 因此 ESB 模式使请求者不用了解服务提供者的物理实现从应用程序开发 人员和部署人员的角度来看均是如此。总线负责将请求交付给提供所需功能和 QoS 的服务提供者。

29、提供者接收他们要响应的请求，而不知道消息的来源。ESB 本身对使用它的服务请求者和提供者均不可见。应用程序逻辑可以使用各种编 程模型和技术调用或交付服务，而无需考虑是直接连接还是通过 ESB 传递的。 连接到 ESB 是部署决策；应用程序源代码不会受到影响。 2.4.3ESB 的功能的功能 ESB 支持许多交互类型，包括单向、请求/响应、异步、同步和发布/订阅。 它还支持复杂事件处理（在复杂事件处理中，可能会观测到一系列事件） ，以产 生一个事件作为该系列中的关系的结果。 下图对基本 ESB 模式进行了简单描述。 企业服务总线技术方案建议 - 11 - 消息流过将各个通信参与方相互连接在一起的

30、总线,某些参与方会调用其他 参与方提供的服务；而其他参与方则会向感兴趣的使用者发布信息。端点与 ESB 交互的位置称为服务交互点 (SIP)。例如，SIP 可以是 Web 服务端点、消 息队列或 RMI 远程对象的代理。服务注册表将捕获描述以下内容的元数据： SIP 的要求和功能（例如，提供或需要的接口） 、它们希望与其他 SIP 的交互 方式（例如，同步或异步，通过 HTTP 或 JMS） 、它们的 QoS 要求（例如，首 选的安全、可靠交互）以及支持与其他 SIP 交互的其他信息（例如，语义注释） 。 将总线插入参与方之间，提供了将它们的交互通过称为“中介”的构造进 行协调的机会。中介对请

31、求者和提供者之间动态传递的消息进行操作。对于复 杂的交互，可以按顺序将中介连在一起。中介模式部分讨论了实现这些虚拟化、 QoS 和管理概念的常用中介模式。 总的来说，ESB 的主要功能是： ESB 提供了服务位置和标识的基础功能：参与方不需要知道其他参与方的位 置或标识。例如，请求者不需要知道请求是否可以由某个提供者提供服务。 您可以随意添加或删除服务提供者，而不会带来任何干扰。这是 IT 系统实 现灵活的服务框架的基础。 交互协议的功能：参与方不需要采用相同的通信协议或交互方式。表达为 企业服务总线技术方案建议 - 12 - SOAP/HTTP 的请求可能由包括 Java 远程方法调用 (R

32、MI)、EJB 等的提供者 提供服务。 独立的接口处理：请求者和提供者不需要就公共接口达成协议。ESB 可以 通过将请求消息转换为提供者所期望的格式来处理此类差异。 交互的服务质量 (QoS)：参与方声明其 QoS 要求，包括性能和可靠性、请 求的授权、消息内容的加密/解密、服务交互的自动审核以及如何对请求进 行路由（如根据工作负载分布标准将请求路由到可用的实现） 。描述请求者 和提供者的 QoS 要求和功能的策略可以由服务自己实现或者由进行不匹配 补偿的 ESB 实现。因此 ESB 模式使请求者不用了解服务提供者的物理实 现从应用程序开发人员和部署人员的角度来看均是如此。总线负责将 请求交付

33、给提供所需功能和 QoS 的服务提供者。提供者接收他们要响应的 请求，而不知道消息的来源。 保证不同应用系统之间的高度内聚，同时又保持各个应用系统的相对独立 性，使得各个系统之间存在着松散的藕合关系。 保证在一个异构的环境中实现信息稳定、可靠的传输，屏蔽掉用户实际中 的硬件层、操作系统层、网络层等相对复杂、烦琐的接口，最大限度地提 高用户应用的可移植性、可扩充性和可靠性。 可以将复杂的网状结构变为星型结构，大大简化系统配置；它为各种应用 提供一个统一接口，从而大大减少系统间接口的个数；同时，它可以作为 一个数据中心，提供各种数据处理服务 提供了消息处理、格式转换和消息路由等功能，用于实现系统扩

34、展性和高 可靠性。 2.4.4ESB 的实现模式的实现模式 从 ESB 的角度来看，所有的服务交互端点都是类似的，因为它们都发送或 处理请求/事件；它们都要求特定的 QoS；它们可能都需要交互协助。ESB 模式 允许集成开发人员以与处理新业务逻辑、流程编排组件或外部 Web 服务同样 （面向服务）的方式对待与用户交互的请求者或提供者。 用于构建基于 ESB 的解决方案的模式大致分为以下几类： 企业服务总线技术方案建议 - 13 - 交互模式交互模式：允许服务交互点将消息发送到总线或从总线接收消息。 中介模式中介模式：允许对消息交换进行操作。 组合模式组合模式：综合交互模式和中介模式进行更复杂处

35、理。 部署模式部署模式：支持将解决方案部署到联合基础设施中。 2.5应用系统整合的国内外现状应用系统整合的国内外现状 IDC 的调查报告指出：“应用整合市场全球营业收入已经从 2000 年的 50 亿美元上升到 2006 年的 240 亿美元，这意味着综合年增长率超过了 30%。与此 相对应，整个 IT 服务产业的同期综合年增长率预计只有 11%。”IDC 还报道， 北美和西欧等国家产生 90%的应用整合服务需求，而日本和拉美将驱动剩下的 需求。因此，他们认为：应用整合仍是是最近几年内 IT 行业中增长最快的部分。 其实，IT 系统的整合是一个全球性问题，另据有关机构统计，大型企业每年 IT

36、预算的 40%投给了整合和集成平台，整合和集成还被全球 33%的 CIO 评为最重要 的问题，超过 90%的 CIO 认为它是非常重要的问题。 应用整合的前提是企业已经拥有了较为完善但又相互独立的应用信息系统。 经过十几年的努力，我国企业信息化已经得到了很大的发展。随着技术的进步 以及 Internet 和电子商务应用的不断深入，企业对信息化应用的要求也在不断 提高。同时，为了适应发展变化的形势，企业应用系统也面临着升级的压力。 因此，企业面临着两种选择：第一，完全放弃已有的封闭系统，采用全新的开 放技术或产品来开发企业的全部应用；第二，维持已有系统的正常运转，采用 整合技术将不同的系统集成起

37、来。如果是稍大型的企业应用，完全更换是不现 实的。因此绝大多数人倾向于应用整合。 企业服务总线技术方案建议 - 14 - 中国应用整合应用行业分布中国应用整合应用行业分布 企业应用整合不仅包括企业内部应用系统的集成，还包括企业与企业间的 集成。从集成层面上来讲包括点对点集成、平台集成、数据集成、流程集成以 及界面的集成。在电信行业里，去年某省移动成功实施了 EAI 项目，网通也较 早实施了 EAI；在金融领域中，某大型商业银行的某省分行应用 EAI 框架，在 金融领域率先完成了 EAI 项目，将之应用在国际结算业务的单证影像系统中； 其他大型商业银行也逐步或者已经用 EAI 技术构建自身 IT

38、 架构的信息总线。 EAI，如今似乎已成为金融、保险、电信、烟草、保险、石油、电力、航空、汽 车等领域愈来愈不可阻挡的技术趋势。 2.5.1 项目案例项目案例 某国内著名通信公司方案概述某国内著名通信公司方案概述 客客户户需求：需求： 为了适应业务发展需要，面对日益激烈的市场竞争，满足电信多样灵活的产品和服务 快速推向市场, 增强电信企业核心竞争力，国内某通信公司计划在高层面上建立新一代电 信运营支撑系统, 该运营支撑系统以企业级应用整合平台为架构, 通过平台将不同应用商 提供的应用系统整合，实现业务流程自动化和信息共享,为公司的业务发展奠定扎实基础。 企业服务总线技术方案建议

39、- 15 - 建建设设方案：方案： 个个性性化化 集集合合 URL 重重定定向向 传传输输编编码码 客客户户 关关系系 管管理理 服服务务 目目录录 企企业业企企业业 视视图图视视图图 业业务务管管理理 网网络络管管理理 系系统统管管理理 媒媒介介 服服务务服服务务 分分组组多多业业务务分分组组多多业业务务 接接入入平平台台接接入入平平台台 帐帐单单 服服务务 质质量量 管管理理 认认证证 授授权权 计计费费 消消息息处处理理 主主机机服服务务 SP 业业务务 & 基基础础设设施施 呼呼叫叫 中中心心 网网 站站 资资产产 管管理理 供供应应员员工工 管管理理 信信用用 检检查查检检查查 资资

40、产产资资产产 应应用用 办办公公室室 企企业业资资源源规规划划 行行业业 第第三三方方业业务务 & 基基础础设设施施 内内容容 娱娱乐乐 零零售售 行行业业 Internet Extranet 内内容容费费率率 网网络络 有有线线 无无线线 缓缓存存 政政策策 管管理理器器 防防火火墙墙 网网络络 接接入入 认认证证 授授权权 计计费费 数数据据库库数数据据库库数数据据库库数数据据库库数数据据库库数数据据库库 数数据据库库 财务 网络 目目录录协协定定 函函式式库库 域域名名服服务务器器 数数据据库库 工工作作流流应应用用事事务务处处理理流流企企业业应应用用集集成成 Hub 业业务务经经纪纪人

41、人 数数据据 仓仓库库 运营支撑系统体系架构以整合模型(企业体系结构集成)为中心，业务工作流应用全面 集成，该应用允许各种消息通过通信总线在预定的交易信息流中传输，这使业务、市场营 销、运营、安全性决策、政策和流程可以根据运营支撑系统的全方位进行制定。通过建成 的体系架构、使运营支撑系统应用独立于业务工作流，从而提供一种“应用即插即用环境” 用以支持更灵活地选择和集成当前及将来的应用。运营支撑系统应用可通过从市场上购得 的适配器与总线相连，这些适配器用于将总线提供的信息转化为特定应用可以接受的格式。 体系架构框架的另外一个重要组成部分是电信服务供应商的应用服务环境，它在电信服 务供应商的网络

42、IT/运营支撑系统环境中可实现由该电信服务供应商及其他第三方内容和应 用供应商提供的业务的业务接入和提供。应用服务环境的一个重要特性是它定义了标准的 开放互连，以实现将使用供应商网络基础设施的内容和应用集成。需要特别注意的是，许 多电信服务供应商正在大力构建这种基于标准的开放平台以提供新业务。 IBM 参考应用体系架构说明了帮助电信服务供应商为客户提供以下功能所需的框架： 产品选择 下订单 准备服务或产品 激活服务或产品 提供服务或产品 为服务或产品计费 中断服务或产品提供 可实现上述流程的体系架构概念是基于服务总线、工作流程引擎、服务目录数据模型 企业服务总线技术方案建议 - 16 - (S

43、ervice Catalog Data Model)和服务代理(Service Broker)的。 产产品品选择选择： ： 客户选择 WebSphere Business Integration (WBI)来构建 EAI，具体组件包括： WebSphere MQ Workflow (MQWF) 实现端到端的业务工作流管理。 WebSphere Interchange Server (WICS) 完成流程自动化与数据同步。 WebSphere Message Broker (WMB) 实现数据转换与路由。 WebSphere MQ 完成事件服务管理。 WebSphere Business Int

44、egration Adapter 完成应用连接。 2.5.2某较大型商业银行某较大型商业银行 ESB 项目简介项目简介 企业服务总线(Enterprise Service Bus,简称 ESB)是该行基于大集中 SOA 架 构的核心，它将传统的系统间复杂的网状结构变为星型结构，大大简化应用系 统间的集成和管理。作为一个企业系统的信息总线，可以对消息进行分析判断、 处理计算、格式转换以及智能路由等各种消息服务，根据消息的内容进行灵活 而高性能的决策，从而将消息发送到相关的目的地。ESB 的关键在于把系统间 的关系由紧密耦合变为灵活可变的松耦合。 本项目中涉及到的系统和各系统间的关系如图所示。分行

45、层次上，低柜系 统通过 Client/Server(MQI 通道)方式接入 ESB 系统中，其它分行前置系统接入 各总行集中系统中。总行层次上，各开放平台上的总行集中系统（包括： OCRM、对公网银、对私网银、基金、外汇宝、个人信贷、CMIS、综合积分系 统、IBP）通过 Server/Server(MQ 通道)方式接入 ESB。对于总行集中主机平台 应用：针对核心系统，需开发 APPC 适配器；对于综合理财系统，考虑通过 MQ/SNA 通道接入到 ESB 中；对于贷记卡，可以考虑开发 TCP/IP 的适配器实 现或通过 MQ 实现。 企业服务总线技术方案建议 - 17 - 大集中核心系统综合

46、理财平台 低柜系统 ESB 对公网银 OCRM 综合积分系统 基金系统 外汇宝 个人信贷 IBP CMIS 主主机机平平台台 开开放放平平台台 APPC适配器 CICS连接 MQ连接 正在开发的应用 图示： MQI连接 LU连接 总总行行 对私网银 贷记卡系统 TCP/IP适配器 第三方系统 根据 ESB 在系统中的定位，ESB 内部功能模块分为三部分： 1.数据流的处理，负责所有数据流的格式转换、转发 2.接入系统的配置与 Adapter，负责与其他系统的连接 3.管理模块，负责异常处理，并提供操作画面供查询错误信息、统计信息； 提供监控功能，能展现接入各系统的连接情况是否正常。 从安全性方

47、面考虑，通过 ESB 连接的系统分为该行系统内与该行与第三方 系统两类，系统内的连接安全性由网络、系统配置及应用实现；对与系统外的 连接系统交互数据时，数据安全性由双方约定，WMB 支持与之相连的 MQ 进 行数据加密，确保数据中途不被截取。 企业服务总线技术方案建议 - 18 - 第第 3 章章 关键技术分析关键技术分析 3.1与现有系统的集成与现有系统的集成 3.1.1与基于与基于 J2EE 系统的集成系统的集成 J2EE 平台由一整套服务（Services） 、应用程序接口（APIs）和协议构成， 它对开发基于 Web 的多层应用提供了功能支持，他们共同组成了 J2EE 的完整 架构。

48、J2EE 使用多层的分布式应用模型，应用逻辑按功能划分为组件，各个应用 组件根据他们所在的层分布在不同的机器上。以下是 J2EE 典型的四层结构: 运行在客户端机器上的客户层组件 运行在 J2EE 服务器上的 Web 层组件 运行在 J2EE 服务器上的业务逻辑层组件 运行在 EIS 服务器上的企业信息系统(Enterprise information system)层软 件 企业服务总线技术方案建议 - 19 - 与 J2EE 的系统集成，关键是看应用系统是否按照上面所描述的模型方式 来建设，如果系统的逻辑层次分明，则集成会相对容易，反之会麻烦。我们在 集成 J2EE 应用的时候，比较关注的

49、是该系统能抽取哪些服务重用，是通过什 么样的方式将服务发布出来。一般说来，在 J2EE 系统中，Java Bean、POJO、EJB、JMS、Servlet、JCA 等是服务的常见封装方式。我们建议 在和 ESB 进行集成的时候，采用 JMS、POJO 是比较方便、简单的方式。 3.1.2与基于与基于 MQ 系统的集成系统的集成 WebSphere MQ 是非常通用、成熟的商业消息中间件，应用系统对外交互的 接口为消息队列，同时提供消息/数据传输的可靠性保障。MQ 消息中间件一般 同时提供同步、异步两种通讯方式。使用消息队列，消息系统可以管理很多通 讯细节。此种接口方式为典型松耦合模式，是应用

50、集成普遍使用的方式之一， 可以实现接口的重用能力。目前， IT 系统中使用消息中间件比较多，技术也 比较成熟，因此，采用面向消息队列的集成是非常可行的方案。 下面是采用 MQ 连接企业服务总线的示意图： 企业服务总线技术方案建议 - 20 - 3.1.3与基于与基于 CICS 系统的集成系统的集成 CICS在其客户机端支持JAVA、C和COBOL等语言，也采用统一的应用编 程接口(API)，客户可以采用两种方式来编制CICS的客户端程序，一种是 External Call Interface(ECI)，另一种是External Presentation Interface(EPI)。另外 CI

51、CS也提供了符合J2EE JCA规范的适配器 下面是 CICS 服务和企业服务总线集成的示意图： 企业服务总线技术方案建议 - 21 - 3.1.4与基于邮件系统的集成与基于邮件系统的集成 基于邮件（如 Domino）的应用提供了多种方式的集成，可以通过 Java 调 用、本地调用、Web Service、消息等方式和 ESB 进行交互。考虑到我们建议的 ESB 的技术特点，首先我们建议采用和 CICS 类似的方式，通过消息的方式和 ESB 进行集成，可以参考上面的图例。 另外，邮件系统一般提供了比较好的 Web Service 支持，可以直接接受 SOAP 的请求，因此通过 Web Serv

52、ice 调用也是可行的。 3.1.5与基于与基于 C/S 架够系统的集成架够系统的集成 基于 C/S 的应用是上世纪九十年代比较普遍的方式，对集成的考虑比较少。 由于一般 C/S 的应用将页面和应用逻辑混在了一起，因此不容易抽象出后台服 务给其他系统使用。对 C/S 的应用改造会有比较多的工作量。C/S 方式的应用 多数是采用 VB、PB、Delphi 等工具实现，集成的困难是在页面和逻辑的分离 上。考虑到我们建议的 ESB 特点，建议通过 MQ 消息中间件的方式进行集成， 可以参考 CICS 的图例。但是和 CICS 集成的重要区别是 C/S 系统要通过使用 企业服务总线技术方案建议 - 2

53、2 - 本地语言编程来实现连接 MQ 的适配器。 3.2平台扩展性与高可用性的实现平台扩展性与高可用性的实现 ESB 平台我们建议使用 IBM 的 WebSphere Message Broker 实现，它是一个 高性能的产品，在国内外许多大型的系统中有成功应用的案例。Message Broker 和 MQ 都提供了 Cluster 群集解决方案，通过横向扩展提高系统的吞吐 能力，下面是示意图： ESB 是一个服务于广大后台系统的关键系统，除了要求系统具备足够的吞 吐能力外，也要求系统具有相当高的可用性，来支持业务的连续运行。 高可用性的关键在于避免系统的单点故障 (Single Point

54、Of Failure)， WebSphere Message Broker 完全提供了集群功能，实现了整个系统能够有效支 持近似 7*24 小时不间断运行。当系统需要升级或安装补丁时，可对集群中的成 员进行逐一更新，支持系统在升级期间不间断运行。 多个企业服务总线可以共同组成一个 Cluster 环境，实现系统的高可用性。 另外，连接外部系统的 Adapter 需要服务于固定的系统连接，需要利用系统的 HACMP 实现高可用性。 对于采用软件 Cluster 方式的部分，当其中的一个部分需要升级或安装补 企业服务总线技术方案建议 - 23 - 丁时，可以让其中的一个成员暂时停止服务，对其进行相

55、应的操作后重新加入 Cluster 中。按照此方法可以对每个成员逐一进行处理。 需要说明的是，以上两方面都需要对系统、中间件和应用进行仔细的规划。 并且在进行充分的测试后，再在生产系统中使用。 3.3平台安全性的考量平台安全性的考量 ESB 平台是应用集成的核心和基础，对安全性有很高的要求。一般来说， 对安全的考虑主要涉及到认证、授权两个方面，认证主要是判断使用者是不是 “合法”的 ESB 用户，授权是判断使用者有没有权限访问 ESB 特定中的资源。 对于我们推荐使用的 ESB 产品 WebSphere Message Broker，对与安全有比较详 细的考虑。 WebSphere Messa

56、ge Broker 中的安全管理工作包括了配置、运行工具、性 能问题确定、资料收集等，参与到上述任务的人员都需要 WebSphere Message Broker 一定的授权。如果希望可以正确地使用系统授权，管理员必须进行一些 操作。同时，由于 WebSphere Message Broker 涉及比较多的 MQ 资源，对 MQ 安全控制也是考虑的重要因素。 对于 WebSphere Message Broker，授权主要关注谁有权限存取系统中的资 源，确保想访问系统资源的用户是被许可的，例如： 可以配置 WebSphere Message Broker，如使用 mqsicreatebroke

57、r 命令 存取系统队列，如放置一个消息到消息流的启动队列中 在开发工作台中进行操作，如部署消息流到运行环境中 发布、订阅主题 对于系统运行时候的服务，也是需要进行授权才可以访问的。WebSphere Message Broker 中的运行对象存在于 Broker Domain 中，每一个运行对象都有一 个存取控制列表（Access Control List，ACL） ，ACL 决定了哪个用户或者组有 权限存取运行对象。ACL 中的条目明确谁可以查看、修改运行对象。需要说明 的是 ACL 虽然许可或者拒绝用户访问运行对象，但 ACL 并不对运行对象进行 保护。 企业服务总线技术方案建议 - 24

58、 - 使用 ACL 条目，管理员可以控制用户访问 WebSphere Message Broker 中限 定的对象，例如，用户 JUNGLEMPERRY 许可访问修改 BROKER A，但对 BROKER B 可能就没有权限。进一步，即使都在 BROKER A 中，特定用户也可能有权限部 署服务到执行组 1 中，但对执行组 2 没有权限。 企业服务总线技术方案建议 - 25 - 附录附录 A：产品技术文档和白皮书：产品技术文档和白皮书 A.1 WebSphere MQ 产品简介产品简介 WebSphere MQ为系统设计人员提供了一种简单而直接的方法，使得应用程 序可以在不同的操作平台之间相互

59、可靠地交换信息，实现企业内和企业间的商 务整合。 单一的API，跨越三十余种不同的平台 应用集成中介软件 确保消息传递 更快的应用开发 支持同步和异步的事务处理 支持并行处理的应用 完整的商务整合解决方案 什么是什么是 WebSphere MQ? ? WebSphere MQ是什么是什么? WebSphere MQ是IBM的商用消息处理中间件 （Commercial Messaging Middleware）。WebSphere MQ提供一个具有工业标准， 安全，可靠的信息传输系统。它的功能是控制和管理集成的商业应用，使得组 成这个商业应用的多个分支程序（模块）之间通过传递消息完成整个工作流程

60、。 企业服务总线技术方案建议 - 26 - WebSphere MQ基本由一个消息传输系统和一个应用程序接口组成，其资源是消 息和队列（Messaging and Queuing）。 消息消息：一个信息包含两个因素：消息描述（用于定义诸如消息传输目标 等）和数据信息（如应用程序数据或数据库查询等）。程序之间的通讯通过传 递消息而非直接调用程序。 队列队列：一个安全的信息存储区。因为消息存放在队列中，所以应用程序 可以相互独立的运行，以不同的速度，在不同的时间，在不同的地点。 消息传输系统消息传输系统：用于确保队列之间的信息提供，包括网络中不同系统上 的的远程队列之间的信息提供。并保证网络故障或