引言

　　最新的IT集成是使用Web服务技术实现面向服务的体系结构（SOA），有许多优秀的文章讲述了该技术的好处和相关的实践。最近，企业服务总线（Enterprise Service Bus，ESB）的概念被表述为 SOA 基础架构的关键组件。然而，有必要阐明 ESB 究竟是一个产品、技术、标准，还是别的什么。特别是，当前是否可以构建 ESB？如果这样，该如何构建？

　　本文将 ESB 描述为由中间件技术实现并支持 SOA 的一组基础架构功能。ESB 支持异构环境中的服务、消息，以及基于事件的交互，并且具有适当的服务级别和可管理性。为了达到此目的，需要将多种功能集中起来并加以分类。然而，并不是 ESB 能够传递值的每一种情形都需要所有的功能。

　　本文确定了一组最低功能，可以满足 ESB 与 SOA 的原则保持一致的基本需要。通过确定这些最低功能，您可以确定利用何种现有技术来实现支持 SOA 的 ESB。通过考虑特定情形下的需求如何确定对额外功能的需要，您可以选择最适合这种情形的实现技术。

　　随着 ESB 解决方案的发展和成熟，它所需要的功能也在不断地发展。同样，可见的 ESB 产品的可用性和功能也日趋完善。因此，在本系列的最后一篇文章中，我将考虑 SOA 和 ESB 的发展路线，以指导 ESB 功能和技术的最初应用，并且阐述如何选择循序渐进的方法。

　　ESB在SOA内的工作角色

　　虽然我不打算深入讨论 SOA 的定义，但是在这里概括一下大部分对 SOA 的描述所适用的原则是很有用的：

　　利用显式的与实现无关的接口来定义服务。
　　利用强调位置透明性和可互操作性的通信协议。
　　封装可重用业务功能的服务的定义。

　　图 1说明了这些原则。注意，虽然 Web 服务技术非常符合这些原则，但它并不是唯一符合这些原则的技术。

　　图 1: SOA 的原则

　　为了实现 SOA，应用程序和基础架构都必须支持 SOA 原则。启用 SOA 应用程序涉及到创建服务接口，服务接口可以直接也可以间接地通过使用适配器用于现有的或新的功能。从最基本的级别来看，启用该基础架构涉及到规划功能来将服务请求路由和传递给正确的服务提供者。然而，基础架构支持在不影响服务的客户端的情况下由另一个服务实现替代原有的服务实现也是至关重要的。这不仅需要根据 SOA 原则指定服务接口，而且需要基础架构允许客户端代码以独立于所涉及的服务位置和通信协议的方式来调用服务。这样的服务路由和替代是 ESB 的许多功能中的一部分。

　　ESB 支持这些服务交互功能，并提供集成的通信、消息传递以及事件基础架构来支持这些功能。因此，它将当今正在使用的主要企业集成模式组合成一个实体。ESB 为 SOA 提供与企业需要保持一致的基础架构，从而提供合适的服务级别和可管理性、以及异构环境中的操作。

　　本文剩余部分将讨论 ESB 在 SOA 中的角色，包括它提供的除了基本的路由和传输以外的功能，如下面的ESB 功能模型部分中所述。

　　ESB 结构

　　ESB 有时被描述为分布式基础架构，这与其他的解决方案形成了对比，比如消息代理技术一般被描述为中心辐射型（hub-and-spoke）。然而，这并不是真正的差别。正在研究两个不同的问题：控制的集中和基础架构的分布。ESB 和中心辐射型（hub-and-spoke）解决方案都集中控制配置，比如服务交互的路由、服务命名等等。同样，这两个解决方案可能部署在简单的集中式基础架构中，也可能采用更复杂的分布式方式进行部署。图 2展示了这一点。

　　毫无疑问，不同的技术对它们所支持的物理部署模式有不同的约束——有些可能适合于非常广泛的分布，以支持在很大的地理范围内进行的集成，而其他的可能更适合于部署在本地群集中，以支持高可用性和可伸缩性。使物理分布需求与候选技术的功能相匹配是 ESB 设计的一个重要方面。另外的一种能力也是非常重要的，就是以增量方式扩展最初的部署来反映不断变化的需求、集成附加的系统或扩展基础架构的物理范围。

　　图 2: 分布式 ESB 基础架构的集中控制

　　我还应该定位在 SOA 基础架构中 ESB 与其他组件之间的关系，特别是与 Service Directory、Business Service Choreography、以及 Business-to-Business (B2B) Gateway 这些组件之间的关系。由于上述 SOA 原则对这些组件并没有严格的要求，所以我们可以将它们视为可选组件图 3展示的 SOA 说明了这些组件之间的关系。

　　图 3: SOA 中的 ESB 角色

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

　　Business Service Choreographer 的作用是通过若干业务服务来组合业务流程；因此，它将通过 ESB 调用服务，然后再次通过 ESB 将业务流程公开为客户端可用的其他服务。然而，Business Service Choreographer 在编排业务流程和服务中所扮演的角色确定了这种业务工作流技术是一种与基础架构技术 ESB 分离的技术。

　　最后，B2B Gateway 组件的作用是使两个或多个组织的服务在受控且安全的方式下对彼此可用。这有助于查看这些连接到 ESB 的组件，但它们并不是 ESB 的一部分。虽然有一些网关技术可以提供适合于实现 B2B Gateway 组件和 ESB 的功能，但是 B2B Gateway 组件的用途是将其与 ESB 分离。事实上，这种用途可能需要附加的功能（如合作伙伴关系管理），这些功能不是 ESB 的一部分，并且不一定受到 ESB 技术的支持。

