面向服务的体系结构中企业服务

1、 HYPERLINK 理解面向服务的体系结构中企业服务总线场景和解决方案第 1 部分企业服务总线中的工作角色 HYPERLINK l author1 Rick Robinson（ HYPERLINK mailto:rick_robinson rick_robinson）IT 架构师, IBM2004 年 7 月本文确定了一组最低功能，可以满足企业服务总线（Enterprise ServiceBus，ESB）与面向服务的体系结构（service-orientedarchitecture，SOA）的原则保持一致的基本需要。通过确定这些最低功能，您可以确定利用何种现有技术来实现支持 SOA 的ESB

2、。通过考虑特定情形下的需求如何确定对额外功能的需要，您可以选择最适合这种情形的实现技术。引言最新的 IT 集成是使用 Web服务技术实现面向服务的体系结构（SOA），有许多优秀的文章讲述了该技术的好处和相关的实践（请参见 HYPERLINK l resources 参考资料）。最近，企业服务总线（Enterprise ServiceBus，ESB）的概念被表述为 SOA 基础架构的关键组件（请参见 HYPERLINK l resources 参考资料）。然而，有必要阐明ESB 究竟是一个产品、技术、标准，还是别的什么。特别是，当前是否可以构建 ESB？如果这样，该如何构建？本文将 ESB 描述

3、为由中间件技术实现并支持 SOA 的一组基础架构功能。ESB支持异构环境中的服务、消息，以及基于事件的交互，并且具有适当的服务级别和可管理性。为了达到此目的，需要将多种功能集中起来并加以分类。然而，并不是 ESB能够传递值的每一种情形都需要所有的功能。本文确定了一组最低功能，可以满足 ESB 与 SOA 的原则保持一致的基本需要。通过确定这些最低功能，您可以确定利用何种现有技术来实现支持 SOA 的ESB。通过考虑特定情形下的需求如何确定对额外功能的需要，您可以选择最适合这种情形的实现技术。在接下来的文章中，我将在 SOA 中定义一组 ESB 场景，以定义 ESB 或 SOA实现的共同起点。而

4、解决方案模式又为选择适当的实现技术提供了指南。随着 ESB 解决方案的发展和成熟，它所需要的功能也在不断地发展。同样，可见的 ESB产品的可用性和功能也日趋完善。因此，在本系列的最后一篇文章中，我将考虑 SOA 和 ESB 的发展路线，以指导 ESB功能和技术的最初应用，并且阐述如何选择循序渐进的方法。ESB 在 SOA 内的工作角色虽然我不打算深入讨论 SOA的定义（请参见 HYPERLINK l resources 参考资料），但是在这里概括一下大部分对 SOA 的描述所适用的原则是很有用的：利用显式的与实现无关的接口来定义服务。利用强调位置透明性和可互操作性的通信协议。封装可重用业务功能

5、的服务的定义。 HYPERLINK l figure1 图 1说明了这些原则。注意，虽然 Web 服务技术非常符合这些原则，但它并不是唯一符合这些原则的技术。图 1: SOA 的原则为了实现 SOA，应用程序和基础架构都必须支持 SOA 原则。启用 SOA应用程序涉及到创建服务接口，服务接口可以直接也可以间接地通过使用适配器用于现有的或新的功能。从最基本的级别来看，启用该基础架构涉及到规划功能来将服务请求路由和传递给正确的服务提供者。然而，基础架构支持在不影响服务的客户端的情况下由另一个服务实现替代原有的服务实现也是至关重要的。这不仅需要根据 SOA原则指定服务接口，而且需要基础架构允许客户端

6、代码以独立于所涉及的服务位置和通信协议的方式来调用服务。这样的服务路由和替代是 ESB的许多功能中的一部分。ESB 支持这些服务交互功能，并提供集成的通信、消息传递以及事件基础架构来支持这些功能。因此，它将当今正在使用的主要企业集成模式组合成一个实体。ESB 为SOA 提供与企业需要保持一致的基础架构，从而提供合适的服务级别和可管理性、以及异构环境中的操作。本文剩余部分将讨论 ESB 在 SOA 中的角色，包括它提供的除了基本的路由和传输以外的功能，如下面的ESB 功能模型部分中所述。ESB 结构ESB 有时被描述为分布式基础架构，这与其他的解决方案形成了对比，比如消息代理技术一般被描述为中心

7、辐射型（hub-and-spoke）。然而，这并不是真正的差别。正在研究两个不同的问题：控制的集中和基础架构的分布。ESB和中心辐射型（hub-and-spoke）解决方案都集中控制配置，比如服务交互的路由、服务命名等等。同样，这两个解决方案可能部署在简单的集中式基础架构中，也可能采用更复杂的分布式方式进行部署。 HYPERLINK l figure2 图 2展示了这一点。毫无疑问，不同的技术对它们所支持的物理部署模式有不同的约束有些可能适合于非常广泛的分布，以支持在很大的地理范围内进行的集成，而其他的可能更适合于部署在本地群集中，以支持高可用性和可伸缩性。使物理分布需求与候选技术的功能相匹配

