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

《面向服务的体系结构中企业服务》由会员分享，可在线阅读，更多相关《面向服务的体系结构中企业服务（27页珍藏版）》请在金锄头文库上搜索。

1、 理解面向服务的体系结构中企业服务总线场景和解决方案第 1 部分企业服务总线中的工作角色Rick Robinson（rick_robinsonuk.ibm.）IT 架构师, IBM2004 年 7 月本文确定了一组最低功能，可以满足企业服务总线（Enterprise ServiceBus，ESB）与面向服务的体系结构（service-orientedarchitecture，SOA）的原则保持一致的基本需要。通过确定这些最低功能，您可以确定利用何种现有技术来实现支持 SOA 的ESB。通过考虑特定情形下的需求如何确定对额外功能的需要，您可以选择最适合这种情形的实现技术。引言最新的 IT 集成是

2、使用 Web服务技术实现面向服务的体系结构（SOA），有许多优秀的文章讲述了该技术的好处和相关的实践（请参见参考资料）。最近，企业服务总线（Enterprise ServiceBus，ESB）的概念被表述为 SOA 基础架构的关键组件（请参见参考资料）。然而，有必要阐明ESB 究竟是一个产品、技术、标准，还是别的什么。特别是，当前是否可以构建 ESB？如果这样，该如何构建？本文将 ESB 描述为由中间件技术实现并支持 SOA 的一组基础架构功能。ESB支持异构环境中的服务、消息，以与基于事件的交互，并且具有适当的服务级别和可管理性。为了达到此目的，需要将多种功能集中起来并加以分类。然而，并不是

3、 ESB能够传递值的每一种情形都需要所有的功能。本文确定了一组最低功能，可以满足 ESB 与 SOA 的原则保持一致的基本需要。通过确定这些最低功能，您可以确定利用何种现有技术来实现支持 SOA 的ESB。通过考虑特定情形下的需求如何确定对额外功能的需要，您可以选择最适合这种情形的实现技术。在接下来的文章中，我将在 SOA 中定义一组 ESB 场景，以定义 ESB 或 SOA实现的共同起点。而解决方案模式又为选择适当的实现技术提供了指南。随着 ESB 解决方案的发展和成熟，它所需要的功能也在不断地发展。同样，可见的 ESB产品的可用性和功能也日趋完善。因此，在本系列的最后一篇文章中，我将考虑

4、SOA 和 ESB 的发展路线，以指导 ESB功能和技术的最初应用，并且阐述如何选择循序渐进的方法。ESB 在 SOA 的工作角色虽然我不打算深入讨论 SOA的定义（请参见参考资料），但是在这里概括一下大部分对 SOA 的描述所适用的原则是很有用的： 利用显式的与实现无关的接口来定义服务。 利用强调位置透明性和可互操作性的通信协议。 封装可重用业务功能的服务的定义。图 1说明了这些原则。注意，虽然 Web 服务技术非常符合这些原则，但它并不是唯一符合这些原则的技术。图 1: SOA 的原则为了实现 SOA，应用程序和基础架构都必须支持 SOA 原则。启用 SOA应用程序涉与到创建服务接口，服务

5、接口可以直接也可以间接地通过使用适配器用于现有的或新的功能。从最基本的级别来看，启用该基础架构涉与到规划功能来将服务请求路由和传递给正确的服务提供者。然而，基础架构支持在不影响服务的客户端的情况下由另一个服务实现替代原有的服务实现也是至关重要的。这不仅需要根据 SOA原则指定服务接口，而且需要基础架构允许客户端代码以独立于所涉与的服务位置和通信协议的方式来调用服务。这样的服务路由和替代是 ESB的许多功能中的一部分。ESB 支持这些服务交互功能，并提供集成的通信、消息传递以与事件基础架构来支持这些功能。因此，它将当今正在使用的主要企业集成模式组合成一个实体。ESB 为SOA 提供与企业需要保持

6、一致的基础架构，从而提供合适的服务级别和可管理性、以与异构环境中的操作。本文剩余部分将讨论 ESB 在 SOA 中的角色，包括它提供的除了基本的路由和传输以外的功能，如下面的ESB 功能模型部分中所述。ESB 结构ESB 有时被描述为分布式基础架构，这与其他的解决方案形成了对比，比如消息代理技术一般被描述为中心辐射型（hub-and-spoke）。然而，这并不是真正的差别。正在研究两个不同的问题：控制的集中和基础架构的分布。ESB和中心辐射型（hub-and-spoke）解决方案都集中控制配置，比如服务交互的路由、服务命名等等。同样，这两个解决方案可能部署在简单的集中式基础架构中，也可能采用更

7、复杂的分布式方式进行部署。图 2展示了这一点。毫无疑问，不同的技术对它们所支持的物理部署模式有不同的约束有些可能适合于非常广泛的分布，以支持在很大的地理围进行的集成，而其他的可能更适合于部署在本地群集中，以支持高可用性和可伸缩性。使物理分布需求与候选技术的功能相匹配是ESB 设计的一个重要方面。另外的一种能力也是非常重要的，就是以增量方式扩展最初的部署来反映不断变化的需求、集成附加的系统或扩展基础架构的物理围。图 2: 分布式 ESB 基础架构的集中控制我还应该定位在 SOA 基础架构中 ESB 与其他组件之间的关系，特别是与 Service Directory、Business Servic

