本文中的案例研究重点说明与开立新帐户服务的连接性相关的挑战和解决方案。其中描述如何使用“SOA 中的服务连接性场景”的实现模式来解决与该案例研究相关的业务和 IT 挑战。

　　案例研究：SOA 中的服务连接性场景

　　本红皮书是面向服务的体系结构 (SOA) 系列之一，主要通过名为 JKHL Enterprises (JKHLE) 的虚构公司阐述了一个案例研究。

　　本红皮书中的案例研究重点说明与开立新帐户服务的连接性相关的挑战和解决方案。本红皮书描述如何使用“SOA 中的服务连接性场景”的实现模式来解决与该案例研究相关的业务和 IT 挑战。

　　案例研究简介

　　JKHL Enterprises (JKHLE) 正在进行一系列的基本业务变更，期望最终能够获得最大收益。JKHLE 已决定采用 SOA 原则来解决其面临的业务和 IT 挑战。

　　JKHLE 团队的工作重点是在各个销售渠道中以一致的方式解决因创建新客户帐户而带来的难题。此 SOA 采用计划被称为帐户开立项目 (Account Open Project)。使用 SOA 方法有利于在未来业务发生变化时进行更快的实现和提供更大的灵活性。

　　注意：有关该案例研究的详细信息，请参考“案例研究：

　　SOA 帐户开立项目概述，REDP-4376”。

　　我们在本红皮书中介绍的案例研究包括以下关键人员和角色：

　　Edmund Smythe-Barrett，企业架构师
　　Sandy Osbourne-Archer，首席技术架构师

　　帐户开立项目的挑战

　　我们在本红皮书中定义的帐户开立项目挑战与“SOA 中的服务连接性场景”相关。

　　如“案例研究：SOA 帐户开立项目概述，REDP-4376”中所述，JKHLE 面临的挑战包括访问各种资源中的过时且复杂的应用程序，在某些情况下，甚至需要依赖基于纸张的业务流程。这些问题增加了处理新帐户的时间和成本，进而可能会对客户满意度带来负面影响。

　　帐户开立项目体系结构团队的工作重点是解决重大问题以及改变客户在开立 JKHLE 帐户时使用多种机制这一现状。他们希望从业务和 IT 这两个角度制定一种经过改进、单一的开立帐户机制。

　　帐户开立项目将成为用于 JKHLE 中的新 SOA 实现的第一个测试用例。

　　帐户开立项目的要求

　　帐户开立项目将分两个阶段实现：

　　第一阶段的要求
　　第一个阶段将把初始服务连接性 SOA 的概念引入帐户开立项目体系结构中。

　　第二阶段的要求
　　第二阶段将实现更多复杂的 SOA 解决方案。

　　第一阶段的要求

　　JKHLE 将把帐户开立项目用作在组织中实现 SOA 时的第一个测试用例。

　　首席技术架构师 Sandy Osbourne-Archer 对不断下滑的收入和利润表示担忧，迫切希望借帐户开立项目这一契机来解决此问题，以便使业务和 IT 目标能更好地与 IT 基础结构保持一致。

　　企业架构师 Edmund Smythe-Barrett 专门负责连接性问题。对于如何改变 JKHLE 环境这一问题，他有自己的一些想法：一是要实现一个更敏捷、更灵活的环境，二是要为帐户开立项目以及整个 JKHLE IT 环境带来直接、重大的好处。

　　Sandy 就此项目对 Edmund 提出了一些明确的要求，希望他能帮助满足。

　　REQ-01：实现多渠道访问

　　Sandy 希望能从组织中的多个渠道访问此新的帐户开立流程。因此，相同的流程必须能作为一项可调用的服务供从 JKHLE 办公室、Internet 和内部网以一致的方式进行访问。

　　注意：有关解决方案的详细信息，请参阅“向多个渠道公开现有系统”。

　　REQ-02：以安全、可靠的方式访问外部服务

　　帐户开立流程必须能以安全、可靠的方式访问外部服务，不需要为了进行外部访问而公开 JKHLE 基础结构。

　　注意：有关解决方案的详细信息，请参阅“网关——安全地连接到外部的第三方和业务合作伙伴”。

　　REQ-03：访问现有后端系统

