为准备 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 提供的。