SOA中的ESB角色

　　图 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实现部分中进行探讨。

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

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

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

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

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

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

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

　　2.SOA原则需要使用与实现无关的的接口、强调位置透明性和可互操作性的通信协议、相对粗粒度和封装可重用功能的服务定义。

　　3.ESB可以作为分布式的异构基础架构进行实现。

　　4.ESB提供了管理服务基础架构的方法和在分布式异构环境中进行操作的功能。

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

　　最低的 ESB 功能

　　表 2: 最低的 ESB 功能

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

　　1.URL寻址和现有的HTTP和DNS基础架构提供了一个具有路由服务和位置透明性的“总线（bus）”。

　　2.SOAP/HTTP支持请求-响应（Request-Response）通信规范。

　　3.HTTP传输协议被广泛地使用。

　　4.SOAP和WSDL是开放、与实现无关的服务通信和连接模型。

　　然而，这些 SOAP/HTTP和WSDL的基本应用只是点到点（point-to-point）的集成，并不能实现一些 ESB 需要的关键功能：

　　1.目前还没有用于控制服务寻址和命名的管理功能。服务名称通过每个适配器单独进行控制的，服务路由控制则分散在由服务客户端调用的地址、HTTP 基础架构和分配给适配器的服务名称之间。

　　2.虽然这种方法依赖于实现细节，但是它往往并不能使服务实现的替代变得简单；服务请求者代码（也可能是开发工具生成的）通常通过特定地址的特定协议直接绑定到具体的服务提供者实现。如果想要用另一个服务实现来替代原来的服务实现，就需要修改应用程序代码并重新部署这些代码。

　　当然，在许多甚至是大多数情形中往往需要其他的功能，并且这种需要变得越来越常见。特别地，不管是现在还是以后，下面的需求类型可能会导致更复杂高级的技术的使用：

　　1.服务质量和服务级别功能。

　　2.高级 SOA 概念，例如服务编排、目录、转换等等。

　　3.按需操作环境需求，比如管理与自治功能以及基础架构智能功能。

　　4.跨越具有不同所有权的多个网络、多个协议以及多个域的真正意义上的异步操作。

　　影响 ESB 的安全问题

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

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

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

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

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

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

　　结束语

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

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

　　ESB的许多功能包括提供：

　　1.通信

　　2.服务交互

　　3.集成

　　4.质量服务

　　5.安全

　　6.服务级别

　　7.消息处理

　　8.管理及自治服务

　　9.建模

　　10.基础架构智能

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