在关于企业服务总线(Enterprise Service Bus，ESB)的这个系列的第二部分中，作者描述和分析了实现ESB和其他面向服务的体系结构(SOA)的解决方案的一些常见场景。

　　这个系列的第1篇文章描述了企业服务总线(Enterprise Service Bus，ESB)的基本概念和工作角色。本文侧重于描述为支持面向服务的体系结构(SOA)而进行的ESB开发的场景和问题。您的组织的SOA和ESB可能需要应用到一个或多个这样的场景。

　　ESB场景及分析

　　SOA中的ESB场景部分描述了许多SOA和ESB实现的起点。每个场景都指出驱动体系结构和设计决策的问题，而这些决策会影响解决方案模式的选择(将在这个系列的第3部分中进行介绍)。在 驱动ESB体系结构和设计决策的问题 部分中，您可以阅读关于这些问题的详细描述。这些解决方案模式代表着从服务技术的基本使用，到简单的ESB实现，再到复杂的SOA体系结构的发展过程。

　　这些ESB场景的目的并不在于展示组织对SOA或ESB的全部需求。例如，虽然某个场景(如两个系统的基本集成)可能看起来很好地匹配了特定的当前需求，但是随着时间的推移，这种需求可能发展成更复杂的需求(如支持一个或多个应用程序实现更广泛的连接性场景。另外，还可能有许多对SOA或ESB基础架构的单独需求会出现这样的情况，就其个别而言符合简单场景，但集中在一起则表现得比较复杂。

　　我们需要在实现满足非常明确的需求的解决方案、努力预料未来的需求和定义跨企业的一致解决方案这三者之间作出选择。将组织的需要看作是总体上相对复杂的场景(如实现具有高服务质量和Web服务标准支持的SOA基础架构)可能是比较适合的。另外，还可以将个别的情形单独看作是简单场景，但是定义最后得到的这些解决方案以后发展成通用体系结构的路线。

　　SOA中的ESB场景

　　下面的几个部分描述了这些场景的特征：

　　·两个系统的基本集成

　　·支持一个或多个应用程序实现更广泛的连接性

　　·支持遗留系统实现更广泛的连接性

　　·支持企业应用程序集成(EAI)体系结构实现更广泛的连接性

　　·实现组织之间服务或系统的受控集成

　　·通过编排服务使流程自动化

　　·实现具有高服务质量和Web服务标准支持的SOA基础架构

　　两个系统的基本集成

　　支持一个或多个应用程序实现更广泛的连接性

　　支持遗留系统实现更广泛的连接性

　　支持企业应用程序集成(EAI)基础架构实现更广泛的连接性

　　实现组织之间服务或系统的受控集成

　　通过编排服务使流程自动化

　　实现具有高服务质量和Web服务标准支持的SOA基础架构

　　驱动ESB体系结构和设计决策的问题

　　为了确定用于ESB的合适解决方案模式和实现技术，需要对特定的ESB功能需求进行详细的分析。下面的问题旨在帮助进行这一过程，而前面的部分指出了与每个场景相关的特定问题。

　　·现有功能及其数据接口是否与您想要提供的服务相匹配?您是否能够修改或聚合应用程序?

　　如果不可以，则转换或聚合功能就需要由适配器或ESB体系结构来提供，或者不得不由服务客户端来完成。

　　·服务是否可以以一些通用业务数据模型的形式公开?如果可以，则实现这些服务的系统是否已经支持该模型?或者说可以使它们这样做?

　　如果服务不可以，则转换或聚合功能就需要由适配器或ESB体系结构来提供。

　　·是否需要开放标准?或者是否可以通过EAI中间件来实现适当的互操作性?如果需要开放标准的话，则哪些开放标准是适合的?

　　虽然使用开放标准是实现互操作性的一种途径，但专有的EAI中间件也具有高度的互操作性，并且往往要成熟得多。另外，许多组织还拥有广泛的现有基础架构，在一些场景中，它们可能会使得开放标准的作用几近于无。

　　在需要开放标准的场景中，Web服务也许是这些情况下最明显的选择。不过，您也可以应用Java Messaging Service (JMS)、JDBC、基本XML或者一些其他的技术(比如EDI或业界通用的XML格式。

　　在实践中，不能总是假定相同标准的不同实现之间具有互操作性，特别是对于近来出现或刚刚兴起的标准。对于Web服务，Web服务互操作性组织(Web Services Interoperability Organization)发布了使用SOAP和WSDL的互操作性的基本概要，其他更高级的标准(例如 Web服务安全性(WS-Security)、Web服务事务(WS-Transaction)等等)的概要随后也将发布。在产品全面、稳定且广泛地支持这些概要之前，开放标准的使用还没有得到保证，并且可能并不总是促进互操作性。

　　·是否需要支持基本通信协议及标准(例如WebSphere MQ、SOAP、WSDL)?或者需要更高级的功能(例如Web服务安全性(WS-Security)、Web服务事务(WS-Transaction)等等)?

　　对支持更复杂标准的需求将对实现技术的选择加以更严格的约束，并且可能意味着使用还不成熟的技术。

　　·当果考虑更改现有的基础架构使用的消息格式和协议(包括可能采用开放标准)时，需要在整个现有的基础架构中进行这些更改吗?或者很快就要应用新的消息格式和协议吗?如果正在使用或考虑使用EAI技术，该技术是否有自己的内部格式?或者它能够将开放标准处理为内部格式吗?

　　开放标准的任何应用都是受扩展访问的需求驱动的，因此它们对现有基础架构的接口的可用性比在内部使用的这样的标准更重要。

　　如果需要在内部使用特定的格式、技术或标准，这会给实现技术的选择带来限制。

　　·将作为服务公开的系统实现功能支持所需的技术或开放标准(比如SOAP、JMS或XML)吗?

　　如果不支持，ESB基础架构或适配器将需要在所需的开放标准和服务提供者支持的格式之间进行转换的功能。

　　·在需要访问遗留系统的情况下，通过使用更新的基于XML的技术，可以直接支持(例如CICS SOAP支持)遗留系统的可用性吗?是否需要单独的适配器?遗留平台是否支持XML处理?如果支持，这种处理是否可以灵活地使用平台功能?

　　如果因为这其中的任何原因而导致所需的SOAP或XML功能对遗留平台不可用，则需要在适配器(比如s J2C Connector Architecture (JCA) 或WebSphere Business Integration Adaptors)、集成层或ESB基础架构中使用适当的转换功能。

　　·如果EAI技术已经可用，它是否使用适当的功能或接口粒度将服务作为消息流实现?它支持哪些连接性协议(例如 JCA、SOAP、WebSphere MQ以及Java远程方法调用(Java Remote Method Invocation))?

　　如果现有消息流不提供所需要的服务，则需要另外的流程来执行转换。如果EAI技术不直接支持所需的标准，就需要添加一个网关组件。

　　·应该从服务客户端通道以工作负荷缓冲、安全、登录等形式提供给服务提供者系统什么保护措施?

　　这种缓冲通常是ESB基础架构的一个角色，并且定义它所需要一些功能。如果特定的服务提供者系统(例如遗留事务系统(legacy transactional systems))需要额外的保护，则可以使用专用集成层。

　　·应该实现多少服务?实现的什么方面应该在这些服务中保持一致?如何实施一致性(可能在多个平台上和多个应用程序中)?

　　如果只需要非常少的服务，简单的点到点(point-to-point)集成模型可能比较适合。然而，如果需要更多的服务或者过一段时间以后可能还是如此，则添加控制点(比如由ESB提供的)就变得愈加有益。

　　·服务交互包含在组织内部，还是有一些交互在组织外部?

　　这常常是不同于在单个组织中实现的ESB基础架构的一种情况，因为对安全和服务路由的需求可能与外部可用的服务不同。

　　·是否需要服务编排?服务编排是否涉及短期(short-lived)或长期(long-lived)(换句话说就是有状态的)流程，还是两者都涉及?它们是否包含人工活动?

　　在这些需求构成业务功能的情况下，应该在与ESB分离的Service Choreographer组件中实现编排。关于是支持长期有状态流程还是支持人工活动的需求将对实现技术的选择产生限制。

　　·基础架构应该支持什么样的服务级需求(例如，服务响应时间、吞吐量、可用性等等)?随着时间的推移，需要如何对其进行扩展?

　　一些候选的ESB实现技术相对较新，并且可能仅仅在有限的服务级进行过测试。同样，由于相关的开放标准不是最近制订就是正在兴起的，所以在更多的既定产品和技术中对它们的支持也是新出现的。

　　在可以预见的未来，关键的体系结构决策将专注于特定开放标准优点的平衡，针对服务级需求的新兴或成熟的产品技术支持这些开放标准。制订这些即时决策需要考虑到有些标准和支持它们的产品是相对成熟的(例如XML、SOAP等等)，有些(例如Web服务安全(WS-Security))比较新，还有一些(例如Web服务事务)是正在兴起的。

　　标准的优点之间的权衡和经过验证的服务级特征往往驱动一个结合了ESB与SOA体系结构中适应标准的、专有的或自定义技术的混合方法。

　　·是否需要点到点(point-to-point)或端到端(end-to-end)安全模型(例如，ESB是否可以简单的对服务请求授权，还是需要将请求者的身份或其他凭证传递给服务提供者)?是否需要使用应用程序或遗留安全系统来集成服务安全模型?

　　如果点到点安全性是可接受的，则许多现有解决方案(例如SSL 、对数据库访问的J2EE安全性、适配器安全模型等等)就能够得到应用。如果需要端到端安全性，则Web服务安全标准就成为可能，提供所有相关的系统来支持它。换句话说，您可以使用带有客户端消息头的客户端模型，或者传送像应用程序数据这样的安全信息。

　　结束语

　　本文确定了一些ESB实现中最常见的场景，以及对相应的解决方案直接产生影响的问题。虽然没有完全涵盖所有的隐藏问题，但这些是其中最常遇到的。

　　我们概述了从两个系统的基本集成到实现支持高质量服务和Web服务标准的SOA体系结构的常见场景。并描述了需要重视的十四个不同的问题：

　　·现有数据接口

　　·业务数据模型

　　·开放标准的使用

　　·对基本或高级通信协议的支持

　　·通过现有系统对数据传递格式的修改

　　·通过新技术公开现有服务

　　·对遗留系统的访问

　　·现有EAI技术

　　·需要的保护措施

　　·需要提供多少服务和需要的一致性程度

　　·公司内部以及与其他公司之间的互操作

　　·对服务编排的需求

　　·服务级需求的基础架构级支持

　　·点到点(point-to-point)或端到端(end-to-end)安全模型的使用

　　理解这些基本场景和问题为您开发可能的解决方案打下了牢固的基础。在本系列的第3部分，我将讨论本文中提到的实际解决方案。如下：

　　·基本适配器

　　·服务网关

　　·Web services Compliant Broker

　　·Service Choreographer

　　·用于SOA的EAI体系结构

　　·完整的SOA体系结构

　　最后，我将讨论组织考虑如何使用受控和增量的方式发展它们的体系结构时可用的选择。也将说明能够指导您开发自己的ESB路线的一些问题。