本文中的案例研究重点是与 SOA 服务创建和重用相关的挑战和解决方案。在本文中，我们将介绍如何使用关键方法和选项来利用现有的 IT 资产并通过 SOA 接口加以重用，还将介绍如何为新的和现有的资产构建服务，以确保它们可以用于未来的 SOA 工作。本文描述了如何使用“面向服务的体系结构中的服务创建场景”的实现模式来解决与该案例研究相关的业务和 IT 挑战。

　　案例研究简介

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

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

　　注意：有关该案例研究的详细信息，请参考案例研究：SOA 案例研究，第 1 部分：项目启动。

　　我们在本文中介绍的案例研究包括以下人员和角色：

　　Sandy Osbourne-Archer，首席技术架构师
　　Edmund Smythe-Barrett，企业架构师
　　Kai Buser，集成架构师
　　Willy Sheng Duo Li（也叫 Willy Li），应用程序开发员
　　Ursula DeBarry，软件架构师和服务设计主管
　　Eugene Testrite，质量工程师经理

　　帐户开立项目的挑战

　　我们在本文中定义的帐户开立项目挑战与重用作为服务公开的现有应用程序组件、创建新服务和使用服务相关。

　　Willy Li 是一位应用程序开发员，在其职业生涯之初的前一份工作中，积累了大约两年的 COBOL 编程经验。后来，Willy Li 继续着他的事业，并在 C、C++、Microsoft? C# 和 .Net 方面锤炼了自己的编程技巧。最近，他又开始了 Java? 编程工作。他从未想到以前的 COBOL 经验会对他当前的工作大有帮助。

　　在 Willy Li 以前的工作中，他完成了对 Java Web 服务的试验并研究过 SOA 的基本原理。Willy Li 深信，在今后的几年中，整个行业将转向 SOA，所以他准备将职业重点放在 SOA 上。遗憾的是，由于政治原因，他以前雇主那里的 SOA 开发搁浅了，因此，他又去寻找其他的机会。在了解到 JKHLE 中 SOA 的采用情况后，Willy Li 加入了 JKHLE。

　　Willy Li 被分配到了新组建的帐户开立项目中，该项目由首席技术架构师 Sandy Osbourne-Archer 领导。Sandy 最近派 Willy Li 主持工作，负责服务创建的开发和对现有应用程序的重用。

　　JKHLE 有许多应用程序运行在现有的系统上，如 CICS? 和 IMS?。因此有必要利用现有系统中的这些资产，以便缩短时间、降低成本。

　　Wily 当时非常担心对他的工作要求。Willy Li 坦言，“我对 CICS 和 IMS 一窍不通，对 COBOL 的了解也是很久以前的事”。Sandy 劝他说：“别担心，大多数情况下，我们不需要修改 COBOL。在某些情况下，当现有的代码与业务功能不匹配时，这时我们才需要重构代码”。

　　在重构现有代码方面，可以使用 IBM? WebSphere Studio Asset Analyzer 加强对现有应用程序和资产的理解。当进行重构时，可以像我们在以下部分中介绍的那样，启用应用程序的业务功能。

　　IBM 将为 CICS 和 IMS 同时提供适配器，并且新版本支持将现有的应用程序作为服务公开。这些访问方法可以在一定程度上提供屏蔽，使您不受 COBOL 和后端系统的影响。Sandy 向 Willy Li 解释说，Willy Li 对 SOA 的背景和理解对该项目非常有用。此外，企业架构师 Edmund Smythe-Barrett 和其他架构师还将提供有关 SOA 采用的全局方案。

　　在初次会面之后，各团队领导以非正式方式讨论了他们新分配的任务。Edmund 将讨论他针对企业服务总线 (ESB) 和服务注册中心的计划，并提供对整个基础结构中已计划服务的访问。由于 Willy Li 曾经在前一雇主那里做过 Web 服务试验方面的工作，因此他能够很快看出，与直接链接这些服务的刻板方法相比，使用 ESB 的服务可以提高灵活性。

　　Ursula DeBarry 是一名软件架构师和服务设计主管，负责设计用于访问和处理信息的服务接口。Ursula 解释，服务设计团队需要一些时间为所需的服务定义准备规范。根据帐户开立项目制定的计划，Willy Li 已经急切希望尽快开始工作，并能做出一些成果出来。

　　Willy Li 决定，他将通过为后端系统所需的每个访问方法开发服务原型来缩短学习过程。Willy Li 知道，当服务设计团队公布其服务设计规范时，需要更改其原型服务。

　　帐户开立项目的要求

