本文确定了一组最低功能，可以满足企业服务总线（Enterprise Service Bus，ESB）与面向服务的体系结构（service-oriented architecture，SOA）的原则保持一致的基本需要。通过确定这些最低功能，您可以确定利用何种现有技术来实现支持SOA的ESB。通过考虑特定情形下的需求如何确定对额外功能的需要，您可以选择最适合这种情形的实现技术。

　　引言

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

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

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

　　在接下来的文章中，我将在SOA中定义一组ESB场景，以定义ESB或SOA实现的共同起点。而解决方案模式又为选择适当的实现技术提供了指南。

　　随着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的功能模型

　　表1对现有文献中确定的一些ESB功能进行了总结和分类（请参见参考资料）。虽然有一些功能非常基础，但是其他的功能（如自动化功能或智能化功能）代表着向按需操作环境转变的重要步骤。重要的是认识到，当前的大多数场景只需要部分类别中的部分功能。ESB实现所需的最低功能将在下面支持SOA的最低功能的ESB实现部分中进行探讨。

　　表1：在现有的文献中定义的ESB功能

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

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

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

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

　　·ESB是一种逻辑体系结构组件，它提供与SOA的原则保持一致的集成基础架构。
　　·SOA原则需要使用与实现无关的的接口、强调位置透明性和可互操作性的通信协议、相对粗粒度和封装可重用功能的服务定义。
　　·ESB可以作为分布式的异构基础架构进行实现。
　　·ESB提供了管理服务基础架构的方法和在分布式异构环境中进行操作的功能。

　　表2展示了根据这些原则定义的最低ESB功能

　　表2: 最低的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所需的最低功能，包括通信、集成和服务交互。

　　在这个系列的下一个部分中，我将讨论一些通用的场景，以及与这些场景相关的解决方案模式，同时指出影响这些场景最一般的问题。

　　关于作者

　　Rick Robinson是IBM的一名IT架构师，他于1997年3月作为一名开发人员加入该公司。他是EMEA WebSphere Lab Services的Architecture Services group的一位成员，他从1999年WebSphere软件平台首次发布时就开始关注它。Rick更关注技术而不是行业，但是在过去的三年里他花了大量的时间和金融领域的公司一起工作。Rick是IBM的一位值得信赖的IT架构设计专业人员。在加入IBM之前，Rick在攻读物理博士。