　　帐户开立流程必须能够无缝地访问现有后端应用程序，但是当前任何一种机制都无法轻松做到。

　　注意：有关解决方案的详细信息，请参阅“使企业应用程序与 Web 服务相适应”。
　
　　REQ-04：允许多个内部客户端访问 Web 服务

　　JKHLE 组织由多个远程办公室构成，而这些远程办公室中许多都使用不同的标准。Sandy 希望能有一种统一的方式，供这些远程办公室在访问在总部运行的系统时使用。

　　注意：有关解决方案的详细信息，请参阅“基于开放标准的内部连接”。

　　第二阶段的要求

　　在满足了 Sandy 的初始要求之后，帐户开立项目将用于应对一些更高级的挑战。JKHLE 成功地实现了一个 SOA 解决方案，但是还想对此解决方案做进一步的改进。

　　Sandy 又对 Edmund 提出了另外四个要求。

　　REQ-05：基于可用性高效地访问外部系统

　　帐户开立流程利用第三方提供者进行信用验证。此第三方服务有时候会使响应时间超出可接受限制范围。

　　Sandy 希望通过一种更智能的方法，基于业务价值驱动的可用性以有效的方式访问外部服务。

　　注意：有关解决方案的详细信息，请参阅“业务价值驱动的服务可用性”。

　　REQ-06：在连接域之间进行灵活的通信

　　每个 JKHLE 连接域都计划实现企业服务总线 (ESB) 解决方案。一些 JKHLE 域自主运行，因此可以自由地选择任何 ESB 实现。将来的收购可能还会导致企业中的更多 ESB 实现。Sandy 希望对服务交互强制执行一些标准，通过这些标准让每个域都能自由地进行更改，而不会影响其他域。

　　注意：有关解决方案的详细信息，请参阅“ESB 联合”。

　　REQ-07：将业务流程与多种使用者和提供者应用程序集成

　　帐户开立业务流程需要调用各种后端系统，并接收来自多个渠道的调用。Sandy 希望此流程以及其他流程能够利用 JKHLE 环境中现有的 ESB 基础结构。

　　注意：有关解决方案的详细信息，请参阅“WebSphere Message Broker 和 WebSphere Process Server 交互”。

　　REQ-08：将更改对合作伙伴服务使用者的影响减至最小

　　随着 JKHLE 环境和服务的发展，他们希望确保业务合作伙伴的服务使用者经历最短的中断。

　　注意：有关解决方案的详细信息，请参阅“使用者端 ESB”。

　　将 SOA 实现模式应用于此案例研究：第一阶段

　　为准备 JKHLE SOA 的项目，Edmund 参加了许多 SOA 培训活动，包括深入学习在 IBM SOA 基础和 SOA 场景中获得的知识。Edmund 深信使用经验证的 SOA 实现模式可以为设计解决方案提供一个极好的入口点。Edmund 确定 JKHLE 可以利用“SOA 中的服务连接性场景”来满足帐户开立项目要求。

　　Edmund 向 Sandy 解释说，“SOA 中的服务连接性场景”中的许多模式都使用了 ESB。ESB 是一种逻辑体系结构组件，它提供了与 SOA 的原则一致的集成基础结构。ESB 提供了服务使用者与服务提供者之间的连接性，如图 1 所示。

　　图 1 ESB
 
　　ESB 提供的基本功能包括：

　　服务使用者与服务提供者之间的连接

　　使用者与提供者之间的交互是松散耦合交互。使用者只需知道关于提供者的很少量的信息就能连接到它。ESB 使连接更简单，同时使在将来更改使用者与提供者之间的连接方式更简单。

　　ESB 支持关注分离（separation of concerns）。ESB 通过在单个体系结构组件中提供所有松散耦合的连接功能说明了关注分离。

　　以下各项的服务虚拟化：

　　路由过程中使用的标识
　　服务使用者不需要知道目标服务的标识。ESB 可以确定目标服务的标识。

　　转换过程中使用的协议
　　服务使用者不需要知道该服务所需的传输协议。ESB 可以在使用者所用的协议与目标服务所需的协议之间进行协调。

　　转换过程中使用的接口
　　服务使用者不需要知道目标服务所需的请求或答复数据格式。ESB 提供了数据转换服务，可以在各种数据表示形式之间进行转换。

