理解面向服务的体系结构中企业服务总线场景和解决方案4593299492

理解面向服务的体系结构中企业服务总线场景和解决方案第1部分企业服务总线中的工作角色RickRobinson（[e-mail]）IT架构师,IBM2004年7月本文确定了一组最低功能，可以满足企业服务总线（EnterpriseServiceBus，ESB）与面向服务的体系结构（service-orientedarchitecture，SOA）的原则保持一致的基本需要。通过确定这些最低功能，您可以确定利用何种现有技术来实现支持SOA的ESB。通过考虑特定情形下的需求如何确定对额外功能的需要，您可以选择最适合这种情形的实现技术。引言最新的IT集成是使用Web服务技术实现面向服务的体系结构（SOA），有许多优秀的文章讲述了该技术的好处和相关的实践（请参见参考资料）。最近，企业服务总线（EnterpriseServiceBus，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与其他组件之间的关系，特别是与ServiceDirectory、BusinessServiceChoreography、以及Business-to-Business(B2B)Gateway这些组件之间的关系。由于上述SOA原则对这些组件并没有严格的要求，所以我们可以将它们视为可选组件。图3展示的SOA说明了这些组件之间的关系。图3:SOA中的ESB角色ESB需要某种形式的服务路由目录（serviceroutingdirectory）来路由服务请求。然而，SOA可能还有单独的业务服务目录（businessservicedirectory），其最基本的形式可能是设计时服务目录，用于在组织的整个开发活动中实现服务的重用。Web服务远景在业务服务目录和服务路由目录的角色中都放置了一个UDDI目录，因而使得可以动态发现和调用服务。这样的目录可以视为ESB的一部分；然而，在这样的解决方案变得普遍之前，业务服务目录可能与ESB是分离的。BusinessServiceChoreographer的作用是通过若干业务服务来组合业务流程；因此，它将通过ESB调用服务，然后再次通过ESB将业务流程公开为客户端可用的其他服务。然而，BusinessServiceChoreographer在编排业务流程和服务中所扮演的角色确定了这种业务工作流技术是一种与基础架构技术ESB分离的技术。最后，B2BGateway组件的作用是使两个或多个组织的服务在受控且安全的方式下对彼此可用。这有助于查看这些连接到ESB的组件，但它们并不是ESB的一部分。虽然有一些网关技术可以提供适合于实现B2BGateway组件和ESB的功能，但是B2BGateway组件的用途是将其与ESB分离。事实上，这种用途可能需要附加的功能（如合作伙伴关系管理），这些功能不是ESB的一部分，并且不一定受到ESB技术的支持。ESB的功能模型表1对现有文献中确定的一些ESB功能进行了总结和分类（请参见参考资料）。虽然有一些功能非常基础，但是其他的功能（如自动化功能或智能化功能）代表着向按需操作环境转变的重要步骤。重要的是认识到，当前的大多数场景只需要部分类别中的部分功能。ESB实现所需的最低功能将在下面支持SOA的最低功能的ESB实现部分中进行探讨。表1：在现有的文献中定义的ESB功能通信服务交互路由寻址通信技术、协议和标准（例如IBM®WebSphere®MQ、HTTP和HTTPS）发布/订阅响应/请求Fire-and-Forget，事件同步和异步消息传递服务接口定义（例如，Web服务描述语言（WebServicesDescriptionLanguage，WSDL））支持替代服务实现通信和集成所需的服务消息传递模型（例如SOAP或企业应用程序集成(EAI)中间件模型）服务目录和发现集成服务质量数据库服务聚合遗留系统和应用程序适配器EAI中间件的连接性服务映射协议转换应用程序服务器环境（例如J2EE和.NET）服务调用的语言接口（例如Java和C/C++/C#）事务（原子事务、补偿、Web服务事务（WS-Transaction））各种确定的传递范例（例如Web服务可靠消息传递（WS-ReliableMessaging）或对EAI中间件的支持）安全性服务级别身份验证授权不可抵赖性机密性安全标准（例如Kerberos和Web服务安全性（WS-Security））性能吞吐量可用性其他可以构成契约或协定的持久评估方法消息处理管理和自治编码的逻辑基于内容的逻辑消息和数据转换有效性中介对象标识映射数据压缩服务预置和注册记录、测量和监控发现系统管理和管理工具的集成自监控和自管理建模基础架构智能对象建模通用业务对象建模数据格式库B2B集成的公共与私有模型开发和部署工具业务规则策略驱动的行为，特别是对于服务级别、服务功能的安全和质量（例如Web服务策略（WS-Policy））模式识别上面的许多功能既可以使用专有技术实现，也可以通过利用开放标准实现。然而，使用不同的技术来实现ESB可能会使它们的性能、可伸缩性和可靠性这些特性显著不同，同时ESB功能和所支持的开放标准也会有所不同。由于这些原因，再加上最近制订和正在兴起的一些相关标准，当今实现ESB的许多关键决策都涉及到成熟的专有技术和不成熟的开放标准之间的权衡。在本系列文章中，我们不打算详细讨论上面的每一个功能类别。相反，我们将集中讨论采用或实现ESB的不同方法之间的驱动策略。特别是在下一部分，我们将讨论ESB为支持SOA所需的最低功能由什么构成。支持SOA的最低功能的ESB实现如果在前面确定的功能中只有一部分和大多数SOA场景相关，我们可能会问：实现ESB所需的一组最低功能由什么构成？为此，考虑最被普遍认同的ESB定义的原理：ESB是一种逻辑体系结构组件，它提供与SOA的原则保持一致的集成基础架构。SOA原则需要使用与实现无关的的接口、强调位置透明性和可互操作性的通信协议、相对粗粒度和封装可重用功能的服务定义。ESB可以作为分布式的异构基础架构进行实现。ESB提供了管理服务基础架构的方法和在分布式异构环境中进行操作的功能。表2展示了根据这些原则定义的最低ESB功能表2:最低的ESB功能通信集成提供位置透明性的路由和寻址服务控制服务寻址和命名的管理功能至少一种形式的消息传递范型（例如，请求/响应、发布/订阅等等）支持至少一种可以广泛使用的传输协议支持服务提供的多种集成方式，比如Java2连接器、Web服务、异步通信、适配器等等服务交互一个开放且与实现无关的服务消息传递与接口模型，它应该将应用程序代码从路由服务和传输协议中分离出来，并允许替代服务的实现。请注意这些最低功能并不需要使用特别的技术，比如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基础架构和分配给适配器的服务名称之间。虽然这种方法依赖于实现细节，但是它往往并不能使服务实现的替代变得简单；服务请求者代码（也可能是开发工具生成的）通常通过特定地址的特定协议直接绑定到具体的服务提供者实现。如果想要用另一个服务实现来替代原来的服务实现，就需要修改应用程序代码并重新部署这些代码。当然，在许多甚至是大多数情形中往往需要其他的功能，并且这种需要变得越来越常见。特别地，不管是现在还是以后，下面的需求类型可能会导致更复杂高级的