　　Willy Li 安排与 Edmund 会面，以审核和讨论该原型实现的要求。Willy Li 尽力确保这些要求体现出公开和使用帐户开立项目服务所需的访问方法。

　　REQ-01：使用外部服务

　　帐户开立应用包括的流程需要使用外部第三方服务（如地址验证服务）。

　　REQ-02：创建新服务

　　这些服务接口将以 Web 服务描述语言 (WSDL) 文件的形式提供。WSDL 将为所有服务提供一个通用描述形式，实质上对服务使用者隐藏了实现细节。Willy Li 计划根据 WSDL 文档创建一些新服务。

　　REQ-03：将 CICS 应用直接作为服务公开

　　将 CICS Transaction Server v3.1 托管的 COBOL 应用程序作为服务公开。Willy Li 了解到 CICS v3.1 包括对 Web 服务的本机支持和工具，这简化了该要求，因此，将很少需要甚至不需要编程。

　　REQ-04：将 CICS 应用间接作为服务组件公开

　　Willy Li 了解到，一些旧的 COBOL 应用程序仍由 CICSTransaction Server v2.3 托管，它不包括直接启用 Web 服务的本机功能。此外，JKHLE 需要通过 Java 代码、CICS 适配器和 CICS Transaction Gateway (CTG) 来公开由 CICS Transaction Server v2.3 托管的 COBOL 应用程序还有其他一些原因。这将使 JKHLE 内部系统和外部合作伙伴能够将该应用程序作为一项服务来使用。

　　REQ-05：使 WebSphere Message Broker 流支持服务

　　作为支持电子业务的一部分，JKHLE 在WebSphere? Message Broker上进行了一些投资。它是一个企业应用程序集成基础架构，用于连接 IMS、SAP? 和 Siebel? 应用程序。JKHLE 想通过使 WebSphere Message Broker流（该流提供与基础结构相关的服务）支持服务来使用和重用在 WebSphere Message Broker 中进行的投资。

　　REQ-06：使 IMS 事务支持服务

　　使 IMS 事务支持服务可将这些事务作为服务使用。JKHLE 公司想利用他们在 WebSphere Application Server 和 WebSphere Message Broker 中的现有投资。

　　中间层服务将用来与 IMS 后端系统通信。

　　将 SOA 场景模式应用于案例研究

　　本部分描述了如何使用“面向服务的体系结构中的服务创建场景”实现模式来解决与帐户开立项目案例研究相关的业务和 IT 挑战。

　　使用外部服务
　　创建新服务
　　将现有应用程序作为服务直接公开
　　将现有应用程序作为服务间接公开
　　使 WebSphere Message Broker 流支持服务
　　使 IMS 事务支持服务
　　使用外部服务

　　注意：使用外部服务非常方便，并且很少需要甚至不需要编码，特别是当服务符合 WS-I.org 概要时。还有其他一些注意事项（如，当所选服务临时不可用时提供备用服务），多数情况下使用 ESB 很容易解决。

　　还需要为其他管理域中提供的服务进行一些计划。

　　帐户开立流程应用程序需要对新的帐户拥有者进行地址验证。JKHLE 组织确定，使用外部服务提供商来验证地址比构建和维护内部应用程序要好得多。Willy Li 将进行调查，并作为原型使用 AddressesInc.com 外部服务中的 VerifyAddress 服务进行地址验证。

　　建议的解决方案

　　Willy Li 通过将 WSDL 描述导入 IBM Rational Application Developer 中预览了 AddressesInc.com 中的 VerifyAddress 服务，他以前使用 IBM Rational Application Developer 生成了一个带有简单用户界面的 Web 服务客户端应用程序，该界面不但简单好用而且比较对于用户来说感觉比较熟悉。

　　在创建原型时，Willy Li 遇到了几个难题。一个问题是，VerifyAddress 的正式版本需要使用安全套接字层 (SSL)。JKHLE 还希望避免直接链接到任何服务，以免导致不灵活的基础结构。因此，JKHLE 将 ESB 用于与所有服务的交互，并将通过使用 IBM WebSphere Message Broker 来实现 ESB 功能。

　　Willy Li 与 Edmund 会面，计划在 JKHLE 的业务流程中使用此外部服务。Edmund 说，他们需要做的就是更新 ESB 服务注册中心（通过使用 IBM WebSphere Service Registry and Repository 来实现），将一个入口添加到此外部服务，然后这项服务就可以使用了。

　　还需要更新服务注册中心，以便包含该服务的元数据。