　　面向连接的安全性，管理，日志记录、审核等方面。

　　在第一阶段中，JKHLE 将使用“SOA 中的服务连接性场景”中的以下实现模式：

　　向多个渠道公开现有系统
　　网关——安全地连接到外部的第三方和业务合作伙伴
　　使企业应用程序与 Web 服务相适应
　　基于开放标准的内部连接

　　向多个渠道公开现有系统

　　JKHLE 中当前的连接性体系结构不能实现从不同的渠道轻松访问流程或应用程序。Edmund 希望使不同环境（如富客户端、Internet 浏览器和内部浏览器）中的用户能够以让每个使用者认为自然的方式访问帐户开立流程，而无需为各访问渠道设置多种不同的机制。具体来说，JKHLE 环境拥有基于浏览器的 Internet 和内部网用户，使用交互式语音响应系统的仅使用语音服务的用户，以及通过基于 Microsoft? .NET 的应用程序平台与客户服务代表协作的仅使用语音服务的用户。

　　封装不同访问机制的一种机制将使 Sandy 的其他体系结构团队远离 JKHLE 环境中使用用的不同样式进行访问的困境。

　　建议的解决方案

　　Edmund 建议使用 ESB 体系结构。ESB 可以与多个渠道进行交互，并且可以将各渠道中不同的消息类型转换为可以传递到帐户开立流程中的单一规范格式。图 2 显示了此体系结构。

　
　　图 2 建议的解决方案：ESB
 
　　Sandy 欣喜地看到虽然此体系结构增加了 ESB 组件处理不同的传输协议和消息传递格式的负担，但是对帐户开立流程并无影响。此体系结构还简化了将来集成更多渠道的工作。对于任何附加的渠道，只要首先在该渠道上配置 ESB，该渠道就能接收来自其他组件（如帐户开立流程）的调用。

　　还可以使用此 ESB 组件与其他后端流程进行通信，如“基于开放标准的内部连接”中所述。

　　Edmund 建议 JKHLE 在 IBM WebSphere? Message Broker 中实现 ESB。此解决方案中使用的多个渠道能够很好地实现 WebSphere Message Broker 的通用性。

　　网关——安全地连接到外部的第三方和业务合作伙伴

　　Edmund 面临着提供用于访问外部服务提供者的解决方案的挑战。帐户开立流程需要连接到外部服务提供者以对潜在的帐户持有者执行信用验证。由于之前曾饱尝负面影响之苦，JKHLE 对外部连接非常敏感。

　　Sandy 告诫 Edmund，她需要的是到一组固定的外部服务的安全、可控制并且可管理的连接。只有这样，首席信息官/首席技术官才允许她连接到外部提供商。

　　建议的解决方案

　　Edmund 找到了一个能够满足这组要求的理想的解决方案。他将自己关于 ESB 体系结构的想法扩展到包括一类新的集成 ESB 的设备。此外，配以适当的组件来提供服务的注册和存储功能，以及安全性和可管理性，此体系结构如图 3 所示。

　　图 3 建议的解决方案：Integration Appliance
 
　　此环境包括以下组件：

　　Integration Appliance
　　包含内置于 Integration Appliance 中的服务代理。服务代理可以执行以下功能：

　　使用服务的注册和存储功能确保只有经 JKHLE 体系结构团队批准的服务才能被访问。
　　中转服务请求，这样，从帐户开立流程中接收的服务请求未必是最终被调用的服务提供者。
　　Integration Appliance 还支持一整套 Web 服务安全标准，这些标准在与信用验证服务进行交互时是必需的。

　　鉴于 Integration Appliance with IBM WebSphere DataPower? XI50 支持 Web 服务标准以及 Web 服务安全性，Edmund 建议 JKHLE 使用它。

　　服务注册中心和存储库
　　定义经 JKHLE 体系结构团队批准的已注册的服务。IBM WebSphere Service Registry and Repository 提供了存储和管理服务元数据的功能，这些功能使人们更乐于实现此组件。

　　安全管理器
　　验证对信用验证服务的请求是否经过授权而提出的请求。此外，此组件还会验证信用验证服务作出的响应是否为对信用验证请求的有效响应。

