【IT168 技术文档】

    引言

    SOA 提供了一种灵活的、可扩展且可组合的方法来重用和扩展现有应用程序以及构造新的应用程序。服务声明它们实现的或期望其他服务实现的接口，并且声明控制潜在伙伴交互的策略，从而公布各种功能（包括提供的和请求的）。Web 服务描述语言（Web Services Description Language，WSDL）和其他 Web 服务标准（如 WS-Policy）提供了用于这些声明的词汇。（请参阅参考资料，以获得指向 WSDL Version 2.0 Part 0: Primer 的链接。）

    业务功能的虚拟化（SOA 的一个主要目标）是通过将服务的定义和使用与服务的实现分离开来而实现的。我们可以使用各种技术实现服务，这些技术包括 IBM WebSphere® MQ、IBM CICS® 或 IBM IMS™、Java™ 2 Platform Enterprise Edition (J2EE) Enterprise JavaBeans (EJB)、Java 类、IBM DB2® 查询、Java 消息服务 (JMS) 或 Microsoft® .NET。服务请求者将请求发送到提供其所需功能的服务提供者，而不必考虑它如何实现。 

    ESB 是一种体系结构模式，支持虚拟化通信参与方之间的服务交互并对其进行管理。它提供服务提供者和请求者之间的连接，即使它们并非完全匹配，也能够使它们进行交互。此模式可以使用各种中间件技术和编程模型实现。 

    本文将定义 ESB 模式和它在 SOA 内的角色。后续文章将详细描述其使用场景、使用目前的技术实现 ESB 模式的方法，以及 ESB 技术未来的发展方向。 

    什么是 ESB？ 

    在 ESB 模式中，服务交互的参与方并不直接交互，而是通过一个总线交互，该总线提供虚拟化和管理功能来实现和扩展 SOA 的核心定义。IBM ESB 模式提供以下几方面的虚拟化： 

    位置和标识：参与方不需要知道其他参与方的位置或标识。例如，请求者不需要知道请求是否可以由某个提供者提供服务。您可以随意添加或删除服务提供者，而不会带来任何干扰。
 
    交互协议：参与方不需要采用相同的通信协议或交互方式。表达为 SOAP/HTTP 的请求可能由仅理解 Java 远程方法调用 (RMI) 的提供者提供服务。 

    接口：请求者和提供者不需要就公共接口达成协议。ESB 可以通过将请求消息转换为提供者所期望的格式来处理此类差异。
（交互）服务质量 (QoS)：参与方声明其 QoS 要求，包括性能和可靠性、请求的授权、消息内容的加密/解密、服务交互的自动审核以及如何对请求进行路由（如根据工作负载分布标准将请求路由到可用的实现）。描述请求者和提供者的 QoS 要求和功能的策略可以由服务自己实现或者由进行不匹配补偿的 ESB 实现。 

    因此 ESB 模式使请求者不用了解服务提供者的物理实现——从应用程序开发人员和部署人员的角度来看均是如此。总线负责将请求交付给提供所需功能和 QoS 的服务提供者。提供者接收他们要响应的请求，而不知道消息的来源。ESB 本身对使用它的服务请求者和提供者均不可见。应用程序逻辑可以使用各种编程模型和技术调用或交付服务，而无需考虑是直接连接还是通过 ESB 传递的。连接到 ESB 是部署决策；应用程序源代码不会受到影响。 

    ESB 支持许多交互类型，包括单向、请求/响应、异步、同步和发布/订阅。它还支持复杂事件处理（在复杂事件处理中，可能会观测到一系列事件），以产生一个事件作为该系列中的关系的结果。 

    图 1 对基本 ESB 模式进行了描述。消息流过将各个通信参与方相互连接在一起的总线。某些参与方会调用其他参与方提供的服务；而其他参与方则会向感兴趣的使用者发布信息。端点与 ESB 交互的位置称为服务交互点 (SIP)。例如，SIP 可以是 Web 服务端点、WebSphere MQ 队列或 RMI 远程对象的代理。服务注册表将捕获描述以下内容的元数据：SIP 的要求和功能（例如，提供或需要的接口）、它们希望与其他 SIP 的交互方式（例如，同步或异步，通过 HTTP 或 JMS）、它们的 QoS 要求（例如，首选的安全、可靠交互）以及支持与其他 SIP 交互的其他信息（例如，语义注释）。 


    图 1： 基本 ESB 模式 

    将总线插入参与方之间，提供了将它们的交互通过称为中介 的构造进行协调的机会。中介对请求者和提供者之间动态传递的消息进行操作。对于复杂的交互，可以按顺序将中介连在一起。中介模式部分讨论了实现这些虚拟化、QoS 和管理概念的常用中介模式。 

    ESB 模式为 SOA 实现提供了灵活且易于管理的方法。总线透明地插入端点之间，可以提高服务质量，可以促进请求者和提供者间的交互（而不受协议、交互模式或服务功能不匹配的影响），还可以支持监视和管理。 

    SOA 用户角色及其任务 

    通过研究创建和管理 SOA 解决方案的用户的角色及任务，可以进一步深入了解 ESB 模式。ESB 工具和运行时将 SOA 解决方案的生命周期划分为四个阶段： 

    发现与描述：对可以在整个 ESB 中进行互连的 SIP 进行标识和描述。这包括创建新的服务、发现现有服务、以及描述其接口、要求和功能。 
    建模与构建：通过新建的或现有的中介进行 SIP 互连，以描述解决方案的端到端交互。 
    配置与部署：针对特定的运行时拓扑配置解决方案的抽象声明，并对其进行部署，同时创建必要的运行时构件。 
    监视与管理：通过 SIP 和中介的行为监视和管理解决方案。此阶段将使用 ESB 运行时中的检测和控制点、以及观测和响应消息流的中介。
 
    对于 ESB 中间件，最重要的 SOA 解决方案开发角色是集成开发人员和解决方案管理员，但其中也涉及到业务分析人员、解决方案架构师、实现人员、适配器开发人员和操作人员。（这些角色都是概念性的；一个人可以担任其中的多个角色。）图 2 显示了这些角色交互的方式。 

    业务分析人员确定业务需求，并检查业务流程。他们将概括出解决方案的目标、涉及的业务流程、监视解决方案的运行状况和状态的关键指标，以及 IT 系统需要提供的业务服务的类型。 

    解决方案架构师确定哪些业务需求可以通过对现有 IT 资产进行重用、修改或组合得到满足，哪些需要编写或购买新的 IT 资产。他们定义 IT 资产间的交互，包括消息交换的内容。 

    开发工作在三个角色中分配。实现人员编写新的应用程序代码，这些代码将通过服务接口调用。适配器开发人员构建包装现有或新采购的应用程序和软件包的服务，从而为其他服务提供可访问性。集成开发人员使用 ESB 的相关工具和技术构建逻辑，以控制请求在这些服务间路由的方式。 


    图 2：用户角色 

    解决方案管理员部署新的 IT 资产并将其服务定义导入到服务注册表中，从而使新的 IT 资产可用。当解决方案就绪后，操作人员将监视其执行，根据需要启动和停止 IT 系统，并给解决方案管理员提供建议（后者可能将据此调整解决方案配置）。

    ESB 模式 

    集成开发人员和解决方案管理员会使用一组模式对 SOA 解决方案进行设计和部署。 


    图 3：基本 ESB 模式的元素