8、是ESB 设计的一个重要方面。另外的一种能力也是非常重要的，就是以增量方式扩展最初的部署来反映不断变化的需求、集成附加的系统或扩展基础架构的物理范围。图 2: 分布式 ESB 基础架构的集中控制我还应该定位在 SOA 基础架构中 ESB 与其他组件之间的关系，特别是与 Service Directory、Business ServiceChoreography、以及 Business-to-Business (B2B) Gateway 这些组件之间的关系。由于上述 SOA原则对这些组件并没有严格的要求，所以我们可以将它们视为可选组件。 HYPERLINK l figure3 图 3展示的 SO

9、A说明了这些组件之间的关系。图 3: SOA 中的 ESB 角色ESB 需要某种形式的服务路由目录（service routingdirectory）来路由服务请求。然而，SOA 可能还有单独的业务服务目录（business servicedirectory），其最基本的形式可能是设计时服务目录，用于在组织的整个开发活动中实现服务的重用。Web服务远景在业务服务目录和服务路由目录的角色中都放置了一个 UDDI 目录，因而使得可以动态发现和调用服务。这样的目录可以视为 ESB的一部分；然而，在这样的解决方案变得普遍之前，业务服务目录可能与 ESB 是分离的。Business Service Ch

10、oreographer 的作用是通过若干业务服务来组合业务流程；因此，它将通过 ESB 调用服务，然后再次通过ESB 将业务流程公开为客户端可用的其他服务。然而，Business Service Choreographer在编排业务流程和服务中所扮演的角色确定了这种业务工作流技术是一种与基础架构技术 ESB 分离的技术。最后，B2B Gateway 组件的作用是使两个或多个组织的服务在受控且安全的方式下对彼此可用。这有助于查看这些连接到 ESB 的组件，但它们并不是ESB 的一部分。虽然有一些网关技术可以提供适合于实现 B2B Gateway 组件和ESB 的功能，但是 B2B Gateway

11、 组件的用途是将其与 ESB分离。事实上，这种用途可能需要附加的功能（如合作伙伴关系管理），这些功能不是 ESB 的一部分，并且不一定受到 ESB 技术的支持。ESB 的功能模型 HYPERLINK l table1 表 1对现有文献中确定的一些 ESB 功能进行了总结和分类（请参见 HYPERLINK l resources 参考资料）。虽然有一些功能非常基础，但是其他的功能（如自动化功能或智能化功能）代表着向按需操作环境转变的重要步骤。重要的是认识到，当前的大多数场景只需要部分类别中的部分功能。ESB实现所需的最低功能将在下面支持 SOA 的最低功能的 ESB实现部分中进行探讨。表 1：在

12、现有的文献中定义的 ESB 功能通信服务交互路由寻址通信技术、协议和标准（例如 IBM WebSphere MQ、HTTP 和 HTTPS）发布/订阅响应/请求Fire-and-Forget，事件同步和异步消息传递服务接口定义（例如，Web 服务描述语言（Web Services Description Language，WSDL）支持替代服务实现通信和集成所需的服务消息传递模型（例如 SOAP 或企业应用程序集成 (EAI) 中间件模型）服务目录和发现集成服务质量数据库服务聚合遗留系统和应用程序适配器EAI 中间件的连接性服务映射协议转换应用程序服务器环境（例如 J2EE 和 .NET）服务

13、调用的语言接口（例如 Java 和 C/C+/C#）事务（原子事务、补偿、Web 服务事务（WS-Transaction）各种确定的传递范例（例如 Web 服务可靠消息传递（WS-ReliableMessaging）或对 EAI 中间件的支持）安全性服务级别身份验证授权不可抵赖性机密性安全标准（例如 Kerberos 和 Web 服务安全性（WS-Security）性能吞吐量可用性其他可以构成契约或协定的持久评估方法消息处理管理和自治编码的逻辑基于内容的逻辑消息和数据转换有效性中介对象标识映射数据压缩服务预置和注册记录、测量和监控发现系统管理和管理工具的集成自监控和自管理建模基础架构智能对象建

14、模通用业务对象建模数据格式库B2B 集成的公共与私有模型开发和部署工具业务规则策略驱动的行为，特别是对于服务级别、服务功能的安全和质量（例如 Web 服务策略（WS-Policy）模式识别上面的许多功能既可以使用专有技术实现，也可以通过利用开放标准实现。然而，使用不同的技术来实现 ESB可能会使它们的性能、可伸缩性和可靠性这些特性显著不同，同时 ESB功能和所支持的开放标准也会有所不同。由于这些原因，再加上最近制订和正在兴起的一些相关标准，当今实现 ESB的许多关键决策都涉及到成熟的专有技术和不成熟的开放标准之间的权衡。在本系列文章中，我们不打算详细讨论上面的每一个功能类别。相反，我们将集中讨

15、论采用或实现 ESB 的不同方法之间的驱动策略。特别是在下一部分，我们将讨论ESB 为支持 SOA 所需的最低功能由什么构成。支持 SOA 的最低功能的 ESB实现如果在前面确定的功能中只有一部分和大多数 SOA 场景相关，我们可能会问：实现 ESB 所需的一组最低功能由什么构成？为此，考虑最被普遍认同的 ESB定义的原理：ESB 是一种逻辑体系结构组件，它提供与 SOA 的原则保持一致的集成基础架构。SOA 原则需要使用与实现无关的的接口、强调位置透明性和可互操作性的通信协议、相对粗粒度和封装可重用功能的服务定义。ESB 可以作为分布式的异构基础架构进行实现。ESB 提供了管理服务基础架构的

