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 2.5.1.1某国内著名通信公司方案概述.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、：.之中，改变是第二个主题。全球化和电子商务 加快了改变的步伐。全球化带来了激烈的竞争，产品周期缩短了，每个公司都 想赢得超过竞争对手的优势。在竞争产品和可以从 Internet 上获得的大量产品 信息的推动下，客户要求更快速地进行改变。因而，在改进产品和服务方面展 开的竞争进一步加剧了。 为了满足客户提出的越来越多的新要求，技术方面的改进也在不断地加快。 企业必须快速地适应这种改变，否则就难以生存，更别提在这个动荡不安竞争 激烈的环境中取得成功了，而 IT 基础设施必须支持企业提高适应能力。 因此，企业组织正在从上世纪八十年代或更早的时期的相互隔离的垂直业 企业服务总线技术方案建议 - 3
4、- 务部门，到上世纪八十年代和九十年代关注业务流程的水平结构，向新的生态 系统业务范例发展。重点是扩展供应链，支持客户和合作伙伴访问业务服务。 下图展示了企业的这种发展。 我如何使我的 IT 环境更灵活且更快地响应不断改变的业务需求呢？ 我们 如何使这些异构系统和应用程序尽可能无缝地进行通信呢？我们如何达到企业 目标而不使企业走向破产的深渊呢？ IT 响应者/支持者是随着企业的这种发展而并行发展的，如下图所示。现 在，许多 IT 经理和专业人员都同样相信，我们真的快找到了一种满意的答案 面向服务的体系结构。 为了减少异构性、互操作性和不断改变的要求的问题，这样的体系结构应 该提供平台来构建具有
5、下列特征的应用程序服务： 松散耦合 位置透明 协议独立 基于这样的面向服务的体系结构，服务使用者甚至不必关心与之通信的特 定服务，因为底层基础设施或服务“总线”将代表使用者做出适当的选择。基础 设施对请求者隐藏了尽可能多的技术。特别地，来自不同实现技术（如 J2EE 或 .NET）的技术规范不应该影响 SOA 用户。如果已经存在一个服务实现， 企业服务总线技术方案建议 - 4 - 我们就还应该重新考虑用一个“更好”的服务实现来代替，新的服务实现必须具 有更好的服务质量。 2.2什么是面向服务的体系架构什么是面向服务的体系架构 面向服务的体系结构是一个组件模型，它将应用程序的不同功能单元（称 为
6、服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立 的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。 这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。 这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服 务之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性，另一点是， 当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够 继续存在。而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功 能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更 改时，它们就显得非常脆弱。 对松耦合的系统
7、的需要来源于业务应用程序需要根据业务的需要变得更加 灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、 合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业 务的性质。我们称能够灵活地适应环境变化的业务为随需应变的（On Demand）业务，在随需应变的业务中，一旦需要，就可以快速地对完成或执 行任务的方式进行必要的更改。 值得注意的是，Web Services 并不是实现 SOA 的惟一方式。例如 CORBA 是另一种方式，同样，面向消息的中间件（Message-Oriented Middleware）系统（比如 IBM 的 MQ）也是一种选择。但是为了建立
8、体系结 构模型，用户所需要的并不只是服务描述。用户需要定义整个应用程序如何在 服务之间执行其工作流。尤其需要找到业务的操作和业务中所使用的软件的操 作之间的转换点。因此，SOA 应该能够将业务的商业流程与它们的技术流程 联系起来，并且映射这两者之间的关系。例如，给供应商付款的操作是商业流 企业服务总线技术方案建议 - 5 - 程，而更新您的零件数据库，以包括进新供应的货物却是技术流程。因而，工 作流还可以在 SOA 的设计中扮演重要的角色。 此外，动态业务的工作流不仅可以包括部门之间的操作，甚至还可以包括 与不为您控制的外部合作伙伴进行的操作。因此，为了提高效率，您需要定义 应该如何得知服务之
9、间的关系的策略，这种策略常常采用服务级协定和操作策 略的形式。 最后，所有这些都必须处于一个信任和可靠的环境之中，以同预期的一样 根据约定的条款来执行流程。因此，安全、信任和可靠的消息传递应该在任何 SOA 中都起着重要的作用。 2.3面向服务的体系结构所带来的好处面向服务的体系结构所带来的好处 如前所述，企业正在处理两个问题：迅速地改变的能力和降低成本的要求。 为了保持竞争力，企业必须快速地适应内部因素（如兼并和重组）或外部因素 （如竞争能力和顾客要求） 。需要经济而灵活的 IT 基础设施来支持企业。 我们可以认识到，采用面向服务的体系结构将给我们带来几方面的好处， 有助于我们在今天这个动荡
10、的商业环境中取得成功： 利用现有的资产利用现有的资产 SOA 提供了一个抽象层，通过这个抽象层，企业可以继续利用它在 IT 方 面的投资，方法是将这些现有的资产包装成提供企业功能的服务。组织可以继 续从现有的资源中获取价值，而不必重新从头开始构建。 更易于集成和管理复杂性更易于集成和管理复杂性 在面向服务的体系结构中，集成点是规范而不是实现。这提供了实现透明 性，并将基础设施和实现发生的改变所带来的影响降到最低限度。通过提供针 对基于完全不同的系统构建的现有资源和资产的服务规范，集成变得更加易于 管理，因为复杂性是隔离的。当更多的企业一起协作提供价值链时，这会变得 更加重要。 更快的响应和上市
11、速度更快的响应和上市速度 从现有的服务中组合新的服务的能力为需要灵活地响应苛刻的商业要求的 组织提供了独特的优势。通过利用现有的组件和服务，可以减少完成软件开发 企业服务总线技术方案建议 - 6 - 生命周期（包括收集需求、进行设计、开发和测试）所需的时间。这使得可以 快速地开发新的业务服务，并允许组织迅速地对改变做出响应和减少上市准备 时间。 减少成本和增加重用减少成本和增加重用 通过以松散耦合的方式公开的业务服务，企业可以根据业务要求更轻松地 使用和组合服务。这意味资源副本的减少、以及重用和降低成本的可能性的增 加。 说到做到说到做到 通过 SOA，企业可以未雨绸缪，为未来做好充分的准备。
12、SOA 业务流程 是由一系列业务服务组成的，可以更轻松地创建、修改和管理它来满足不同时 期的需要。 SOA 提供了灵活性和响应能力，这对于企业的生存和发展来说是至关重 要的。但是面向服务的体系结构决不是灵丹妙药，而迁移到 SOA 也并非一件 可以轻而易举就完成的事情。请别指望一个晚上就将整个企业系统迁移到面向 服务的体系结构，我们推荐的方法是，在业务要求出现或露出苗头时迁移企业 功能的适当部分。 2.4应用系统的应用系统的的整合与的整合与 ESB ESB（Enterprise Service Bus，即企业服务总线）是传统中间件技术与 XML、Web 服务等技术结合的产物。ESB 提供了网络中
13、最基本的连接中枢，是 构筑企业神经系统的必要元素。 企业服务总线 ESB 就是一种可以提供可靠的、有保证的消息技术的最新方 法。ESB 中间件产品利用的是 Web 服务标准和与公认的可靠消息 MOM 协议接 口(例如 IBM 的 WebSphere MQ)。ESB 产品的共有特性包括：连接异构的 MOM、利用 Web 服务描述语言接口封装 MOM 协议，以及在 MOM 传输层上 传送简单对象应用协议(SOAP)传输流的能力。大多数 ESB 产品支持在分布式应 用之间通过中间层如集成代理实现直接对等沟通。 企业服务总线（Enterprise Service Bus，ESB）的概念是从面向服务体系
14、架 构(Service -Oriented Architecture， SOA)发展而来的，与以服务为导向的应用架 企业服务总线技术方案建议 - 7 - 构体系（SOA）紧密连接在一起， 是 SOA 核心组成部分，是 SOA 架构中应用 整合的骨干。SOA 描述了一种 IT 基础设施的应用集成模型，其中的软构件集 是以一种定义清晰的层次化结构相互耦合，其中，一个 ESB 是一个预先组装的 SOA 实现，它包含了实现 SOA 分层目标所必需的基础功能部件。在 SOA 架构 上发布的业务服务是 ESB 的“用户” ，这些基于 SOA 架构的业务系统所开放出 来的服务通过 ESB 进行交互。它们的交
15、互请求被以事件的方式进行发布和订阅。 2.4.1企业应用整合与企业应用整合与 ESB 企业应用整合(EAI)的概念在 IT 界提出和讨论已经有几年的历史了，最初 大家谈到的 EAI 的概念，相对后来 EAI 的发展来看，可以说是一个狭义上的 EAI，正如其字面上的含义Enterprise Application Integration，即企业应用整合， 仅指企业内部不同应用系统之间的互连，以期通过应用整合实现数据在多个系 统之间的同步和共享。 伴随着 EAI 技术的不断发展，它所被赋予的内涵变得越来越丰富。现在大 家谈到的 EAI 的概念，具有更为广义的内涵，它已经被扩展到业务整合 (Busi
16、ness Integration)的范畴，业务整合相对 EAI 来说是一个更宽泛的概念，它 将应用整合进一步拓展到业务流程整合的级别。业务整合不仅要提供底层应用 支撑系统之间的互连，同时要实现存在于企业内部应用与应用之间，本企业和 其他合作伙伴之间的端到端的业务流程的管理，它包括应用整合，B2B 整合， 自动化业务流程管理，人工流程管理，企业门户以及对所有应用系统和流程的 管理和监控等方方面面。 EAI 的目标是支持对现有 IT 系统的重新利用，通过 EAI 技术能够将不同的 软件和系统串联起来，延长这些应用系统的生命周期。传统的 EAI，往往使用 如 CORBA 和 COM 等的消息中间件进
17、行分布式，跨平台的程序交互，修改企 业资源规划以达到新的目标，使用中间件、XML 等方法来进行数据分配。因此， 实际上传统的 EAI 是部件级的重用。很不幸的是，基于部件的架构没有统一的 标准，因此，各个厂商都有各自不同的 EAI 解决方案，你会看到各种各样的中 间件平台。如果 EAI 碰到了异构的 IT 环境，就必须分别考虑怎样在各个不同 企业服务总线技术方案建议 - 8 - 的中间件之间周旋，来实现合理的互联方式，你不得不考虑各种复杂的可能性。 因此，你所见过的大多数传统 EAI 解决方案都比较笨重。 如果我们选择传统的 Hub 模式来构建 SOA 基础架构，从纯粹逻辑的角度， 可能会出现
18、哪些问题呢？首先，整个 SOA 架构的性能，如果每个服务的请求都 经过中央 Hub 的中转，那么 Hub 的负担会很重，速度会随着参与者的增多而愈 来愈慢；其次，这样的系统会很脆弱，一旦 Hub 出错，整个 SOA 架构都会瘫 痪；最后，这样的架构会破坏 SOA 的开放性原则，参与者运行在一个相对封闭 的环境中，扩展起来十分麻烦。因此，这也不是理想的 SOA 架构。 ESB 为基础的架构与前面的 Hub 结构有什么不同呢？首先，它比单一 Hub 的形式更开放，总线结构有无限扩展的可能；其次，真正体现了 SOA 的理念， 一切皆为服务，服务在总线(BUS)中处于平等的地位。即使我们需要一些 Hu
19、b， 那么它们也是以某种服务的形式部署在总线上，相比上面的结构要灵活的多。 这就是 ESB，我们需要给它一个明确的定义：ESB 是一种在松散耦合的服务和 应用之间标准的集成方式。它可以作用于： 面向服务的架构 -分布式的应用由可重用的服务组成 面向消息的架构 - 应用之间通过 ESB 发送和接受消息 事件驱动的架构 - 应用之间异步地产生和接收消息 用一句较通俗的话来描述它：ESB 就是在 SOA 架构中实现服务间智能化集 成与管理的中介。而它与 SOA 的关系要相对好理解一些：ESB 是逻辑上与 SOA 所遵循的基本原则保持一致的服务集成基础架构，它提供了服务管理的方 企业服务总线技术方案建
20、议 - 9 - 法和在分布式异构环境中进行服务交互的功能。可以这样说，ESB 是特定环境 下(SOA 架构中)实施 EAI 的方式：首先，在 ESB 系统中，被集成的对象被明确 定义为服务，而不是传统 EAI 中各种各样的中间件平台，这样就极大简化了在 集成异构性上的考虑，因为不管有怎样的应用底层实现，只要是 SOA 架构中的 服务，它就一定是基于标准的。 其次，ESB 明确强调消息(Message)处理在集成过程中的作用，这里的消息 指的是应用环境中被集成对象之间的沟通。以往传统的 EAI 实施中碰到的最大 的问题就是被集成者都有自己的方言，即各自的消息格式。作为基础架构的 EAI 系统，必
21、须能够对系统范畴内的任何一种消息进行解析。传统的 EAI 系统 中的消息处理大多是被动的，消息的处理需要各自中间件的私有方式支持，例 如 API 的方式。因此尽管消息处理本身很重要，但消息的直接处理不会是传统 EAI 系统的核心。ESB 系统由于集成对象统一到服务，消息在应用服务之间传 递时格式是标准的，直接面向消息的处理方式成为可能。如果 ESB 能够在底层 支持现有的各种通讯协议，那么对消息的处理就完全不考虑底层的传输细节， 而直接通过消息的标准格式定义来进行。这样，在 ESB 中，对消息的处理就会 成为 ESB 的核心，因为通过消息处理来集成服务是最简单可行的方式。这也是 ESB 中总线
22、(Bus)功能的体现。其实，总线的概念并不新鲜，传统的 EAI 系统中， 也曾经提出过信息总线的概念，通过某种中间件平台，如 CORBA 来连接企业 信息孤岛，但是，ESB 的概念不仅仅是提供消息交互的通道，更重要的是提供 服务的智能化集成基础架构。 最后，事件驱动成为 ESB 的重要特征。通常服务之间传递的消息有两种形 式，一种是调用(Call)， 即请求/回应方式，这是常见的同步模式。还有一种我 们称之为单路消息(One-way)，它的目的往往是触发异步的事件， 发送者不需 要马上得到回复。考虑到有些应用服务是长时间运行的，因此，这种异步服务 之间的消息交互也是 ESB 必须支持的。除此之
23、外，ESB 的很多功能都可以利用 这种机制来实现，例如，SOA 中服务的性能监控等基础架构功能，需要通过 ESB 来提供数据，当服务的请求通过 ESB 中转的时候，ESB 很容易通过事件驱 动机制向 SOA 的基础架构服务传递信息。 企业服务总线技术方案建议 - 10 - 2.4.2ESB 的要素的要素 ESB 连接和企业的 IT 基础结构，可以跨越不同的地域，支持不同的传输协 议，它可以自动路由消息并且提供系统级的功能（例如，消息的格式自动转换） ， ESB 的实现必须是基于标准的规范, 并且这些实现必须是安全的、可靠的，并 且在非常高的流量压力情况下可管理。 在 遵循 SOA 架构的 ES
24、B 模式中，服务交互的参与方并不直接交互，而是通 过一个总线交互，该总线提供虚拟化和管理功能来实现和扩展 SOA 的核心定义。 因此 ESB 模式使请求者不用了解服务提供者的物理实现从应用程序开发 人员和部署人员的角度来看均是如此。总线负责将请求交付给提供所需功能和 QoS 的服务提供者。提供者接收他们要响应的请求，而不知道消息的来源。ESB 本身对使用它的服务请求者和提供者均不可见。应用程序逻辑可以使用各种编 程模型和技术调用或交付服务，而无需考虑是直接连接还是通过 ESB 传递的。 连接到 ESB 是部署决策；应用程序源代码不会受到影响。 2.4.3ESB 的功能的功能 ESB 支持许多交互类型，包括单向、请求/响应、异步、同步和发布/订阅。 它还支持复杂事件处理（在复杂事件处理中，可能会观测到一系列事件） ，以产 生一个事件作为该系列中的关系的结果。 下图对基本 ESB 模式进行了简单描述。 企业服务总线技术方案建议 - 11 - 消息流过将各个通信参与方相互连接在一起的总线,某些参与方会调用其他 参与方提供的服务；而其他参与方则会向感兴趣的使用者发布信息。端点与 ESB 交互的位置称为服务交互点 (SIP)。例如，SIP 可以是 Web 服务端点、消 息队列或 RMI 远程对象的代理。服务注册表将捕获描述以下内容的元数据： S