　　尽管 Integration Appliance 提供了安全功能，但是 Edmund 仍建议将此组件用于集中的安全环境中。

　　Edmund 建议 JKHLE 使用 Security Manager with IBM Tivoli? Access Manager，因为它能提供企业级授权服务。

　　SOA 管理
　　监视服务调用。虽然 Integration Appliance 也提供了服务监视，但是 JKHLE 管理架构师要求集中的报告功能。

　　因此，Edmund 建议使用 IBM Tivoli Composite Application Manager for SOA 来监视 Web 服务调用。

　　Edmund 向 Sandy 解释说，帐户开立流程只需执行服务调用，Integration Appliance 将处理所有细节。Edmund 解释说，采用 Integration Appliance 的一些其他优势有：

　　Integration Appliance 可以定位到 JKHLE 安全隔离区 (DMZ) 中，因此能为 JKHLE 环境提供进一步的保护。Integration Appliance 是一种安全性得到加强的设备，是专门为处理到外部网络的连接而设计的。
　　Integration Appliance 包含一些特定的内置功能，可以防范一系列 XML 和 Web 服务攻击。

　　使企业应用程序与 Web 服务相适应

　　帐户开立流程需要连接到运行在 SAP? 和 Siebel? 这样的环境中的现有后端应用程序。Sandy 已提出要求指出，帐户开立流程不应知道对调用后端应用程序的机制。Sandy 还要求无需在后端系统中进行任何应用程序更改即可适应与帐户开立流程进行通信。

　　建议的解决方案

　　Edmund 建议使用一种将 ESB 用作帐户开立流程与后端应用程序之间的中间层的解决方案（请参见图 4）。

　　图 4 建议的解决方案：带有适配器的 ESB
 
　　此环境包括以下组件：

　　带有适配器的 ESB

　　ESB 接受帐户开立流程发出的服务调用，将其作为 Web 服务的 SOAP over HTTP 消息。ESB 使用合适的适配器将这些消息转换为后端系统能够理解的格式和传输协议，然后将这些消息发送到后端应用程序。

　　Edmund 建议说 IBM WebSphere Enterprise Service Bus 可以与此组件很好地配合。它还提供了对 Web 服务调用和 J2EE? Connector Architecture 资源适配器，以及 JKHLE 中要求此体系结构用于保存 IBM WebSphere Application Server 堆栈中的所有内容的组的支持。

　　注册中心和存储库

　　存储服务元数据。此组件可确保只有已注册的服务调用才能访问后端应用程序。此组件是由 WebSphere Service Registry and Repository 实现的。

　　服务监视

　　监视进出 ESB 的服务调用。因此，Edmund 建议使用 IBM Tivoli Composite Application Manager for SOA 来监视 Web 服务调用。

　　Edmund 解释说，此解决方案还能针对 JKHLE 环境中将来的更改提供保护。对于所需的每个附加的后端应用程序，可以向 ESB 中添加合适的适配器。

　　基于开放标准的内部连接

　　就构成 JKHLE 组织的许多远程办公室而言，他们面临着一个有待解决的紧迫问题。这些远程办公室在向 JKHLE 总部环境发出一组受控制的服务请求方面具有长期需要。虽然此问题与帐户开立项目并没有直接关系，但是 Sandy 希望作为迁移到 SOA 解决方案的一部分来解决这一问题。

　　这些请求中一部分是基于标准的服务请求，还有一些是使用了需要映射到基于 SOAP 的服务请求的 XML 语法。

　　这些请求都是在 JKHLE 内部作出的，因此，不会遇到前面提到的一些问题。但是，仍需要对这些服务请求执行一种级别的控制。因此，Edmund 希望确保部署了服务控制和管理功能。

　　远程位置的应用程序都是主流应用程序，使用各种 XML 语法作为其数据格式，使用 Java? Message Service (JMS) 作为其传输协议。然而，总部应用程序都要求使用 Web 服务协议 ——SOAP over HTTP。

　　建议的解决方案

　　Edmund 建议的解决方案如图 5 所示。

　　图 5 建议的解决方案：ESB、注册中心和 SOA 管理
 
　　JKHLE 远程办公室包括以下组件：

　　ESB