16、方法和在分布式异构环境中进行操作的功能。 HYPERLINK l table2 表 2展示了根据这些原则定义的最低 ESB 功能表 2: 最低的 ESB 功能通信集成提供位置透明性的路由和寻址服务控制服务寻址和命名的管理功能至少一种形式的消息传递范型（例如，请求/响应、发布/订阅等等）支持至少一种可以广泛使用的传输协议支持服务提供的多种集成方式，比如 Java 2 连接器、Web 服务、异步通信、适配器等等服务交互一个开放且与实现无关的服务消息传递与接口模型，它应该将应用程序代码从路由服务和传输协议中分离出来，并允许替代服务的实现。请注意这些最低功能并不需要使用特别的技术，比如 EAI 中间件

17、、Web服务、J2EE 或 XML。这些技术的使用非常接近也非常符合需求，但是不必强制要求使用它们。相反，最低功能几乎只需简单地使用 SOAP/HTTP 和 WSDL就可以实现（当然不是所有的情况都这样）：URL 寻址和现有的 HTTP 和 DNS 基础架构提供了一个具有路由服务和位置透明性的“总线（bus）”。SOAP/HTTP 支持请求-响应（Request-Response）通信规范。HTTP 传输协议被广泛地使用。SOAP 和 WSDL 是开放、与实现无关的服务通信和连接模型。然而，这些 SOAP/HTTP 和 WSDL 的基本应用只是点到点（point-to-point）的集成，并不

18、能实现一些 ESB 需要的关键功能：目前还没有用于控制服务寻址和命名的管理功能。服务名称通过每个适配器单独进行控制的，服务路由控制则分散在由服务客户端调用的地址、HTTP基础架构和分配给适配器的服务名称之间。虽然这种方法依赖于实现细节，但是它往往并不能使服务实现的替代变得简单；服务请求者代码（也可能是开发工具生成的）通常通过特定地址的特定协议直接绑定到具体的服务提供者实现。如果想要用另一个服务实现来替代原来的服务实现，就需要修改应用程序代码并重新部署这些代码。当然，在许多甚至是大多数情形中往往需要其他的功能，并且这种需要变得越来越常见。特别地，不管是现在还是以后，下面的需求类型可能会导致更复杂

19、高级的技术的使用：服务质量和服务级别功能。高级 SOA 概念，例如服务编排、目录、转换等等。按需操作环境需求，比如管理与自治功能以及基础架构智能功能。跨越具有不同所有权的多个网络、多个协议以及多个域的真正意义上的异步操作。影响 ESB的安全问题我不想在这里直接提出安全需求，不过它们对选择 ESB的实现技术非常重要。例如，如果服务请求不需要提供身份验证或授权，实现技术的选择就可以非常的广泛。更有可能的情况是，如果需要一些安全级别，则评估什么形式的安全是可以接受的就非常重要。例如：是否可以接受通信基础架构中的安全性，例如，是否在 EAI 中间件服务器之间使用安全套接字层（Secure Socket

20、Layer，SSL）互相验证，或者是否在使用 HTTPS 协议？是否可以接受在参与系统之间单独的点到点（point-to-point）安全性，或者是否需要端到端（end-to-end）模型？例如，是否有必要通过类似于代理的中间件系统来把客户端身份传递到服务实现的最终提供者？是否可以接受应用层中的安全性，例如，客户端代码是否能够执行带有用户 ID 和密码的基本 HTTP身份验证，或者是否能够把这些信息作为应用程序数据传递给服务？是否需要遵守行业安全标准，例如 Kerberos 或 WS-Security？虽然所有这些都是可能的，但是行业的发展方向是基础架构和中间件支持的符合标准的安全性（例如 W

21、eb服务安全性（WS-Security）功能。然而，相比之下，这些安全标准也是最近才提出的，而且对它们的产品支持仍在发展的过程中，而不是已经确定了，这里尤其需要特别考虑的就是它们的互操作性。因此，任何ESB 架构都需要尽可能早地确定安全需求，以便在选择实现技术时可以将它们包括进来。结束语在本文中，我讨论了大多数通用的 SOA原则，以及它们与 Web服务技术的关联。基于这些原则，我提出了需要一个基础架构组件，这个组件可以提供路由功能，以便使服务能够彼此交互，同时还能够支持使用另一个服务实现来替换原有的服务实现。这些功能都是通过ESB 实现的。ESB 在维持集中控制的同时提供分布式的基础架构，因而

22、需要一些形式的服务路由目录，并且还可能需要业务服务目录。Business ServiceChoreographer 从 ESB 调用服务，然后通过 ESB 把这些流程作为新的服务公开。ESB 的许多功能包括提供：通信服务交互集成质量服务安全服务级别消息处理管理及自治服务建模基础架构智能从这些不同的功能中，我确定了建立 ESB 所需的最低功能，包括通信、集成和服务交互。在这个系列的下一个部分中，我将讨论一些通用的场景，以及与这些场景相关的解决方案模式，同时指出影响这些场景最一般的问题。第 2 部分驱动体系结构的 ESB 场景和问题 HYPERLINK l author1 Rick Robinso

