这个系列文章的第 3 部分介绍了实现企业服务总线（Enterprise Service
Bus，ESB）的场景和解决方案，在此作者分析了第
2 部分概述的多个场景可能的解决方案。在第
1 部分中说明的总线工作角色提供了这些场景的基础。
下面继续这个系列来构建面向服务体系结构（Service-Oriented Architecture，SOA）的企业服务总线，现在我们来看一看第
2 部分（请参阅参考资料）中所描述场景的多种显而易见的解决方案模式。
以下的每个部分都描述了一种 ESB 实现方式的解决方案模式，除了基本适配器（Basic Adaptors）模式以外，其他的都是简单的点到点（P2P）解决方案。每个模式都提出了不同的使用现行技术的实现选择，同时也做出了正反两方面以及移植方面的考虑。
请注意每个解决方案模式的图示，它认为服务客户端与提供服务的系统是分离的。当然，在许多情况下，相同的系统或应用程序既可以是服务客户端也可以是服务提供者。图示并非是要排除系统作为单独的客户端和提供者的可能性，而是承认了相同的系统在不同的互操作中可以有两种不同的工作角色。在决定系统是作为客户端角色来选择、确认和调用服务，还是作为提供者角色来接收、处理和响应服务请求时，这个区别通常很重要。
本部分的解决方案模式有：
- 基本适配器（Basic Adaptors）
- 服务网关
- Web 服务兼容的代理（Web Service-compliant Broker）
- 面向服务体系结构的企业应用集成基础架构（EAI Infrastructure for SOA）
- 服务编排（Service Choreographer）
- 完整的面向服务体系结构的基础架构（Full SOA Infrastructure）
这种解决方案通过封装器或适配器技术来实现简单的点到点（P2P）服务集成，而不是真正的 ESB。这种技术通过
WSDL 定义的 SOAP 访问或者其他可互操作的产品技术（比如 IBM WebSphere®
MQ （MQ））来实现集成。如果这些技术没有为服务接口定义（比如 WSDL）提供本地模型，那么将需要使用自定义模型来实现
SOA 规范。
虽然设计比较简单，但是从该模式中可以获得的好处却不可低估。例如，通过 MQ 或 SOAP/HTTP 进行的直接集成仍然可以是松散耦合式的，尤其是互操作的特征是使用接口来声明时。在将来的某个时候，对于支持最初使用的集成技术的
ESB 基础架构，我们可以通过它来中断集成。还可以在进程级别的服务命名和寻址之上实现控制级别。
现在已经有各种各样的适配器可用，而且也可以通过开发工具或运行时技术来创建新的适配器。并能使其提供对 Web
服务规范和 企业应用集成（Enterprise Application Integration，EAI）中间件的支持。它也可以提供给多种不同类型的系统，包含最新的分布式应用服务器（J2EE
服务器（如 WebSphere），或者微软的 .NET 系统）、企业遗留系统（比如 CICS®）以及
Commercial Off-the-Shelf 软件包（比如 SAP 或 Siebel）。
图 1 说明了一般的基本适配器解决方案，包含了使用现有的
HTTP 和 EAI 中间件基础架构来支持新的集成。虽然本图描绘的是内部集成场景，但如果用 HTTP 来作为通信协议，或者使用某些
Internet 兼容的 EAI 技术（比如 MQ internet pass-thru），那么该解决方案同样可以应用于外部场景。
图 1. 基本适配器解决方案模式将现有 HTTP 和未修改的 EAI
基础架构描述为支持服务总线功能的某些方面
选择基本适配器的实现技术
以下是实现基本适配器的一些选择：
- 使用遗留系统或应用程序直接提供的 SOAP 或 EAI 功能。例如，IBM CICS 目前直接提供对
SOAP 的支持，以及许多系统和应用程序包能够支持 MQ 或 SOAP 接口。
- 如果用于提供访问的应用程序是用户自己开发的应用程序且运行于应用服务器环境，或者只要应用服务器运行时环境和应用开发环境能够用来给应用程序添加封装器。例如，WebSphere
Studio Application Developer 能够用来给部署于 WebSphere Application
Server（Application Server）的 J2EE 应用程序添加 XML、SOAP 或
MQ 支持。
- 如果这种支持不可用或不合适（例如， 如果 XML 转换不适合用来处理现有平台上的资源），那么可能需要其他的体系结构层，如图
2 所示。这可能是托管了与应用程序或遗留系统集成的适配器的应用服务器层。例如，Application
Developer Integration Edition 提供了 Java 2 连接器架构（Java
2 Connector Architecture，JCA）连接器技术来访问遗留系统（比如 CICS），并通过
WebSphere 运行时环境为其提供了 J2EE 和 Web 服务接口。
图 2. 执行 XML 转换处理的其他体系结构层
- 如果使用开发工具来创建自己的封装器，那么您可以增强工具提供的功能：通过创建一个框架或一组实用工具类来执行通用任务，比如安全性、日志纪录等等。然而，这种方法可能引起范围蠕变（scope
creep），并最终导致该框架实际上变成了用户开发的服务网关或Web
服务兼容代理。当定义框架提议的功能时，需要注意验证开发和维护的成本是否合适，以及转换为更复杂的模式是更不合适的。
请参阅参考资料以获取更多有关实现此模式的详细信息。
基本适配器剖析
从正面来说，这种解决方案模式对新的基本架构的需求最低或是根本不需要，并且使用的都是广泛支持的各种规范和技术。从反面来说，像安全、管理等功能都交给了应用程序或单个封装器的实现来处理。
由于该模式基于使用协同操作技术和开放式标准，因此将该模式移植到更复杂的体系结构也就相对比较简单。
模式替换
如果以上均不能满足集成的需求，或者存在一些附加功能或服务质量需求，那么封装器方式就可能满足不了需求。如果是这样，从逻辑上说下一步应该是服务网关。如果需要更高级
ESB 功能，则Web 服务兼容代理或EAI
Infrastructure for SOA 模式会比较适合。
这种模式代表了一种基本的 ESB 实现，接近于在第
1 部分中描述的“最低功能的 ESB 实现”。服务网关一般通过 SOAP/HTTP、MQ、Java
消息服务（Java Message Service，JMS）等来支持客户端连接，但是也可以通过诸如 JCA
或 WebSphere 业务集成适配器（WebSphere Business Integration Adaptors，WBIA）来对服务提供者支持更广泛的集成。网关组件为服务路由、协议转换以及安全担当着中央控制点的角色。
网关能够用来向客户端提供一致的服务命名空间（例如，以 URL 的形式为 SOAP/HTTP 服务提供命名空间），并可以向服务提供授权模型，实际上这些服务是由完全不同的系统通过多种协议来提供的。当需要向外部合作伙伴（比如客户端或供应方）公开服务时，网关所提供的这些功能便成为一个明显的需求。然而当需要对从应用程序到用多种系统和技术实现的功能的访问进行简化时，这些功能在单个企业内部也很有用。
一个关键的网关功能是将客户端支持的服务协议转换为提供方支持的服务协议。这些协议可以包括 SOAP/HTTP、MQ
或 SOAP/JMS、JCA、RMI/IIOP 等。候选实现技术的能力需要针对所需要的客户端和提供方协议来进行评价。
图 3描述了服务网关解决方案模式
图 3. 使用服务网关模式实现 ESB
选择服务网关的实现技术
服务网关解决方案模式可以用以下的方式来实现：
- 使用打包好的网关技术，比如 WebSphere Application Server Network
Deployment 或 WebSphere Business Integration Connection
提供的 Web Services Gateway。许多网关技术支持某些形式的中间件过滤器或处理器程序设计模型，以实现自定义增强功能。Web
Services Gateway 提供了一些可配置的中间件功能。它也支持基于 XML 的远程过程调用
Java APIs（Java APIs for XML-based Remote Procedure
Call ，JAX-RPC）规范中定义的 Web 服务请求/响应处理程序。
- 使用应用程序开发和最新应用服务器技术的运行时功能来实现自定义网关。这可能包含与前面基本适配器解决方案模式中所描述的相同类型的适配器。
- 如果需要更高级的功能，就应该考虑更复杂高级的 EAI 中间件，比如 WebSphere Business
Integration Message Broker。
- 这种模式的许多实现存在于遗留技术中，这些遗留技术通常没有使用 Web 服务技术。例如，许多组织构建了路由器事务，它对多种遗留事务提供了使用类似文本的（text-like）数据模型的简单接口。这种系统使用具有一些
XML 的可移植优点的自定义数据格式 ，从而有效地实现了网关模式。
服务网关剖析
从正面来说，尽管一些网关技术必须在有适当弹性的方式下部署，但这种解决方案仍然能够包含最低功能基础架构。对互操作协议和开放标准的重视也使基础架构所涉及的方面得以简化。大多数网关技术与许多其他接口类型（比如
RMI/IIOP 和 JCA）进行协同操作的能力，也应该能够减少其他连接性技术的部署。
然而，网关技术往往限制了对请求/响应和发布/订阅服务的简单一对一映射的服务处理。更复杂高级的功能，比如消息转换、消息相关性、消息聚集等都可能超出了网关技术所能提供的功能之外，或需要在自定义场景中进行网关技术之外的开发工作。
大多数 ESB 技术认可网关模式及其相关功能。有了这一点，互操作协议和开放标准的使用、网关功能的简化等任何移植到更高级的
ESB 基础架构的问题都不会太困难。
服务网关的替换模式
最显而易见的替换模式是Web 服务兼容代理或EAI
Infrastructure for SOA。当需求超出了网关所能提供的功能之外，或者超出了已打包的网关技术范围时，这些模式会比较适合。另一方面，如果实际涉及的服务非常少，那么简单的基本适配器解决方案可能比较合适。
这种解决方案代表了高级复杂的 ESB 实现，它提供了一个功能完整的 EAI 解决方案的所有功能，并且使用开放标准模型。通过特定场合的明确需求来定义需要什么级别的
EAI 功能，从而确定适合使用哪种 EAI 技术。 图
4说明了使用 Web 服务兼容代理的 ESB 实现。
图 4. 使用 Web 服务兼容代理的特性丰富的 ESB 实现
选择 Web 服务兼容代理的实现技术
Web 服务兼容代理可以使用的实现技术选择如下：
- 最可能用于这种解决方案的实现技术是能提供合适的 Web 服务支持的 EAI 中间件，比如 WebSphere
Business Integration Server。
- 如果 Web 服务支持主要是为了外部集成需要，则 EAI 中间件的专有特性可以在内部使用，并结合服务网关组件的使用来添加
Web 服务支持。
请参阅参考资料以获取更多有关实现此模式的详细信息。
Web 服务兼容代理剖析
这种实现方式的优点是在开放标准模型内提供了丰富的功能。然而，虽然 EAI 中间件技术是成熟的，但是该解决方案支持的开放标准，尤其是更高级的
Web 服务标准，比如 Web 服务策略（WS-Policy）和 Web 服务事务（WS-Transaction）还不够成熟。因此该场景最主要的缺点仅仅是不能简单地对所有情况都适用。
Web 服务兼容代理的替换模式
如果不能提供适当的 Web 服务支持，则服务总线（Service Bus）的需求可以通过EAI
Infrastructure for SOA模式用更加专有或定制的方式来实现，也许要与服务网关组件相结合以添加
Web 服务接口。另外，如果开放标准是最关键的需求，而且一些 EAI 功能（比如转换和聚集）能够在别处完成（也许是在应用程序或适配器内），则服务网关模式可能更合适。
出于本文一直讨论的原因，采用 Web 服务规范并不总是适合的。但是 SOA 原则却仍然可以应用于各种解决方案，这些解决方案既可以是专有的或自定义的技术，也可以是开放标准。
一个显而易见的方法已经被许多成功的实现所证实。就是使用 EAI 技术（但不排除其他技术）并结合 XML
来构建自定义的 SOA 基础架构。只要服务接口已经明确定义并有合适的粒度，EAI 中间件就能确保满足 SOA
的互操作性和位置无关性原则。
这种方式潜在的好处也意义重大，因为成熟的 EAI 技术全部的功能和性能都应用于 SOA 的灵活性上。这个优点既可以应用于为
SOA 实现新的且坚固稳定的基础架构，也可以应用于在现有基础架构上的实现符合 SOA 原则的应用程序。
用这种方法实现的 ESB 可以使用这些重要的开放式的，而且也是事实上的标准，并且从它们中获得好处。事实上，这确实是一种可以把这些标准广泛应用到现有
IT 基础架构中的方法，并且为将来更远的发展提供一定的基础：
- 许多 EAI 技术的应用非常广泛，尤其是在单独的组织中，以至于 EAI 技术和开放标准一样具有互操作性上的优点。
- 如果合适的话，可以使用 XML 数据和消息格式以帮助实现互操作性和平台无关性，就像 XML 在
Web 服务规范中帮助实现了这些优点一样。
- EAI 将很有可能支持一些形式的 Web 服务，因此可以在适合的场合提供开放标准接口，尤其是对于使用
document/literal SOAP 模型来公开所使用的 XML 格式的场合。另外，可以通过添加服务网关到该解决方案来提供这种访问。
- 有些时候，可以利用 Java 的平台无关性来提供客户端 API 包，这不但对于 J2EE 环境来说很有用，而且对于单独
Java 环境、支持 Java 的数据库环境以及其他很多场合也是如此。
- EAI 中间件可以支持其他的开放标准（比如 Java Messaging Service），这些标准也许不像
Web 服务那样广泛适用，但仍然有很多技术支持它们。
该方法是向完全开放标准的 SOA 基础架构发展的一个重要步骤。虽然从某种意义上说，至少应该考虑将其移植到
Web 服务标准，但这种方法是向完全开放标准的 SOA 基础架构发展的一个重要步骤。EAI 和 XML
技术的过渡使用至少提供了处理问题（比如接口粒度、公共数据模型与格式等）的方法，所有这些都是向前发展的重要步骤。
最后，再次强调这种方法的好处。成熟的 EAI 技术通过已被证实的性能、可用性以及可伸缩性等特点提供了极其丰富的
ESB 功能（流程和数据模型、转换、基于内容的路由、服务聚集和编排等等）。由于这些功能是最重要的需求，因此不借助
Web 服务技术而只使用 EAI 技术来实现 ESB，这从解决方案的核心上看是完全符合要求的，尤其是因为如果需要使用
Web 服务，可以在许多方面添加 Web 服务支持。
图 5说明了这种解决方案模式包含的组件。
图 5. 使用 EAI 中间件实现功能丰富的服务总线
选择 EAI 中间件模式的实现技术
EAI 中间件的选择取决于特定情况下所需的 ESB 功能与各种不同 EAI 产品（比如 WebSphere
Business Integration 家族）的特性。
设计活动的关键之处在于服务接口定义模型。为了遵循 SOA 原则，应使用直接的接口来定义服务。虽然有些
EAI 技术可能提供了这样的模型，但在其他的情况下，需要自定义解决方案。在实践中，这经常通过使用 XML
模式并结合服务身份确认、寻址以及业务数据来实现。然而，也有不使用 XML 的解决方案，比如某些服务网关模式的遗留系统的实现所使用的文本解决方案。
与数据模型无关的接口模型方面的功能，用于声明性地定义应该如何使用 EAI 基础架构的特性来调度服务请求和响应。应用程序需要一些机制以解释接口定义及适当的调用
EAI 基础架构。还有，这些机制可以通过 EAI 技术提供，可供选择的技术包括设计与开发规范的实施，或者框架
API 的使用。
框架 API 的开发和维护显然代价不菲，但是它比实施跨越多个应用程序规范要更有效。如果至少大多数连接到服务总线的应用程序都支持同一种编程语言（比如
Java）的情况下，这样的方法是最有效的。
业务数据模型的采用也同样需要选择，是采用基于 XML 的、专有的还是自定义的。由于存在很多普通的和具体于特定行业的
XML 数据模型，采用这些模型中的一种可能会有好处。然而，许多这种模型正处于向 Web 服务规范移植的过程中，如果考虑使用这种解决方案模式的原因是由于可用的
Web 服务技术出于某些原因而不适合使用，那么就不可以选择那些规范。最后，如果 Web 服务或其他基于规范的某些形式的访问需要使用这种自定义模式实现的服务，那么就既可以选择使用
EAI 技术提供的 Web 服务支持，也可以添加一个显式服务网关组件（如果它能够更好的匹配需求的话）。
EAI 中间件模式剖析
由于这种解决方案模式代表了重要的开发、实现和维护工作，所以需要慎重考虑。该模式的优点是它与 SOA 原则完全一致，这被反复证明对交付业务有益，并能够用成熟的技术实现，使之具备企业级的功能、弹性和性能。
该解决方案的成本主要有两方面。首先在于解决方案的最初实现和随后进行的维护，其次，在于移植工作，随着 Web
服务技术的成熟并日益引人注目，最终很可能需要采用开放标准的解决方案。
这种模式的采用是一个即时的决策，这个决策依赖于近期或中期的利益来证明是否值得进行必要的投入。投入的多少依赖于所使用
EAI 的现有级别，也依赖于附加定制开发的工作量多少。近期或中期的定义依赖于单个组织认为新兴的 Web
服务规范何时会足够的成熟，以满足他们功能性或非功能性的需求。
EAI 中间件的替换模式
Web 服务兼容代理模式是与
EAI 中间件模式相似的使用开放标准技术的实现方式。
这种模式由专用服务编排组件的实现组成。这种组件不是真正的 ESB，但是它通过多种协议（比如 SOAP/HTTP
或 MQ）支持对服务的连接性，这需要或隐含着 ESB 的存在。在有些场景中，这种支持足以对服务提供方和服务器请求方进行直接连接。但如果情况并非如此，ESB
可以通过本文描述的任何其他解决方案模式来提供。这就构成了完整
SOA 基础架构解决方案模式。
图 6说明了服务编排的实现。
图 6. 服务编排的实现
选择服务编排的实现技术
这种解决方案模式中要做的最重要的选择是，它所需开放标准的级别。有以下三个场景：
- 对服务接口和流程建模大规模地采用 Web 服务规范。
- 对服务接口采用 Web 服务规范，并结合使用专有的流程建模技术。
- 使用专有的接口和流程建模技术。
因为与流程建模相关的 Web 服务标准（首先是 Web 服务业务流程执行语言（Business Process
Execution Language for Web Services，BPEL4WS）是最近出现的，为此支持它们的产品还不够成熟，因此这些问题与该解决方案模式特别相关。大多数服务编排技术的提供商都将提供专用的及基于标准的混合技术。例如，这样的技术包括：
- WebSphere Enterprise Process Choreographer 技术提供了对
Web 服务接口和流程定义的支持。
- MQ Workflow 提供了对更成熟但更专有的服务编排技术的支持，该技术既有 Web 服务接口也有专有接口。
如果采用专有技术，也许为了解决可伸缩性或弹性需求，可以添加服务网关组件以提供
Web 服务连接性。如果选择 服务编排技术不能为服务提供方（例如，遗留系统或应用服务器）提供充分的集成，那么就需要一个遵守其中一个其他解决方案中的
ESB。
服务编排剖析
这种解决方案模式很大程度上依赖于基于规范的或专有的解决方案是否实现。基于规范的解决方案目前还不太成熟，但它最终将能够提供更好的互操作性。专有解决方案将可能在较为熟悉的模型中提供可伸缩性和弹性，还可以充分利用高互操作性的通信技术（比如
MQ）。但是，随着开放标准技术的成熟和蔓延，这种方案可能最终还是需要一些移植工作。
这种模式代表了服务编排组件与服务总线实现的结合。因为这两方面在本文的其他部分已有描述，在这里就不更多的描述了，只是说完整的实现显然是可能的。一端采用完全专有解决方案，它使用
ESB 和专有服务编排技术的EAI
Infrastructure for SOA模式，另一端采用完全开放标准的解决方案，它使用 ESB
以及适应开放标准的服务编排技术的Web
服务兼容代理模式。
本文描述的模式都涉及到从即时需求构建 ESB，这仅仅是朝更复杂的 SOA 实现前进的第一步。这一部分讨论一些有用的选择，用于组织考虑如何以受控和渐进的方式发展。我不建议所有的组织都采用一种路线，相反，我想讨论一些在设计
SOA 或 ESB 路线中应该考虑的问题。
确定所涉及的直接范围
简单说来，实现综合性的 SOA 主要存在两个方面：全功能、有弹性的基础架构的实现和所有相关功能以服务的形式跨业务地公开。虽然还不是完全独立，但两个方面之间存在一定程度的松散耦合，这使组织可以比较灵活的选择如何实现它们。
在某些方面，第一个决策就是是验证 ESB 技术，还是验证功能性体系结构的 SOA 原则？这个问题引出了两个极端的方法：
- 丰富的基础架构，受限的功能-- 在这里，主要涉及的是验证这些技术的功能。基础架构很可能包含复杂的
ESB 功能（开放标准的或专有的），并可能构成完整
SOA 基础架构解决方案模式。但是这种技术上方案含有高风险性，并可能含有相对不成熟的技术。因此，不要用它去实现关键的业务项目或功能。功能以服务的形式公开既具有低危险性，又主要通过可选通路保持传递。随着基础架构功能的验证和成熟，服务以后将移植到基础架构。
- 基本的基础架构，丰富的功能 -- 在这里，主要涉及的是业务功能以服务的形式公开，这样就可以用新的方式访问或组合这些功能以传递业务价值。在这种情况下，预计的业务利益或其他因素驱动的改变往往变得非常重要，以降低技术风险。因此，基础架构的实现或者仅使用最基础最成熟的
Web 服务规范，或者使用更确定的 EAI 技术。一旦基础架构适当且支持服务互操作性，它的功能今后可以随着
ESB 技术的成熟而升级或移植 。
当然，还有两个其他的极端方式 -- 什么都不做，或者马上着手做每件事，但这些可能对路线的观点不感兴趣。
另外一个的方法在无形地使用。那就是单个部门、项目或工程渐进地采用 SOA 和 ESB 原则、技术和基础架构。许多组织在
ESB 或 SOA 的进程中，可能使用的是这种方式而不是直接了当的方式。这种局部采用专门技术或实践的方式可以对其提供更成功的检验，这比大爆炸（big-bang）方式要好得多。这与丰富的架构，受限的功能方式比较相似，但它由许多基本的架构组成，而不是单个丰富的架构。
实现 SOA 的方法有两个方面应该在早期确定：对服务的内部或外部访问的提供，和一个解决服务粒度的方法。
支持内部或外部访问的决策将驱动一些因素，包括需要什么级别的服务安全性（请参阅影响
ESB 的安全问题），以及是否需要显式服务网关组件以控制外部访问。正如EAI
Infrastructure for SOA 解决方案模式中所讨论的，外部访问也驱动了 Web
服务规范的使用。然而内部访问可能更具灵活性，比如 MQ、RMI/IIOP、或专有 XML。
服务粒度问题已经在业界被广泛地讨论（请参阅参考资料）。综合性的
SOA 可能包含多种粒度的服务，从技术操作性的功能（比如登录、记账等），通过业务功能（比如查询账目结算），到业务处理（比如处理库存订单）。
每个粒度级别的服务都由更低粒度级别的服务或其他功能组成。因此，需要考虑一些不同等级的服务聚集或编排，它可能适合不止一种实现技术。在任何特定情况下都可以处理该问题的一个实用方法就是，确认、特征化以及对可用的不同服务粒度级别进行命名。然后就可以在两个不同粒度级别之间定义聚集或编排需求，并选择适当的实现技术。
本部分的最后，值得注意服务实现的自上而下（top-down）和自下而上（bottom-up）模型之间联系。自下而上方法专注于以服务的形式实现应用程序和遗留系统的功能。在一般情况下，这涉及使用适配器和开发环境来提供合适的接口，并导致相对细粒度业务功能的启用。
自上而下方法则更多涉及到解析业务系统和组件以确认流程和服务的体系结构处理。这个趋向于确定了粗粒度的服务，而这些粗粒度服务可能是由更多的细粒度服务组成的。
许多组织可能会将这两种方法都加以运用以进行服务确认和启用，某种中间汇合点需要来合并他们。如果这种汇合点在约定的地方明确地对多种粒度级别的确认和分类，那么它对于技术人员来说可能更加简单。
SOA 的重要阶段
无论选择那种方法来实现完整的 SOA，都必须经过许多阶段。这个部分指出和讨论了其中的一些重要阶段。由于它们在很大程度上独立，并且它们实现的次序依赖于影响单个组织的很多因素，因此并没有对它们排序：
- 基于标准的安全模型-- 虽然简化的或专有的模型可能在短期内可以满足需要，但综合性的
SOA 必须具备全面且开放标准的安全模型。理解哪些支持 Web 服务安全规范的产品能够满足组织的需求，这是整个实现计划的关键部分。
- 启用服务遗留系统和应用程序-- 现代应用服务器（例如，J2EE 服务器比如 Application
Server）的发展让组织能够使用 SQL 和 JDBC 或 ODBC 接口来访问数据库。同样，SOA
的发展将驱动组织能够对遗留事务和应用程序功能进行基于服务的访问。因此组织可以计划定义和实现用最适当形式的服务来启用每个系统。可以选择利用
XML 或 Web 服务支持、使用适配器（比如 JCA 适配器）或者使用 EAI 网关技术提供遗留系统连接性。
- 实现高质量服务基础架构 -- 到目前为止，可利用的最成熟的 Web 服务支持对不可靠的通信协议（SOAP/HTTP
规范提供了更高质量的服务，比如 Web 服务可靠消息传递（WS-ReliableMessaging）或
Web 服务事务（WS-Transaction））还没有广泛的支持。目前需要使用 EAI 技术来为
SOA 提供更高质量的服务。从长远来看，组织应该在对新兴规范的支持和对符合 Web 服务规范的 EAI
技术的加强这两方面保持平行发展。
- 确定的服务粒度级别-- 如上面确定所涉及的直接范围部分强调的那样，确定与
SOA 相关的粒度级别以及各级别间的聚集和编排是非常关键的。每个粒度级别（例如，技术性功能、业务功能、业务流程等）的实现和相关的编排也构成了一个关键的里程碑。
SOA 实现步骤
以下问题在前面两部分已经讨论过，您现在可以构成 SOA 和服务总线实现的一般路线：
- 决定 SOA 技术或 SOA 功能的哪些元素应该优先实现（请参阅确定所涉及的直接范围）。
- 指定或定义合适的项目来实现第一个解决方案，这既可以是技术试验、业务试验，也可以是存在可接受风险的真实业务项目。
- 指定 SOA 中那一个 ESB 场景可以用于项目。更多关于驱动
ESB 体系结构和设计决策的问题和ESB
功能模型的需求分析。然后基于这些分析选择一种解决方案。基于更多的分析以及安全和非功能性需求（请参阅影响
ESB 的安全问题），最后选择一种合适的实现技术。
- 与这个工作并行的是，开始规发从第一个实现到完全综合性的 SOA 发展的路线。这项工作依赖于最初试验的重点，并包含基础架构技术性功能的多个方面，或启用其他功能性服务来利用最初的试验。在这两种情况下，路线都应该包含在上面指出的SOA
重要阶段。
在最初项目范围之外，还可以计划在其他几个方向上的发展：
- 发展和提高跨组织的数据模型和流程。
- 实现应用程序阶段服务，并将其纳入基础架构。
- 发展 SOA 基础架构的技术性能力。
本系列到此结束。在这个系列中，说明了如何从体系结构的观点上最好地使用 ESB。将来，随着 SOA 之后的技术的发展，您将看到
ESB 的使用和解决方案得到更深入的研究。
| 