　　远程办公室所用的各种消息传递类型与 JKHLE 总部所用的 Web 服务格式之间的中介。Edmund 解释说，对支持 Web 服务和 JMS 的需要使 WebSphere Enterprise Service Bus 十分适合 ESB 组件这个角色。

　　SOA 管理代理

　　SOA 管理功能让 JKHLE 能够监视远程办公室的 Web 服务活动。Sandy 希望 SOA 管理功能处于 JKHLE 总部的控制之下，因此每个远程办公室都需要安装 SOA 管理代理，可以通过该代理将管理数据发送到总部域。

　　JKHLE 总部包括以下组件：

　　Registry and Repository

　　确保仅使用已注册的总部服务。这是通过 WebSphere Service Registry and Repository 实现的。

　　SOA 管理

　　SOA 管理数据的集中式存储库包含远程办公室的 Web 服务活动。监视服务调用的能力是通过 IBM Tivoli Composite Application Manager for SOA 提供的。

　　将 SOA 实现模式应用于此案例研究：第二阶段

　　成功完成第一阶段的实现之后，Sandy 和 Edmund 已基于服务连接性为 JKHLE 设计了一个 SOA 环境。在第二阶段中，JKHLE 迫切希望扩展 SOA 环境以利用一些高级服务连接性功能。

　　Sandy 和 Edmund 又对“SOA 中的服务连接性场景”使用了以下四种实现模式来帮助设计他们的解决方案：

　　业务价值驱动的服务可用性
　　ESB 联合
　　WebSphere Message Broker 和 WebSphere Process Server 交互
　　使用者端 ESB
　　业务价值驱动的服务可用性

　　Sandy 迫切希望最大限度地提高帐户开立流程的业务价值。为此，她希望重点从最大限度地降低成本和最大限度地提高满意度这方面入手。

　　Sandy 向 Edmund 解释说，帐户开立流程所用的信用验证服务中存在一个问题。目前，帐户开立流程可以直接连接到名为 CVCo 的外部提供商提供的信用验证服务。这一直接连接提供了一个低成本的解决方案，但是客户一直抱怨响应时间太长。Sandy 希望将响应时间缩短到可接受的限制范围内，这样一来就会带来更高的客户满意度。

　　当前环境

　　当前的体系结构通过 ESB 网关的实现帐户开立流程与信用验证服务之间的直接调用（图 6）。

　　图 6 当前环境：直接连接
 
　　请求消息从帐户开立流程出来通过 ESB 网关传递到信用验证服务。ESB 网关允许在 JKHLE 与 CVCo 之间建立连接，提供了服务代理、XML 防火墙和 Web 服务安全性。

　　Edmund 向 Sandy 解释了此体系结构能实现可变响应时间的原因。这一直接连接做法并未提供可供帐户开立流程进行连接的备用服务。它只能调用 CVCo 提供的信用验证服务。由于体系结构不适当和过时等原因，CVCo 服务可能会具有可变的响应时间。在此直接连接体系结构中，这些较长的响应时间会传递到帐户开立流程。

　　Sandy 向 Edmund 指出，虽然 CVCo 提供的服务有时候不可靠，但是它是成本最低的选项，而且在许多情况下，它确实能提供可接受的响应时间。其他服务提供商也提供了类似的信用验证服务，虽说这些服务能提供改进的、更可靠的响应时间，但是它们的成本更高。JKHLE 不愿意将这一成本更高的服务用于对每个客户进行信用验证。

　　建议的解决方案

　　Edmund 向 Sandy 解释说最好的解决方案就是在 CVCo 服务提供商的响应时间能够满足服务水平协议要求时继续使用它。当 CVCo 无法满足服务水平协议要求时，应选择名为 Verity 的另一家服务提供商。Verity 提供的服务价格相对较高，但是其性能更胜一筹。

　　使用此方法，JKHLE 可以提供业务驱动的解决方案。他们可以通过缩短对帐户开立流程的用户的响应时间同时最大限度地降低成本来提高客户满意度。他们可以通过仅在业务需要时使用较昂贵的 Verity 服务提供商来达到控制成本的目的。此解决方案可以使用 Verity 进行所有信用验证，同时提供了专门使用 Verify 服务的解决方案所提供的同样级别的客户满意度，从而实现了显著的成本节约。