　　ESB 的功能模型

　　上面的许多功能既可以使用专有技术实现，也可以通过利用开放标准实现。然而，使用不同的技术来实现 ESB 可能会使它们的性能、可伸缩性和可靠性这些特性显著不同，同时 ESB 功能和所支持的开放标准也会有所不同。由于这些原因，再加上最近制订和正在兴起的一些相关标准，当今实现 ESB 的许多关键决策都涉及到成熟的专有技术和不成熟的开放标准之间的权衡。

　　在本系列文章中，我们不打算详细讨论上面的每一个功能类别。相反，我们将集中讨论采用或实现 ESB 的不同方法之间的驱动策略。特别是在下一部分，我们将讨论 ESB 为支持 SOA 所需的最低功能由什么构成。

　　支持 SOA 的最低功能的 ESB 实现

　　如果在前面确定的功能中只有一部分和大多数 SOA 场景相关，我们可能会问：实现 ESB 所需的一组最低功能由什么构成？为此，考虑最被普遍认同的 ESB 定义的原理：

　　ESB 是一种逻辑体系结构组件，它提供与 SOA 的原则保持一致的集成基础架构。

　　SOA 原则需要使用与实现无关的的接口、强调位置透明性和可互操作性的通信协议、相对粗粒度和封装可重用功能的服务定义。
　　ESB 可以作为分布式的异构基础架构进行实现。
　　ESB 提供了管理服务基础架构的方法和在分布式异构环境中进行操作的功能。

　　请注意这些最低功能并不需要使用特别的技术，比如 EAI 中间件、Web 服务、J2EE 或 XML。这些技术的使用非常接近也非常符合需求，但是不必强制要求使用它们。相反，最低功能几乎只需简单地使用 SOAP/HTTP 和 WSDL 就可以实现（当然不是所有的情况都这样）：

　　URL 寻址和现有的 HTTP 和 DNS 基础架构提供了一个具有路由服务和位置透明性的“总线（bus）”。
　　SOAP/HTTP 支持请求-响应（Request-Response）通信规范。
　　HTTP 传输协议被广泛地使用。
　　SOAP 和 WSDL 是开放、与实现无关的服务通信和连接模型。
　　然而，这些 SOAP/HTTP 和 WSDL 的基本应用只是点到点（point-to-point）的集成，并不能实现一些 ESB 需要的关键功能：

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

　　服务质量和服务级别功能。
　　高级 SOA 概念，例如服务编排、目录、转换等等。
　　按需操作环境需求，比如管理与自治功能以及基础架构智能功能。
　　跨越具有不同所有权的多个网络、多个协议以及多个域的真正意义上的异步操作。

　　影响 ESB 的安全问题

　　我不想在这里直接提出安全需求，不过它们对选择 ESB 的实现技术非常重要。例如，如果服务请求不需要提供身份验证或授权，实现技术的选择就可以非常的广泛。更有可能的情况是，如果需要一些安全级别，则评估什么形式的安全是可以接受的就非常重要。例如：

　　是否可以接受通信基础架构中的安全性，例如，是否在 EAI 中间件服务器之间使用安全套接字层（Secure Socket Layer，SSL）互相验证，或者是否在使用 HTTPS 协议？

　　是否可以接受在参与系统之间单独的点到点（point-to-point）安全性，或者是否需要端到端（end-to-end）模型？例如，是否有必要通过类似于代理的中间件系统来把客户端身份传递到服务实现的最终提供者？

　　是否可以接受应用层中的安全性，例如，客户端代码是否能够执行带有用户 ID 和密码的基本 HTTP 身份验证，或者是否能够把这些信息作为应用程序数据传递给服务？

　　是否需要遵守行业安全标准，例如 Kerberos 或 WS-Security？

　　虽然所有这些都是可能的，但是行业的发展方向是基础架构和中间件支持的符合标准的安全性（例如 Web 服务安全性（WS-Security））功能。然而，相比之下，这些安全标准也是最近才提出的，而且对它们的产品支持仍在发展的过程中，而不是已经确定了，这里尤其需要特别考虑的就是它们的互操作性。因此，任何 ESB 架构都需要尽可能早地确定安全需求，以便在选择实现技术时可以将它们包括进来。

　　结束语

　　在本文中，讨论了大多数通用的 SOA 原则，以及它们与 Web 服务技术的关联。基于这些原则，我提出了需要一个基础架构组件，这个组件可以提供路由功能，以便使服务能够彼此交互，同时还能够支持使用另一个服务实现来替换原有的服务实现。这些功能都是通过 ESB 实现的。

　　ESB 在维持集中控制的同时提供分布式的基础架构，因而需要一些形式的服务路由目录，并且还可能需要业务服务目录。Business Service Choreographer 从 ESB 调用服务，然后通过 ESB 把这些流程作为新的服务公开。

　　ESB 的许多功能包括提供：

　　通信
　　服务交互
　　集成
　　质量服务
　　安全
　　服务级别
　　消息处理
　　管理及自治服务
　　建模
　　基础架构智能

　　从这些不同的功能中，我确定了建立 ESB 所需的最低功能，包括通信、集成和服务交互。