　　由于 JKHLE 和 AddressesInc.com 在不同的管理域中，可能需要进行一些计划或协商，以确保达到 JKHLE 所需的可用性和吞吐量。AddressesInc.com 是一家具有良好声誉的可靠提供商，但是，由于此服务对于业务流程非常关键，所以计划服务在不可用的时间非常重要，即使这种可能性未必存在也需要进行计划。

　　Edmund 解释说 ESB 将有效地虚拟化该服务。当一个服务使用者向 ESB 发送请求时，该服务使用者将得到一个回应。必要时，ESB 可以在运行时决定是否使用备用提供商。当备用服务具有不同的消息 schema 时，ESB 可以将该请求转换为所需的 schema，代表使用者发出请求，并将该响应转换回用户所需的形式。整个流程对请求者应用程序（如业务流程）是透明的。Edmund 和 Willy Li 对使用外部服务的 ESB 方法非常满意。

　　工作方式

　　图 1 描述了外部服务的使用方式。JKHLE 计划通过 ESB 从业务流程中调用该服务。WSDL 是进行该调用所需的一切要件。IBM Rational?Application Developer 可以读取该 WSDL，生成一个服务代理对象，并测试该应用程序，从而使 Java 开发人员将重点放在业务逻辑而非 XML 细节上。

　　ESB 接收该请求并使用 IBM WebSphere Service Registry and Repository 来查找适当的提供商。ESB 使用 HTTP 或 MQ 协议来接受该请求和执行协议转化，以便在该提供商需要该服务时通过 SSL 调用它。如果使用备用提供商，ESB 可以在需要时向使用者应用程序或业务流程透明地转换该请求消息。

　　图 1 使用外部服务
 
　　AddressesInc.com 或备用提供商以期望的形式接收该请求、处理该请求并发送响应。如果需要，ESB 将转换该响应消息并使用适当的协议将其路由到该服务使用者。

　　使用外部服务的注意事项

　　有时，一些业务合作伙伴可以更好、更快、更便宜地为您完成某些工作。JKHLE 没有地址验证业务，它发现维护自己的服务要比使用由 AddressesInc.com 提供的服务昂贵得多。

　　创建新服务

　　尽管 AccountEligibility 服务并没有完全设计好，Willy Li 还是访问了记录以前讨论的文档，这为他提供了有关所需接口的一些好的想法。该服务的基本功能是根据记帐数据（如过期未付余额日、拒付款和最终结帐日）决定是否需要信用报告。适当性决策将应用于帐户验证业务流程中。

　　虽然 JKHLE 业务要求与在 CICS 上托管的现有 COBOL 中的此功能有某些相似之处，但它已有了相当大的发展。

　　根据服务设计团队提供的建议和 Willy Li 本人的经验，他决定，最好创建一个新的基于 Java 的 Web 服务。

　　建议的解决方案

　　Willy Li 从以前的经验中得出，IBM Rational Application Developer 中包含的工具和测试环境可以使其创建新服务的工作变得更加轻松。为了解这些服务设计方面的知识，Willy Li 决定使用 IBM Rational Software Architect，该体系结构包括 Rational Application Developer 功能和用于设计的建模工具。Willy Li 将从创建一个新的 UML 设计开始，这包括协议、有效负载格式、非功能性需求等。

　　在过去，Willy Li 采取自底向上的方法，即创建一种 Java 方法，然后生成与该方法参数和类型匹配的 WSDL 接口。对于原型，他决定使用自顶向下的方法，这样，他可以先在 Rational Software Architect 中创建一个 WSDL 文件。Willy Li 知道，服务设计团队将在完成规范后针对实际的项目要求向他提供 WSDL 定义。

　　Willy Li 将使用 Rational Software Architect 中的工具从 WSDL 中生成 EJB? 代码来创建新服务。还将生成映射代码以解析 SOAP 请求消息，因此，EJB 可以看到 Java 形式的消息并在 SOAP 中生成从 Java 返回的响应消息。

　　开发人员无需 XML 知识就可创建服务。具体的工作（如查询记帐）是标准的 Java 编程。

　　可以使用 Web 服务向导来生成简单的测试应用程序来实验该服务。当 Willy Li 在 Rational Software Architect 测试环境中通过向导生成的接口对该服务进行单元测试后，他将代码 Check-in 到 IBM Rational ClearCase 中，后者已与 IBM Rational ClearQuest 集成。ClearQuest 中的工作流将向质量工程师经理 Eugene Testrite 发出提醒，指示新服务可用于测试。此外，Willy Li 还将向 IBM WebSphere Service Registry and Repository 发布服务。