　　Edmund 说明了如何使用动态路由将 CVCo 和 Verity 合并到新的体系结构中。CVCo 仍然是首选的服务提供商，但是在它不能满足预定义的服务水平协议要求时，应选用 Verity 服务提供商（请参见图 7）。

　　图 7 建议的解决方案：使用 ESB 进行动态路由
 
　　此环境包括以下组件：

　　其他信用验证合作伙伴

　　另外一个合作伙伴 Verity 致力于提供另一种信用验证服务。

　　ESB

　　支持动态路由。在运行时，ESB 利用注册中心来确定可用的提供商（达到预定义的可用性标准的提供商，定义特定的服务当前是否有超出上面定义的阈值的响应时间）。然后，ESB 可以选择达到可用性标准的信用验证服务，并通过 ESB 网关连接到此服务。

　　Edmund 建议在 WebSphere Enterprise Service Bus 中实现 ESB。它支持 Web 服务请求并且可以通过内置于 IBM WebSphere Integration Developer 中的中介来执行动态路由。

　　ESB 网关

　　除充当其提供服务代理、XML 防火墙和 Web 服务安全性的角色之外，还可以计算调用第三方提供者（CVCo 和 Verity）的响应时间。WebSphere DataPower XI50 提供了所有这些功能。

　　系统管理

　　通过 ESB 网关监视服务提供者的响应时间。

　　System Management 可以报告响应时间无法满足服务水平协议要求的情况，并在这种情形发生或清除时生成事件。

　　Edmund 建议 JKHLE 使用 IBM Tivoli Composite Application Manager for SOA 实现系统管理组件。IBM Tivoli Composite Application Manager for SOA 代理监视服务提供者的响应时间，并报告响应时间无法满足预期的服务水平协议要求或超过超时段的情况。IBM Tivoli Composite Application Manager for SOA 会在情况发生或清除时生成事件。

　　注册中心和存储库

　　包括两种信用验证服务的服务定义。注册中心还保存有基于从系统管理组件中接收到的事件的、关于每项服务的可用性的信息。

　　Edmund 建议使用 WebSphere Service Registry and Repository（对于 V6.1 之前的注册中心版本需要带有 SupportPac? SA04: IBM Tivoli Composite Application Manager for SOA Event Handler for WebSphere Service Registry and Repository）。

　　通过此环境，Sandy 可以了解到如何定义响应时间阈值，以及如何做到将请求仅发送到当前满足这些阈值要求的提供者。此解决方案应消除客户所经历的众多长响应时间，并且有助于提高客户满意度，同时最大限度地降低成本。

　　ESB 联合

　　JKHLE 拥有一种分布式结构，包括总部和多个较小的远程办公室。这使得组织需要使用多个域来构建。域可以基于业务部门、组织单元或地理位置。

　　Sandy 关心如何在这些域中提供最多的连接选项。每个连接域都需要能够自由地采用最优的 ESB 实现。Sandy 还关心将来的收购是否会为 JKHLE 带来更多 ESB 实现。JKHLE 需要通过一种机制来将潜在的异类 ESB 实现联合在一起。

　　Edmund 已经被指派了定义符合以下要求的解决方案的任务：强制执行一些服务交互标准，此外还能在域中提供对提供者和接口进行更改的自由性，并且不会影响使用者。

　　当前环境

　　图 8 显示了当前的 JKHLE 环境。

　　图 8 当前环境：直接连接
 
　　每个 JKHLE 远程办公室 (RO) 都能与在总部 (HQ) 域中运行的服务进行直接、点到点的连接。当运行在远程办公室中的应用程序要与运行在 HQ 中的服务进行通信时，将会发生以下交互：

　　远程办公室应用程序与远程办公室 ESB 进行交互。
　　ESB 从 Registry and Repository 中检索 HQ 服务的位置。
　　ESB 直接与 HQ 服务进行交互。
　　此解决方案在 JKHLE 运行良好，但是它未达到 Sandy 提出的能够轻松地适应 HQ 服务中所做的更改这一目标。如果 HQ 服务更改了其接口，那么每个远程办公室 ESB 都需要进行更新以考虑到这一更改。

　　建议的解决方案