23、n（ HYPERLINK mailto:rick_robinson rick_robinson） IT Architect, IBM2004 年 7 月在关于企业服务总线（Enterprise Service Bus，ESB）的这个系列的第二部分中，作者描述和分析了实现 ESB和其他面向服务的体系结构（SOA）的解决方案的一些常见场景。这个系列的 HYPERLINK 第 1篇文章描述了企业服务总线（Enterprise ServiceBus，ESB）的基本概念和工作角色。本文侧重于描述为支持面向服务的体系结构（SOA）而进行的 ESB 开发的场景和问题。您的组织的 SOA 和 ESB可能需要应

24、用到一个或多个这样的场景。ESB 场景及分析SOA 中的 ESB 场景部分描述了许多 SOA 和 ESB实现的起点。每个场景都指出驱动体系结构和设计决策的问题，而这些决策会影响解决方案模式的选择（将在这个系列的第 3 部分中进行介绍）。在 HYPERLINK l 2.2 驱动 ESB体系结构和设计决策的问题部分中，您可以阅读关于这些问题的详细描述。这些解决方案模式代表着从服务技术的基本使用，到简单的 ESB 实现，再到复杂的SOA 体系结构的发展过程。这些 ESB 场景的目的并不在于展示组织对 SOA 或 ESB 的全部需求。例如，虽然某个场景（如两个系统的基本集成）可能看起来很好地匹配了特定

25、的当前需求，但是随着时间的推移，这种需求可能发展成更复杂的需求（如支持一个或多个应用程序实现更广泛的连接性场景。另外，还可能有许多对SOA 或 ESB 基础架构的单独需求会出现这样的情况，就其个别而言符合简单场景，但集中在一起则表现得比较复杂。我们需要在实现满足非常明确的需求的解决方案、努力预料未来的需求和定义跨企业的一致解决方案这三者之间作出选择。将组织的需要看作是总体上相对复杂的场景（如实现具有高服务质量和 Web 服务标准支持的 SOA基础架构）可能是比较适合的。另外，还可以将个别的情形单独看作是简单场景，但是定义最后得到的这些解决方案以后发展成通用体系结构的路线。SOA 中的ESB场景

26、下面的几个部分描述了这些场景的特征： HYPERLINK l table1 两个系统的基本集成 HYPERLINK l table2 支持一个或多个应用程序实现更广泛的连接性 HYPERLINK l table3 支持遗留系统实现更广泛的连接性 HYPERLINK l table4 支持企业应用程序集成（EAI）体系结构实现更广泛的连接性 HYPERLINK l table5 实现组织之间服务或系统的受控集成 HYPERLINK l table6 通过编排服务使流程自动化 HYPERLINK l table7 实现具有高服务质量和 Web 服务标准支持的 SOA 基础架构两个系统的基本集成场景

27、企业需要提供用不同的技术（如 J2EE、.NET、CICS 等等）实现的两个系统之间的集成。Web 服务 SOAP标准或消息传递中间件可能是候选的集成技术。这个场景的一个重要的问题是，将来是否会出现需要集成其他系统的情况。一开始就使用可扩展解决方案可能会对未来的需要提供支持；但是必须在为构建这样的解决方案而付出的额外工作与解决简单的问题的最初需要之间保持平衡。最相关的问题相关的解决方案模式（请参见下一篇文章）1,3,4,6,10,13使用包装器或适配器来实现基本集成请参见基本适配器。或者，想要在将来进行扩展，有以下两种方案：添加控制服务网关。或者实现一个复杂的基础架构比如Web service

28、s Compliant Broker或EAI Infrastructure for SOA。支持一个或多个应用程序实现更广泛的连接性场景现有的已封装或自定义开发的应用程序（例如客户关系管理（Customer RelationshipManagement，CRM）、企业资源规划（Enterprise Resource Planning，ERP）等等）可能是用 J2EE平台或其他应用程序服务器环境实现的，它们提供的可用功能超出了应用程序本身。以服务的形式公开这些功能的价值在于，既支持应用程序彼此之间的互操作，也提供对新的通道或客户端的访问。使用可互操作或开放的标准通信和服务协议看来是今后发展的最佳

29、途径。最相关的问题相关的解决方案模式（请参见下一篇文章）1、2、3、4、6、8、9、10、11、12、13、14使用包装器或适配器来实现基本集成请参见基本适配器。添加控制服务网关。或者实现一个复杂的基础架构比如Web services Compliant Broker或EAI Infrastructure for SOA。如果还需要流程编排（Process Choreography），就实现Service Choreographer或者Full SOA Infrastructure。支持遗留系统实现更广泛的连接性场景组织对遗留技术（比如 CICS、IMS等等）进行了大量的投资，以支持为他们提供

30、核心业务事务和数据访问的应用程序。其重要价值在于提供互操作性或开放标准、以及对这些事务进行基于服务的访问（例如，查询帐户余额的事务、创建订单、日程安排或交付跟踪、查询库存级别等等）。最相关的问题相关的解决方案模式（请参见下一篇文章）1,2,3,4,7,8,9,10,11,13,14使用包装器或适配器来实现基本集成请参见基本适配器。或者，想要在将来进行扩展，有以下两种方案：添加控制服务网关。或者实现一个复杂的基础架构比如Web services Compliant Broker或EAI Infrastructure for SOA。支持企业应用程序集成（EAI）基础架构实现更广泛的连接性场景需要