　　Willy Li 将与 Eugene 联系，讨论其原型设计工作和测试要求。原型设计为质量工程师提供了在测试要求和方法体系早期提高速度的机会。Eugene 的质量工程师团队最终将测试 JKHLE测试环境中的服务，在通过测试之后将更新该服务注册中心的状态。

　　Eugene 非常激动动地告诉 Willy Li，他的团队可以通过使用 IBM Tivoli? Composite Application Manager for SOA 为 Web 服务使用者、提供商和 ESB 中介提供性能和使用标准测试。Willy Li 急于了解如何使用 IBM Tivoli Composite Application Manager 来帮助更好地了解应用程序开发中的性能瓶颈，以及如何在生产环境中使用它，以确保能够监控服务水平协议 (SLA)。

　　工作方式

　　如图 2 中突出显示的那样，有几种方法可用来创建新服务。该模型可以通过使用 Rational Software Architect 在 UML 中实现。Java 类可以从 UML 中生成。接下来，可以从该 Java 类中生成 WSDL，然后进行应用程序测试。这可以确保服务契约与 WSDL 文件精确匹配。

　　图 2 创建新服务
　
　　此外，WSDL 文档还可以在 WSDL 编辑器中创建，并且从 WSDL 中可以生成一个 Java 类框架。后一方法允许开发人员根据需要创建服务契约和匹配的 WSDL。

　　Web 服务向导提供使类支持服务的能力，方法是通过创建 SOAP 处理程序以执行对 SOAP 消息的 XML 解析，并在必要时创建一个 WSDL 描述。

　　创建新服务的注意事项

　　创建新服务的关键注意事项：

　　现有的应用程序不支持功能性访问要求
　　现有的应用程序不适合作为服务使用
　　开发人员通常会直接得出结论，认为编写新代码比重用现有资产更容易，特别是当现有资产是使用不熟悉的现有技术或第三方技术构建时更是如此。不过，当有可用的适配器或连接器时，或者当应用程序可以作为服务直接公开时，重用现有的资产实际上将非常快、而且很方便。重用现有资产还会大量减少代码的编写、测试、维护和更改。

　　当现有的资产经过验证而且可靠，特别是正在使用时，重用现有资产更有实际意义。在以下部分中，我们将讨论重用由 CICS Transaction Server 和 IMS 托管的现有应用程序的方法。这些概念还可应用于其他现有的应用程序和企业信息系统 (EIS)。

　　将现有应用程序作为服务直接公开

　　注意：许多现有应用程序平台和企业信息系统提供了将现有应用程序功能作为服务直接公开以供重用的能力。此方法一般很少需要或根本不需要编程，这就极大地减少了开发与测试的时间与成本。

　　即使那些对现有应用程序或企业信息系统（如 CICS）不太懂或者根本不懂的开发人员也可以利用向导轻松地将现有的应用程序功能作为服务公开。

　　JKHLE 有许多后端 EIS 系统，这些系统每天运行着许多业务应用程序。特别是，记帐应用程序是使用 COBOL 编写的，并且运行在 CICS Transaction Server v3.1 上。记帐应用程序虽然较旧，其功能却不错。JKHLE 不计划替换此系统。

　　帐户开立流程应用程序需要将 CICS 事务用于记帐系统。这需要公开该应用程序的功能，以便让新的帐户开立流程应用程序使用，以及由其他应用程序和系统重用或使用。

　　建议的解决方案

　　CICS Transaction Server V3.1 提供了 Web 服务的本机支持，其中包括用来运行该服务的运行时和轻松创建服务的工具。直接公开现有的 CICS 应用程序可让服务使用者使用 SOAP 请求和响应编程模型直接与 CICS 通信。

　　Willy Li 决定创建一项 SetupBillAccount 服务，以便将 CICS 事务作为服务公开。该服务然后可以由帐户开立流程应用程序使用。

　　虽然 Willy Li 过去曾经做过一些 COBOL 编程，但对最新的 CICS 技术发展以及这些技术如何支持 Web 服务等情况，他感觉还是有点跟不上形势。

　　为了获取最新知识，Willy Li 阅读了一篇标题为“Adapting legacy systems for SOA, Finding new business value in older applications“的文章，这篇文章可通过以下网址找到：

　　http://www.ibm.com/developerworks/webservices/library/ws-soa-adaptleg/

　　虽然最初的工作中并不需要，但 Willy Li 还了解到可以从 CICS 调用一些服务。

　　对于该原型，Willy 使用 IBM Rational Developer for System z? 导入了一个描述所需的 CICS 事务的 COBOL Copybook，并从中生成各种构件，其中包括：

　　WSDL 文档