　　Edmund 说明了如何对当前的 JKHLE 环境进行修改以满足 Sandy 的所有目标。通过在 HQ 域中引入 ESB 和注册中心，JKHLE 环境可以支持所有域中的松散耦合的动态路由（请参见图 9）。

　　图 9 建议的解决方案：ESB 联合
 
　　此环境包括以下附加组件：

　　HQ 域中的 ESB
　　远程办公室通过 HQ ESB 连接到运行在 HQ 域中的服务，而不是直接进行连接。Edmund 建议通过 WebSphere Message Broker 实现 HQ 域中的 ESB。这最大限度地增加了 ESB 可以使用的接口和绑定。

　　Edmund 说明了这一联合 ESB 体系结构的优势：

　　HQ 域可以自由地更改服务，而不会影响远程办公室。可以添加多个新提供者，可以定义新的绑定或接口，可以确定服务的版本。HQ 域中的 ESB 可以跟踪所有更改。因此，这些更改不会对远程办公室公开。
在当前环境中，如果远程办公室 ESB 不支持 HQ 服务的绑定或接口，那么远程办公室 ESB 就无法连接到 HQ 服务。在此建议的 JKHLE 环境中，HQ ESB 起到了适配器的作用：负责转换服务绑定和协议，并且允许远程办公室连接到这些以前不可访问的服务。
WebSphere Message Broker 和 WebSphere Process Server 交互

　　帐户开立业务流程需要与一系列异类服务进行交互，以满足入站和出站请求。将发出大量这些请求。

　　Sandy 解释说帐户开立流程有一些重要的连接性要求：

　　帐户开立业务流程需要接受来自多个使用不同的传输和数据格式的渠道的请求。

　　帐户开立业务流程还需要访问种类不断增加的 JKHLE 后端应用程序，这些应用程序中许多都不支持标准的服务接口。
当前环境

　　Edmund 解释说现有的 ESB 体系结构已经就位，可满足许多要求。此环境是作为“向多个渠道公开现有系统”的一部分而构建的。Edmund 向 Sandy 展示了这一图表，用于说明这一体系结构，并重点强调了帐户开立流程实际上是运行在 Business Process Server 中的（请参见图 10）。

　　图 10 当前环境：ESB 与 Business Process Server 提供者交互
 
　　Edmund 提醒 Sandy 说，WebSphere Message Broker 是用于实现 ESB 组件的，而 WebSphere Process Server 是用于实现 Business Process Server 组件的。

　　建议的解决方案

　　Edmund 提示 Sandy 说，“向多个渠道公开现有系统”这一模式的卖点之一是在将来能够非常简单地添加更多客户端。Sandy 提出的新要求是证明这一解决方案很好的机会。

　　通过使用 ESB 组件，帐户开立流程已能够接收来自多个渠道的请求。.Edmund 解释说通过使帐户开立流程成为 ESB 的使用者（以及提供者），还可以实现 Sandy 所要求的访问各种 JKHLE 后端应用程序。

　　每个后端应用程序都是作为提供者添加到 ESB 的，帐户开立流程是使用 ESB 进入这些应用程序的使用者。

　　使用此体系结构，帐户开立流程不必以后端系统自身的格式对它们进行访问。

　　Edmund 还推荐向此体系结构中添加 Registry and Repository 来存储服务元数据（请参见图 11）。

　　图 11 建议的解决方案：支持添加 Business Process Server 使用者和注册中心
 
　　在此建议的体系结构中：

　　帐户开立业务流程的实例（运行在通过 WebSphere Process Server 实现的 　　Business Process Server 组件中）是通过 WebSphere Message Broker 请求应用程序启动的。
　　帐户开立业务流程（运行在通过 WebSphere Process Server 实现的 Business Process Server 组件中）可以使用 WebSphere Message Broker 连接到服务提供者。
　　WebSphere Message Broker 使用 Registry and Repository 来获取有关 　　Business Process Server、使用者应用程序和提供者应用程序的服务信息。　　Edmund 建议在 WebSphere Service Registry and Repository 中实现这一注册中心。
　　Edmund 向 Sandy 解释说 WebSphere Message Broker 可以从中协调使用者应用程序所用的多种传输协议和数据格式，并将它们发送到 Business Process Server。此外，帐户开立流程还可以使用 WebSphere Message Broker 的高级转换功能访问大量提供者应用程序，包括基于标准的和基于非标准的。