31、对现有的 EAI 基础架构（如 IBM WebSphere BusinessIntegration）进行扩展，以对其进行基于可互操作协议或开放标准的访问。虽然根据 XML 业务数据并通过高度可互操作协议（如 HTTP 或WebSphere MQ）公开服务接口可以在某些场景中提供适当的互操作性级别，但是如果对现有的集成范围的自定义开发或专有扩展都不是可接受的，则可能需要支持WSDL 和 SOAP Web 标准。最相关的问题相关的解决方案模式（请参见下一篇文章）3、4、5、8、9、11、13、14使用开放数据格式及EAI Infrastructure for SOA来扩展 EAI 基础架构。添加控

32、制服务网关。或者对带有Web services Compliant Broker的基础架构增加开放标准支持。实现组织之间服务或系统的受控集成场景组织希望使其客户、供应商或其他合作伙伴能够直接集成由一个或多个应用程序、遗留系统等等提供的功能。控制的重点是需要提供从外部各方到这些应用程序的安全且易管理的访问。因为组织不能直接控制其合作伙伴所使用的技术，因此最好使用开放标准。此场景既可以应用于分散的组织之间，也可以应用于大型分布式组织的各个单位之间。最相关的问题相关的解决方案模式（参见下一篇文章）1、2、3、4、6、8、9、10、11、13、14添加服务网关。或者如果需要更多的复杂功能，就实现Web

33、 Services Compliant Broker。通过编排服务使流程自动化场景（注意：此场景可以看作是支持一个或多个应用程序实现更广泛的连接性场景的发展。它不被当作一个ESB 场景，因为服务编排通常是与 ESB 分开实现的，正如本系列的第一篇文章所述。然而，我之所以把它包括在这里，是因为此场景往往驱动对 ESB和服务编排组件的需求。）现有的已封装（例如，客户关系管理（Customer RelationshipManagement，CRM）、企业资源规划（Enterprise Resource Planning，ERP）等等）或自定义开发的应用程序可能是在 J2EE平台或其他应用程序服务环境

34、中实现的，它们提供的可用功能超出了应用程序本身。可以使用可互操作或开放通信和服务协议将这些功能作为服务公开，这样应用程序就可以交互。可以在某些层次上组合这些交互以构成业务流程。应该使用适当的建模和流程执行技术（可能遵守适当的开放标准）来对这些流程进行显式建模。最相关的问题相关的解决方案模式（请参见下一篇文章）1、2、3、4、6、10、11、12、13、14如果服务的直接连接是可能的，则实现Service Choreographer。如果需要更复杂的集成或控制，则实现Full SOA Infrastructure。实现具有高服务质量和 Web 服务标准支持的 SOA基础架构场景此场景是由前面的组

35、成的。它代表了对由多个应用程序、遗留系统等等提供的服务进行普遍的内部或外部访问的需要。需要各种安全、聚合、转换、路由以及服务编排功能。IT组织以响应所支持的业务不断增加的需求，从而使得能够在业务系统之间进行更普遍且更灵活的集成。最相关的问题相关的解决方案模式（请参见下一篇文章）全部实现Full SOA Infrastructure。驱动 ESB 体系结构和设计决策的问题为了确定用于 ESB的合适解决方案模式和实现技术，需要对特定的 ESB 功能需求进行详细的分析。下面的问题旨在帮助进行这一过程，而前面的部分指出了与每个场景相关的特定问题。现有功能及其数据接口是否与您想要提供的服务相匹配？您是否

36、能够修改或聚合应用程序？如果不可以，则转换或聚合功能就需要由适配器或 ESB 体系结构来提供，或者不得不由服务客户端来完成。服务是否可以以一些通用业务数据模型的形式公开？如果可以，则实现这些服务的系统是否已经支持该模型？或者说可以使它们这样做？如果服务不可以，则转换或聚合功能就需要由适配器或 ESB 体系结构来提供。是否需要开放标准？或者是否可以通过 EAI 中间件来实现适当的互操作性？如果需要开放标准的话，则哪些开放标准是适合的？虽然使用开放标准是实现互操作性的一种途径，但专有的 EAI中间件也具有高度的互操作性，并且往往要成熟得多。另外，许多组织还拥有广泛的现有基础架构，在一些场景中，它们

37、可能会使得开放标准的作用几近于无。在需要开放标准的场景中，Web 服务也许是这些情况下最明显的选择。不过，您也可以应用 Java Messaging Service(JMS)、JDBC、基本 XML 或者一些其他的技术（比如 EDI 或业界通用的 XML 格式。在实践中，不能总是假定相同标准的不同实现之间具有互操作性，特别是对于近来出现或刚刚兴起的标准。对于 Web 服务，Web 服务互操作性组织（WebServices Interoperability Organization）发布了使用 SOAP 和 WSDL 的互操作性的基本概要，其他更高级的标准（例如Web 服务安全性（WS-Secu