　　该文档用来描述该服务，特别是 SOAP 请求和响应格式，以及在这些消息中数据的名称和类型。此文档将在 IBM WebSphere Service Registry and Repository 中发布，以便让该服务的用户知道如何调用该服务和解释响应。

　　CICS WSBind 文件

　　该文件中有执行转换所需的全部元数据。此配置信息在运行时安装在 CICS Transaction Server 上。WSBIND 文件中的信息指示 CICS 如何处理消息和调用 CICS 应用程序，以及如何从结果中创建响应消息。

　　WSDL 文档允许透明使用由 CICS 支持的服务。该服务的请求者只知道 SOAP 请求和响应格式，不知道或不用关心它在由 CICS 处理。

　　工作方式
　
　　图 3 描述了将 CICS 应用程序作为服务直接公开。该服务的使用者可使用 HTTP 或 WebSphere MQ 将 SOAP 消息发送到 CICS Transaction Gateway。

　　在接到传入 SOAP 请求后，CICS 将把 SOAP 消息中的信息转换为 COMMAREA 中的数据并执行 CICS 事务。

　　当完成该事务后，CICS 将使用 COMMAREA 中的数据来创建 SOAP 响应，然后将其发回到该服务的使用者。

　　图 3 将现有的 CICS 应用程序作为服务直接公开
 
　　使用直接公开模式的注意事项

　　使用直接公开实现模式可以将现有的应用程序功能作为服务来公开。在使用 CICS 的情况下，CICS v3.1 包括在本地公开服务的支持，而 CICS v2.3 需要通过添加一个 Feature Pack 来实现这个支持。

　　使用直接公开模式的重要注意事项：

　　方便性是将现有资产作为服务公开的主要动机。因为这样做不需要编写代码，所以节省了开发和测试时间。
　　这些服务要求与该应用程序功能和数据密切对应。因此，不需要使用 Java 访问其他功能。
　　不需要自定义发往或来自实现资产的信息。
　　如果这些原因不适用，则间接公开实现可以提供另外一种方法，但成本是需要增加一些工作和中间件。

　　将现有应用程序作为服务间接公开

　　注意：适配器和连接器提供了间接访问各种平台上的应用程序的功能，如 z/OS? 上的企业信息系统（例如，CICS、IMS 和 SAP）。该适配器或连接器提供一个 Java API，从而将开发人员屏蔽开，他们无需了解后端应用程序。

　　通过将该适配器或连接器的 Java 代码作为服务包装起来，可以将该应用程序功能作为服务公开和使用以及供重用。此实现模式称为间接公开模式。

　　该开发环境中有同时在 CICS Transaction Server v3.1 和 v2.3 上运行的应用程序。目前已在 CICS v2.3 上部署了应收帐款系统，并且想重用这些 CICS 功能来创建名为 SetupARAccount 的新服务。

　　Willy Li 了解到，与为其他 CICS 应用程序实现的类型相似，在 JKHLE 环境中有一些因素制约着对直接公开模式的使用。CICS v2.3 不包括将应用程序作为服务公开的本机支持。有一个可以部署的 Feature Pack，该 Feature Pack 可以为 v2.3 提供此功能；但是，JKHLE 不想升级现有的 CICS v2.3 系统。JKHLE 正在将较旧的 CICS 应用程序迁移到 CICS v3.1，CICS v3.1 提供本机服务支持和更好的工具，可以支持构建和托管服务。

　　Willy Li 还了解到，间接公开模式可用于 CICS v2.3。

　　间接公开模式提供了创建一种服务将适配器或连接器包装起来访问该应用程序的能力。间接公开模式提供了对数据转换、聚合 CICS 功能，以及将所需的服务契约（在 WSDL 中）映射到基础实现（由 COBOL Copybook 表示）的最大限度控制。

　　因此，Willy Li 决定使用间接公开模式，提供将CICS v2.3 系统上的应收帐款系统作为服务公开的能力。

　　建议的解决方案

　　Willy Li 将 IBM Rational Developer for System z 用于开发，这包括 Rational Application Developer 功能和针对 System z 应用程序的附加工具。CICS/IMS Java 数据绑定向导可用来读取 COBOL Copybook 并生成特定于应用程序的访问类，在第 16 页上的图 4 中它们分别显示为 A 和 B。这些类了解的 CICS 功能和数据，并且它们使用 J2EE? 连接体系结构 (JCA) 处理与 CICS 的会话。CICS ECI 资源适配器在部署了该服务的 IBM WebSphere Application Server 运行时中使用。

　　由于初步服务契约是针对 SetupARAccount 定义的，Willy Li 决定为该服务导入 WSDL。接下来，他使用工具从 WSDL 中生成一个类架构和一个处理传入 SOAP 请求的 SOAP 处理器类，SOAP 处理器类是通过处理代码来处理的。

