成功完成第一阶段的实现之后，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参考资料