38、rity）、Web服务事务（WS-Transaction）等等）的概要随后也将发布。在产品全面、稳定且广泛地支持这些概要之前，开放标准的使用还没有得到保证，并且可能并不总是促进互操作性。是否需要支持基本通信协议及标准（例如 WebSphere MQ、SOAP、WSDL）？或者需要更高级的功能（例如 Web服务安全性（WS-Security）、Web 服务事务（WS-Transaction）等等）？对支持更复杂标准的需求将对实现技术的选择加以更严格的约束，并且可能意味着使用还不成熟的技术。当果考虑更改现有的基础架构使用的消息格式和协议（包括可能采用开放标准）时，需要在整个现有的基础架构中进行这些

39、更改吗？或者很快就要应用新的消息格式和协议吗？如果正在使用或考虑使用EAI 技术，该技术是否有自己的内部格式？或者它能够将开放标准处理为内部格式吗？开放标准的任何应用都是受扩展访问的需求驱动的，因此它们对现有基础架构的接口的可用性比在内部使用的这样的标准更重要。如果需要在内部使用特定的格式、技术或标准，这会给实现技术的选择带来限制。将作为服务公开的系统实现功能支持所需的技术或开放标准（比如 SOAP、JMS或 XML）吗？如果不支持，ESB 基础架构或适配器将需要在所需的开放标准和服务提供者支持的格式之间进行转换的功能。在需要访问遗留系统的情况下，通过使用更新的基于 XML 的技术，可以直接支

40、持（例如 CICS SOAP支持）遗留系统的可用性吗？是否需要单独的适配器？遗留平台是否支持 XML 处理？如果支持，这种处理是否可以灵活地使用平台功能？如果因为这其中的任何原因而导致所需的 SOAP 或 XML 功能对遗留平台不可用，则需要在适配器（比如s J2C ConnectorArchitecture (JCA) 或 WebSphere Business Integration Adaptors）、集成层或 ESB基础架构中使用适当的转换功能。如果 EAI 技术已经可用，它是否使用适当的功能或接口粒度将服务作为消息流实现？它支持哪些连接性协议（例如JCA、SOAP、WebSphere

41、MQ 以及 Java 远程方法调用（Java Remote Method Invocation）？如果现有消息流不提供所需要的服务，则需要另外的流程来执行转换。如果 EAI 技术不直接支持所需的标准，就需要添加一个网关组件。应该从服务客户端通道以工作负荷缓冲、安全、登录等形式提供给服务提供者系统什么保护措施？这种缓冲通常是 ESB 基础架构的一个角色，并且定义它所需要一些功能。如果特定的服务提供者系统（例如遗留事务系统（legacytransactional systems）需要额外的保护，则可以使用专用集成层。应该实现多少服务？实现的什么方面应该在这些服务中保持一致？如何实施一致性（可能在多

42、个平台上和多个应用程序中）？如果只需要非常少的服务，简单的点到点（point-to-point）集成模型可能比较适合。然而，如果需要更多的服务或者过一段时间以后可能还是如此，则添加控制点（比如由ESB 提供的）就变得愈加有益。服务交互包含在组织内部，还是有一些交互在组织外部？这常常是不同于在单个组织中实现的 ESB 基础架构的一种情况，因为对安全和服务路由的需求可能与外部可用的服务不同。是否需要服务编排？服务编排是否涉及短期（short-lived）或长期（long-lived）（换句话说就是有状态的）流程，还是两者都涉及？它们是否包含人工活动？在这些需求构成业务功能的情况下，应该在与 ESB

43、 分离的 Service Choreographer组件中实现编排。关于是支持长期有状态流程还是支持人工活动的需求将对实现技术的选择产生限制。基础架构应该支持什么样的服务级需求（例如，服务响应时间、吞吐量、可用性等等）？随着时间的推移，需要如何对其进行扩展？一些候选的 ESB实现技术相对较新，并且可能仅仅在有限的服务级进行过测试。同样，由于相关的开放标准不是最近制订就是正在兴起的，所以在更多的既定产品和技术中对它们的支持也是新出现的。在可以预见的未来，关键的体系结构决策将专注于特定开放标准优点的平衡，针对服务级需求的新兴或成熟的产品技术支持这些开放标准。制订这些即时决策需要考虑到有些标准和支持

44、它们的产品是相对成熟的（例如XML、SOAP等等），有些（例如 Web 服务安全（WS-Security）比较新，还有一些（例如 Web 服务事务）是正在兴起的。标准的优点之间的权衡和经过验证的服务级特征往往驱动一个结合了 ESB 与 SOA 体系结构中适应标准的、专有的或自定义技术的混合方法。是否需要点到点（point-to-point）或端到端（end-to-end）安全模型（例如，ESB是否可以简单的对服务请求授权，还是需要将请求者的身份或其他凭证传递给服务提供者）？是否需要使用应用程序或遗留安全系统来集成服务安全模型？如果点到点安全性是可接受的，则许多现有解决方案（例如 SSL 、对数