　　接着，Willy 使用 Java 编写处理代码，但这不需要太多的编程或代码。该处理代码将传入方法调用映射到访问类、聚合功能，并根据需要转换数据。Willy Li 使用的是第 8 页上“创建新服务”中描述的相同步骤，其中包括根据需要调用生成类上的方法来生成框架代码和完成代码。

　　从理论上讲，Willy Li 除了要知道如何使用 Copybook 和向导之外，不需要了解有关 JCA 或 CICS 适配器甚至 COBOL 的任何知识。他只需调用 Java 类上的方法来完成工作就可以了。尽管此工作的重点是作为服务重用 CICS 应用程序、通过使用 Java 来创建服务，但该资产仍可从 Java API 访问。

　　工作方式

　　图 4 显示了使用 JCA 基本服务组件的方式间接地公开CICS 应用程序

　　图 4 将现有的 CICS 应用程序作为服务组件间接公开
 
　　在此案例中，我们将通过创建中间层 Web 服务来访问 CICS，以间接的方式公开由 CICS Transaction Server 托管的现有 COBOL COMMAREA 应用程序。中间层 Web 服务包装会话 EJB，后者使用 CICS ECI 资源适配器与 CICS Transaction Gateway (CTG) 通信来访问 CICS Transaction Server。CICS ECI 资源适配器是一个用于与 CTG 一起打包的 WebSphere Application Server 的 JCA 适配器。

　　使用间接公开模式的注意事项

　　直接公开实现模式具有不必编码和测试代码的显著优势，并且在许多情况下，这种模式是最佳选择。但在某些情况下，为间接公开模式编写所需的代码仍然更好一些。

　　使用间接公开模式的重要注意事项：

　　该服务实现需要将 CICS 功能和后端代码中没有的其它功能混合使用。
　　您可以轻松地将该服务接口与后端实现的接口分开，这使您能够创建一个更易使用、更易替换为以后的新实现的服务。当已经存在服务规范并且该服务规范不同于您通过直接方法获得的服务规范时，这种方法也比较合适。
　　虽然主要在 CICS 上运行该服务有一些性能优势，但可能需要更好地控制性能影响。

　　使 WebSphere Message Broker 流支持服务

　　帐户开立流程应用程序与许多后端系统交互。

　　Willy Li 了解到，该 IT 组织已经实现了 IBM WebSphere Message Broker，以提供到后端系统（如 IMS、SAP 和 CICS）的连接性。JKHLE 之所以选择 WebSphere Message Broker 方法，是因为它能够整合数据、转换消息和传输协议。

　　目前访问 WebSphere Message Broker 流的方法需要使用 WebSphere MQ。虽然此方法可以用于 JKHLE，但它只能支持使用MQ，并且不容易被各种 JKHLE 应用程序和系统重用。

　　Edmund 邀请集成架构师 Kai Buses 参加关于使 WebSphere Message Broker 流支持服务的讨论，因为 Kai 非常精通 WebSphere Message Broker 和后端集成知识。Kai 解释说，WebSphere Message Broker 是 JKHLE ESB 体系结构的一个关键组件。

　　Kai 建议 Willy Li 开发一个支持服务的 WebSphere Message Broker 流原型，以更加方便地重用这些流。Edmund 建议 Willy Li 使现有的 WebSphere Message Broker 流支持服务，以便访问使用 COBOL 编码并在 IMS 上托管的分类帐应用程序。

　　Willy Li 了解到，帐户开立流程应用程序需要检查新客户是否与现有的关键帐户拥有者有关联，如果有，要确保他们获得了最高级别的服务。Edmund 解释说，分类帐应用程序包含客户进行关联检查所需的数据。分类帐应用程序可用来维护每个客户的销售收入数据，其目的在于了解哪些客户为 JKHLE 带来了最大收入。

　　Willy Li 决定，他将为支持服务的 WebSphereMessage Broker 流创建一个原型，以便访问在 IMS 上托管的分类帐应用程序。

　　建议的解决方案

　　从理论上讲，Willy Li 不需要知道 WebSphere Message Broker 流的技术细节。Web 服务将包装现有的 WebSphere Message Broker 流，以允许该流作为服务使用。

　　工作方式

　　图 5 描述了到后端企业信息系统的支持服务的 WebSphere Message Broker 流。

　　图 5 使 WebSphere Message Broker 流支持服务
 