8、eChoreography、以与 Business-to-Business (B2B) Gateway 这些组件之间的关系。由于上述 SOA原则对这些组件并没有严格的要求，所以我们可以将它们视为可选组件。图 3展示的 SOA说明了这些组件之间的关系。图 3: SOA 中的 ESB 角色ESB 需要某种形式的服务路由目录（service routingdirectory）来路由服务请求。然而，SOA 可能还有单独的业务服务目录（business servicedirectory），其最基本的形式可能是设计时服务目录，用于在组织的整个开发活动中实现服务的重用。Web服务远景在业务服务目录和服务路由

9、目录的角色中都放置了一个 UDDI 目录，因而使得可以动态发现和调用服务。这样的目录可以视为 ESB的一部分；然而，在这样的解决方案变得普遍之前，业务服务目录可能与 ESB 是分离的。Business Service Choreographer 的作用是通过若干业务服务来组合业务流程；因此，它将通过 ESB 调用服务，然后再次通过ESB 将业务流程公开为客户端可用的其他服务。然而，Business Service Choreographer在编排业务流程和服务中所扮演的角色确定了这种业务工作流技术是一种与基础架构技术 ESB 分离的技术。最后，B2B Gateway 组件的作用是使两个或多个组

10、织的服务在受控且安全的方式下对彼此可用。这有助于查看这些连接到 ESB 的组件，但它们并不是ESB 的一部分。虽然有一些网关技术可以提供适合于实现 B2B Gateway 组件和ESB 的功能，但是 B2B Gateway 组件的用途是将其与 ESB分离。事实上，这种用途可能需要附加的功能（如合作伙伴关系管理），这些功能不是 ESB 的一部分，并且不一定受到 ESB 技术的支持。ESB 的功能模型表 1对现有文献中确定的一些 ESB 功能进行了总结和分类（请参见参考资料）。虽然有一些功能非常基础，但是其他的功能（如自动化功能或智能化功能）代表着向按需操作环境转变的重要步骤。重要的是认识到，当前

11、的大多数场景只需要部分类别中的部分功能。ESB实现所需的最低功能将在下面支持 SOA 的最低功能的 ESB实现部分中进行探讨。表 1：在现有的文献中定义的 ESB 功能通信服务交互 路由 寻址 通信技术、协议和标准（例如 IBM WebSphere MQ、 和 S） 发布/订阅 响应/请求 Fire-and-Forget，事件 同步和异步消息传递 服务接口定义（例如，Web 服务描述语言（Web Services Description Language，WSDL） 支持替代服务实现 通信和集成所需的服务消息传递模型（例如 SOAP 或企业应用程序集成 (EAI) 中间件模型） 服务目录和发现

12、集成服务质量 数据库 服务聚合 遗留系统和应用程序适配器 EAI 中间件的连接性 服务映射 协议转换 应用程序服务器环境（例如 J2EE 和 .NET） 服务调用的语言接口（例如 Java 和 C/C+/C#） 事务（原子事务、补偿、Web 服务事务（WS-Transaction） 各种确定的传递例（例如 Web 服务可靠消息传递（WS-ReliableMessaging）或对 EAI 中间件的支持）安全性服务级别 身份验证 授权 不可抵赖性 性 安全标准（例如 Kerberos 和 Web 服务安全性（WS-Security） 性能 吞吐量 可用性 其他可以构成契约或协定的持久评估方法消息处

13、理管理和自治 编码的逻辑 基于容的逻辑 消息和数据转换 有效性 中介 对象标识映射 数据压缩 服务预置和注册 记录、测量和监控 发现 系统管理和管理工具的集成 自监控和自管理建模基础架构智能 对象建模 通用业务对象建模 数据格式库 B2B 集成的公共与私有模型 开发和部署工具 业务规则 策略驱动的行为，特别是对于服务级别、服务功能的安全和质量（例如 Web 服务策略（WS-Policy） 模式识别上面的许多功能既可以使用专有技术实现，也可以通过利用开放标准实现。然而，使用不同的技术来实现 ESB可能会使它们的性能、可伸缩性和可靠性这些特性显著不同，同时 ESB功能和所支持的开放标准也会有所不同

14、。由于这些原因，再加上最近制订和正在兴起的一些相关标准，当今实现 ESB的许多关键决策都涉与到成熟的专有技术和不成熟的开放标准之间的权衡。在本系列文章中，我们不打算详细讨论上面的每一个功能类别。相反，我们将集中讨论采用或实现 ESB 的不同方法之间的驱动策略。特别是在下一部分，我们将讨论ESB 为支持 SOA 所需的最低功能由什么构成。支持 SOA 的最低功能的 ESB实现如果在前面确定的功能中只有一部分和大多数 SOA 场景相关，我们可能会问：实现 ESB 所需的一组最低功能由什么构成？为此，考虑最被普遍认同的 ESB定义的原理： ESB 是一种逻辑体系结构组件，它提供与 SOA 的原则保持

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