45、据库访问的 J2EE安全性、适配器安全模型等等）就能够得到应用。如果需要端到端安全性，则 Web服务安全标准就成为可能，提供所有相关的系统来支持它。换句话说，您可以使用带有客户端消息头的客户端模型，或者传送像应用程序数据这样的安全信息。结束语本文确定了一些 ESB实现中最常见的场景，以及对相应的解决方案直接产生影响的问题。虽然没有完全涵盖所有的隐藏问题，但这些是其中最常遇到的。我们概述了从两个系统的基本集成到实现支持高质量服务和 Web 服务标准的 SOA 体系结构的常见场景。并描述了需要重视的十四个不同的问题：现有数据接口业务数据模型开放标准的使用对基本或高级通信协议的支持通过现有系统对数据

46、传递格式的修改通过新技术公开现有服务对遗留系统的访问现有 EAI 技术需要的保护措施需要提供多少服务和需要的一致性程度公司内部以及与其他公司之间的互操作对服务编排的需求服务级需求的基础架构级支持点到点（point-to-point）或端到端（end-to-end）安全模型的使用理解这些基本场景和问题为您开发可能的解决方案打下了牢固的基础。在本系列的第 3 部分，我将讨论本文中提到的实际解决方案。如下：基本适配器服务网关Web services Compliant Broker Service Choreographer 用于 SOA 的 EAI 体系结构完整的 SOA 体系结构最后，我将讨论组

47、织考虑如何使用受控和增量的方式发展它们的体系结构时可用的选择。也将说明能够指导您开发自己的 ESB 路线的一些问题。理解面向服务的体系结构中企业服务总线场景和解决方案，第 3 部分ESB 场景的解决方案级别: 初级 HYPERLINK l author1 Rick Robinson（ HYPERLINK mailto:rick_robinson rick_robinson） IT Architect, IBM2004 年 7 月这个系列文章的第 3 部分介绍了实现企业服务总线（Enterprise ServiceBus，ESB）的场景和解决方案，在此作者分析了 HYPERLINK 第 2部分概

48、述的多个场景可能的解决方案。 HYPERLINK 在第 1部分中说明的总线工作角色提供了这些场景的基础。下面继续这个系列来构建面向服务体系结构（Service-Oriented Architecture，SOA）的企业服务总线，现在我们来看一看第 2部分（请参阅 HYPERLINK l resources 参考资料）中所描述场景的多种显而易见的解决方案模式。以下的每个部分都描述了一种 ESB 实现方式的解决方案模式，除了基本适配器（BasicAdaptors）模式以外，其他的都是简单的点到点（P2P）解决方案。每个模式都提出了不同的使用现行技术的实现选择，同时也做出了正反两方面以及移植方面的考

49、虑。请注意每个解决方案模式的图示，它认为服务客户端与提供服务的系统是分离的。当然，在许多情况下，相同的系统或应用程序既可以是服务客户端也可以是服务提供者。图示并非是要排除系统作为单独的客户端和提供者的可能性，而是承认了相同的系统在不同的互操作中可以有两种不同的工作角色。在决定系统是作为客户端角色来选择、确认和调用服务，还是作为提供者角色来接收、处理和响应服务请求时，这个区别通常很重要。本部分的解决方案模式有：基本适配器（Basic Adaptors）服务网关Web 服务兼容的代理（Web Service-compliant Broker）面向服务体系结构的企业应用集成基础架构（EAI Infr

50、astructure for SOA）服务编排（Service Choreographer）完整的面向服务体系结构的基础架构（Full SOA Infrastructure）基本适配器解决方案模式这种解决方案通过封装器或适配器技术来实现简单的点到点（P2P）服务集成，而不是真正的ESB。这种技术通过 WSDL 定义的 SOAP 访问或者其他可互操作的产品技术（比如 IBM WebSphere MQ（MQ）来实现集成。如果这些技术没有为服务接口定义（比如 WSDL）提供本地模型，那么将需要使用自定义模型来实现 SOA 规范。虽然设计比较简单，但是从该模式中可以获得的好处却不可低估。例如，通过 M

51、Q 或 SOAP/HTTP 进行的直接集成仍然可以是松散耦合式的，尤其是互操作的特征是使用接口来声明时。在将来的某个时候，对于支持最初使用的集成技术的ESB 基础架构，我们可以通过它来中断集成。还可以在进程级别的服务命名和寻址之上实现控制级别。现在已经有各种各样的适配器可用，而且也可以通过开发工具或运行时技术来创建新的适配器。并能使其提供对 Web 服务规范和 企业应用集成（EnterpriseApplication Integration，EAI）中间件的支持。它也可以提供给多种不同类型的系统，包含最新的分布式应用服务器（J2EE 服务器（如WebSphere），或者微软的 .NET 系统）

52、、企业遗留系统（比如 CICS）以及 Commercial Off-the-Shelf 软件包（比如 SAP或 Siebel）。 HYPERLINK l figure4 图 1说明了一般的基本适配器解决方案，包含了使用现有的 HTTP 和 EAI 中间件基础架构来支持新的集成。虽然本图描绘的是内部集成场景，但如果用 HTTP来作为通信协议，或者使用某些 Internet 兼容的 EAI 技术（比如 MQ internet pass-thru），那么该解决方案同样可以应用于外部场景。图 1. 基本适配器解决方案模式将现有 HTTP 和未修改的 EAI基础架构描述为支持服务总线功能的某些方面选择基