　　IBM WebSphere Message Broker 工具包可用来读取 WebSphere Message Broker 流并生成 Web 服务以公开该流。该服务将部署到安装了 WebSphere Message Broker 的节点上。基于 SOAP 的 Web 服务支持 HTTP 或 HTTPS、JMS 和 WebSphere MQ 传输。

　　WSDL 将发布到 IBM WebSphere Service Registry and Repository 上，并提供给服务使用者使用。该服务将部署到安装了 WebSphere Message Broker 的节点上。

　　使用支持服务的 WebSphere Message Broker 流的重要注意事项

　　使用支持服务的 WebSphere Message Broker 流的重要注意事项包括：

　　WebSphere Message Broker 流已经存在，支持服务是作为服务重用的快速、直接的方法。
　　当需要转换消息和传输协议以及需要整合消息数据时，应考虑使新的 WebSphere Message Broker 流支持服务。
　　WebSphere Message Broker 流提供了可供业务服务组合使用的诸如安全性和审核之类的基础结构服务。
　　WebSphere Message Broker 使用的 JMS 和 WebSphere MQ 是进行可靠消息传递的综合性行业标准，同时还是一种广泛采用的、包括 IMS 连接性在内的业务到业务的集成技术。
　　提供一个耦合了中介的服务实现。
　　利用 WebSphere MQ 进行基本的消息传递和 Web 服务流动。

　　使 IMS 事务支持服务

　　如 “使 WebSphere Message Broker 流支持服务”中所述，Willy Li 了解到需要将后端 IMS 应用程序作为服务公开。

　　Edmund 和 Kai explain 向 Willy Li 解释说，有几种解决方案模式可用于使 IMS 事务支持服务，其中包括：

　　使用 IMS TM 适配器使 IMS 事务支持服务
　　使用 IMS SOAP Gateway 使 IMS 事务支持服务
　　使用 MQ IMS Bridge 使 IMS 事务支持服务
　　针对构建原型这一目的，Willy Li 将使用与 Edmund 和 Kai 讨论的每种方法将分类帐 IMS 应用程序作为服务公开。Willy Li 计划使用分类帐应用程序，该应用程序是使用 COBOL 编码，并且由 IMS Transaction Manager 托管。

　　使用 IMS TM 适配器使 IMS 事务支持服务

　　为了通过 IMS TM 适配器使 IMS 事务支持服务，Willy Li 将使用服务组件间接地公开现有的应用程序功能。

　　业务一致性通常是通过自顶向下的方式或结合使用自顶向下和中间相遇方法定义服务接口 (WSDL) 来实现的。

　　通过创建中间层 Web 服务来访问 IMS，可将 IMS 应用程序作为服务间接公开。中间层 Web 服务包装会话 EJB，后者使用 IMS TM 资源适配器与 IMS 连接通信，以访问在其上托管该应用程序的 IMS Transaction Manager。

　　Willy Li 了解到，通过 IMS TM 适配器使 IMS 事务支持服务将提供最强健的全局事务支持。IMS TM 资源适配器兼容 JCA XA 并支持两阶段提交。

　　工作方式

　　图 6 描述了使用 IMS TM 资源适配器组装和部署支持服务的IMS 事务的环境。

　　图 6 使用 IMS TM 适配器使 IMS 事务支持服务
 
　　对于存在 COBOL Copybook 的情形，Willy Li 将该 Copybook 导入到 IBM Rational Application Developer 中。如果不存在 COBOL Copybook，可先使用 IBM Rational Application Developer 来创建该 Copybook，然后将该 Copybook 导入到 Rational Application Developer。

　　接下来，Willy Li 将使用该工具生成输入和输出转换程序、J2C Bean、服务 WSDL 和服务应用程序。然后将该服务部署到中间层 WebSphere Application Server，并且将 WSDL 发布给 IBM WebSphere Service Registry and Repository。

　　重要注意事项

　　使用 IMS TM 适配器使 IMS 事务支持服务的重要注意事项包括：

　　IMS TM 资源适配器使用 J2EE Connector Architecture (JCA)标准进行消息传递，使此选项成为最广泛采用的 IMS 连接选项，且具有当今最高的服务质量。
提供一个耦合了中介的服务实现。
　　如果客户使用 WebSphere Application Server 创建中间层组件，则最佳集成选项一般是使用 IMS TM 资源适配器的 J2C。
　
　　使用 IMS SOAP Gateway 使 IMS 事务支持服务

　　Willy Li 了解到，他可以使用 IMS SOAP Gateway 让 IMS 应用程序成为可供帐户开立流程应用程序使用或其他应用程序重用的 Web 服务。