　　使用者端 ESB

　　JKHLE 希望在 JKHLE 组织中发生更改时将这些更改对业务合作伙伴造成的影响减至最小。

　　外部业务合作伙伴是 JKHLE 业务的重要组成部分，Sandy 希望确保 JKHLE 服务的更改对业务合作伙伴的服务使用者产生最小的影响。Sandy 强调说在 JKHLE 服务发生更改时，合作伙伴应体验到最小的中断和最低的开发成本。

　　当前环境

　　图 12 显示了当前业务合作伙伴在访问 JKHLE 的行业服务提供者时所用的体系结构。远程应用程序不使用多渠道模式（如“向多个渠道公开现有系统”中所述），因为它们希望保留对发送、表示和处理服务请求的方式和位置的控制权。

　　此环境包括业务中的服务使用者和提供者之间的直接、点到点的连接。使用者和提供者之间的交互如下所示：

　　合作伙伴将说明如何进行连接的 WSDL 发送给 JKHLE 提供者。此 WSDL 包括服务和协议的硬编码地址。
　　合作伙伴仅能使用单一消息传递格式——SOAP over HTTP 来调用 JKHLE 提供的服务。
　　Sandy 解释说，她希望构建一个新的体系结构来解决以下问题：

　　JKHLE 需要能够自由地更改 JKHLE 提供者的物理位置，而无需与每个业务合作伙伴进行联系向他们通报这一更改。
　　JKHLE 还希望增加对更多协议的支持。目前急切的需要对 SOAP over JMS 的支持，将来会需要对代表性状态传输 (REST) 的支持。
　　JKHLE 希望对服务使用者进行注册并跟踪他们对 JKHLE 服务的使用情况。

　　建议的解决方案

　　Edmund 解释说所有 JKHLE 的要求都可以通过向 JKHLE 域中添加注册中心和存储库来满足（请参见图 13）。

　
　　图 13 建议的解决方案：添加注册中心
 
　　此环境要求所有服务使用者进行一次更改，以更新服务使用者应用程序，使其包括注册中心查找代码模块。此注册中心查找模块会对 JKHLE 注册中心和存储库进行查询，以找出有关他们要调用的服务提供者的信息。

　　注册中心和存储库将返回有关此服务的信息，其中包括服务端点地址、消息格式和服务器配置。服务使用者使用这些信息来调用 JKHLE 提供者。

　　此方法取代了当前的使用各服务使用者中的硬编码的信息来查找 JKHLE 服务提供者的方法。

　　Sandy 关注是否需要请每个业务合作伙伴更改使用者应用程序，而 Edmund 向她保证这一更改会是一次性更改，将省去业务合作伙伴的开发成本和长期中断。如果任何 JKHLE 提供者发生变化（通过支持更多传输协议或更改位置），那么注册中心和存储库将用这些信息进行更新，每个服务使用者将在运行时检索到新信息。不需要业务合作伙伴通过更改其使用者应用程序来反映这些更改。

　　Edmund 建议 JKHLE 通过 WebSphere Service Registry and Repository 实现注册中心和存储库。

　　总结

　　Edmund 已成功使用一组 ESB 体系结构模式向 Sandy 提供了她所需要的灵活、松散耦合的连接环境，为 JKHLE 组织提供一种灵活的业务流程。在支持帐户开立项目的同时，ESB 体系结构还提供了一个平台，此平台适用于 JKHLE 及其业务合作伙伴当前及将来的业务流程和应用程序。

　　JKHLE 已在一组通用的工具和中间件基础结构软件上实现了标准化，其中包括：

　　建模和组装：
　　IBM WebSphere Integration Developer
　　IBM WebSphere Message Broker 工具包
　　部署：
　　IBM WebSphere Enterprise Service Bus
　　IBM WebSphere Message Broker
　　IBM WebSphere DataPower XI50
　　IBM WebSphere Process Server
　　管理：
　　IBM Tivoli Composite Application Manager for SOA
　　IBM Tivoli Access Manager
　　控制：
　　IBM WebSphere Service Registry and Repository参考资料