53、本适配器的实现技术以下是实现基本适配器的一些选择：使用遗留系统或应用程序直接提供的 SOAP 或 EAI 功能。例如，IBM CICS 目前直接提供对 SOAP 的支持，以及许多系统和应用程序包能够支持MQ 或 SOAP 接口。如果用于提供访问的应用程序是用户自己开发的应用程序且运行于应用服务器环境，或者只要应用服务器运行时环境和应用开发环境能够用来给应用程序添加封装器。例如，WebSphereStudio Application Developer 能够用来给部署于 WebSphere Application Server（ApplicationServer）的 J2EE 应用程序添加 XM

54、L、SOAP 或 MQ 支持。如果这种支持不可用或不合适（例如， 如果 XML 转换不适合用来处理现有平台上的资源），那么可能需要其他的体系结构层，如 HYPERLINK l figure5 图 2所示。这可能是托管了与应用程序或遗留系统集成的适配器的应用服务器层。例如，Application Developer Integration Edition提供了 Java 2 连接器架构（Java 2 Connector Architecture，JCA）连接器技术来访问遗留系统（比如 CICS），并通过WebSphere 运行时环境为其提供了 J2EE 和 Web 服务接口。图 2. 执行 XM

55、L 转换处理的其他体系结构层如果使用开发工具来创建自己的封装器，那么您可以增强工具提供的功能：通过创建一个框架或一组实用工具类来执行通用任务，比如安全性、日志纪录等等。然而，这种方法可能引起范围蠕变（scopecreep），并最终导致该框架实际上变成了用户开发的 HYPERLINK l 2 服务网关或 HYPERLINK l 3 Web 服务兼容代理。当定义框架提议的功能时，需要注意验证开发和维护的成本是否合适，以及转换为更复杂的模式是更不合适的。请参阅 HYPERLINK l resources 参考资料以获取更多有关实现此模式的详细信息。基本适配器剖析从正面来说，这种解决方案模式对新的基本

56、架构的需求最低或是根本不需要，并且使用的都是广泛支持的各种规范和技术。从反面来说，像安全、管理等功能都交给了应用程序或单个封装器的实现来处理。由于该模式基于使用协同操作技术和开放式标准，因此将该模式移植到更复杂的体系结构也就相对比较简单。模式替换如果以上均不能满足集成的需求，或者存在一些附加功能或服务质量需求，那么封装器方式就可能满足不了需求。如果是这样，从逻辑上说下一步应该是 HYPERLINK l 2 服务网关。如果需要更高级ESB 功能，则 HYPERLINK l 3 Web 服务兼容代理或 HYPERLINK l 4 EAI Infrastructure for SOA模式会比较适合。

57、服务网关解决方案模式这种模式代表了一种基本的 ESB实现，接近于在 HYPERLINK l 2.2 第 1部分中描述的“最低功能的 ESB 实现”。服务网关一般通过 SOAP/HTTP、MQ、Java 消息服务（Java MessageService，JMS）等来支持客户端连接，但是也可以通过诸如 JCA 或 WebSphere 业务集成适配器（WebSphere BusinessIntegration Adaptors，WBIA）来对服务提供者支持更广泛的集成。网关组件为服务路由、协议转换以及安全担当着中央控制点的角色。网关能够用来向客户端提供一致的服务命名空间（例如，以 URL 的形式为

58、SOAP/HTTP服务提供命名空间），并可以向服务提供授权模型，实际上这些服务是由完全不同的系统通过多种协议来提供的。当需要向外部合作伙伴（比如客户端或供应方）公开服务时，网关所提供的这些功能便成为一个明显的需求。然而当需要对从应用程序到用多种系统和技术实现的功能的访问进行简化时，这些功能在单个企业内部也很有用。一个关键的网关功能是将客户端支持的服务协议转换为提供方支持的服务协议。这些协议可以包括 SOAP/HTTP、MQ 或SOAP/JMS、JCA、RMI/IIOP 等。候选实现技术的能力需要针对所需要的客户端和提供方协议来进行评价。 HYPERLINK l figure6 图 3描述了服务

59、网关解决方案模式图 3. 使用服务网关模式实现 ESB选择服务网关的实现技术服务网关解决方案模式可以用以下的方式来实现：使用打包好的网关技术，比如 WebSphere Application Server Network Deployment 或 WebSphereBusiness Integration Connection 提供的 Web ServicesGateway。许多网关技术支持某些形式的中间件过滤器或处理器程序设计模型，以实现自定义增强功能。Web Services Gateway提供了一些可配置的中间件功能。它也支持基于 XML 的远程过程调用 Java APIs（Java A

60、PIs for XML-based RemoteProcedure Call ，JAX-RPC）规范中定义的 Web 服务请求/响应处理程序。使用应用程序开发和最新应用服务器技术的运行时功能来实现自定义网关。这可能包含与前面 HYPERLINK l 1 基本适配器解决方案模式中所描述的相同类型的适配器。如果需要更高级的功能，就应该考虑更复杂高级的 EAI 中间件，比如 WebSphere Business Integration MessageBroker。这种模式的许多实现存在于遗留技术中，这些遗留技术通常没有使用 Web服务技术。例如，许多组织构建了路由器事务，它对多种遗留事务提供了使用类