　　使用 IMS SOAP Gateway，可以在处理数据的方式方面获得更好的灵活性。例如，您可以让该数据将客户端中的 XML 数据发送到能够由新的或增强的 IMS 应用程序处理的 IMS 环境。通过使用 IMS XML DB 功能可以将该数据直接存储在 XML 中，也可以将 XML 数据转换为数据字节。

　　Willy Li 还了解到，IMS SOAP Gateway 包括两个主要组件：

　　IMS SOAP Gateway 部署实用工具

　　这一端到端部署实用工具使您能够设置属性和创建 IMS SOAP Gateway 用来将 IMS 应用程序作为 Web 服务的运行时代码。

　　IMS SOAP Gateway 服务器

　　该服务器用来处理 SOAP 消息。它可以从客户端应用程序中接收 SOAP 消息，将其转换为 IMS 输入消息，并通过 IMS 连接将其发送给 IMS。然后从 IMS 接收输出消息，将其转换为 SOAP，并将其发回到该客户端。

　　工作方式

　　图 7 描述了使用 IMS SOAP Gateway 组装和部署支持服务的 IMS 事务的环境。

　　图 7 使用 IMS SOAP Gateway 使 IMS 事务支持服务
 
　　Willy Li 开始从 SCM 检索分类帐应用程序构件，包括 COBOL 程序和 Copybook。这些构件被导入到 IBM Rational Developer for System z 中。Willy Li 使用该工具来生成输入和输出 XML 转换程序、驱动程序和服务 WSDL。

　　接下来，Willy Li 将生成的 COBOL 源复制到 z/OS，以便为 XML 数据转换和作为 Web 服务调用的 IMS 应用程序编译和准备生成的源代码。生成的 WSDL 将被部署到 IMS SOAP Gateway，并发布给 IBM WebSphere Service Registry and Repository。

　　重要注意事项

　　使用 IMS SOAP Gateway 使 IMS 事务支持服务的重要注意事项包括：

　　通过对访问 IMS 事务提供基本的 SOAP 支持，为通过 Web 的消息传递提供轻量级标准。
　　提供一个松散耦合的服务实现。
　　如果客户不想编写 Web 服务包装程序（例如，为 EJB 编写包装程序），则 IMS Gateway 通常是最佳选项。

　　使用 MQ IMS Bridge 使 IMS 事务支持服务

　　如 “使 WebSphere Message Broker 流支持服务”中所述，Willy Li 将通过使 WebSphere Message Broker 流支持服务来访问后端 IMS 分类帐应用程序。

　　通过使用 WebSphere MQ 和 MQ IMS Bridge，支持服务的 WebSphere Message Broker 流可用来与 IMS 后端系统通信

　　（请参见图 8）。MQ IMS Bridge 使用特别定义的队列与 IMS 通信，并使用 IMS OTMA 接口从该队列中获取消息并将这些消息发送到 IMS，同时通过 OTMA 接口接收输出消息。

　　图 8 使用 WebSphere Message Broker 和 MQ IMS Bridge 使 IMS 事务支持服务
 
　　使 IMS 事务支持服务的注意事项

　　总结

　　在短时间内（包括利用工具熟悉解决方案模式和试验的时间），Willy Li 已经准备好创建帐户开立项目所需的那些典型服务。重用由 CICS 和 IMS 托管的现有应用程序比 Willy Li 当初预期的更加容易，并且需要编写的代码很少。Willy Li 发现，用来创建 UML 的 Rational Software Architect 工具、生成 WSDL 和服务的向导、测试以及与 Rational ClearCase 和 ClearQuest 集成非常容易使用。Willy Li 还发现 Rational Developer for System z 和 WebSphere Message Broker Toolkit 也可以使他的开发工作变得更加便捷。

　　总之，在本案例研究中使用以下软件进行了服务的创建和重用：

　　模型：
　　IBM Rational Software Architect
　　组装：
　　IBM Rational Application Developer

　　注意：IBM Rational Application Developer 包括用来组装和单元测试 Web 服务的工具。IBM Rational Software Architect 包括 Rational Application Developer 的功能和建模功能。因此，如果您担任的角色需要建模和组装，则可以使用 IBM Rational Software Architect。

　　IBM Rational Developer for System z
　　IBM CICS 和 IMS JCA 资源适配器与工具
　　IBM WebSphere Message Broker 工具包
　　IBM WebSphere Studio Asset Analyzer
　　部署：
　　IBM WebSphere Application Server
　　IBM WebSphere Enterprise Service Bus
　　IBM WebSphere Message Broker
　　管理：
　　IBM Tivoli Composite Application Manager for SOA
　　治理：
　　IBM WebSphere Service Registry and Repository