内容


Web 服务的最佳实践

回到基础部分,第 3 部分

使用直接连接的应用程序模式来建立桥梁

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: Web 服务的最佳实践

敬请期待该系列的后续内容。

此内容是该系列的一部分:Web 服务的最佳实践

敬请期待该系列的后续内容。

在本专栏的第一、第二篇文章中,我们为您介绍了 Web 服务的新术语和 IBM 的电子商务模式的有关概念(请参阅下面的 参考资料部分中的链接)。在本文中,我们将把以前列举的术语和解决方案的模式应用于真实的业务情景。IBM 在金融服务业中的一个客户曾清楚地阐述了我们将要在这里讨论的要求。

目前,对于如何在实际的业务情景中最佳地应用 SOAP 和 WSDL 等新技术,开发者和应用程序设计者感到困惑。这就是说那些试图在实践中应用 Web 服务的人常常在缺乏指导的情况下工作。本文的目的是讲述一个真实的业务示例并针对我们在前几篇文章中列出的概念来分析它。在这一过程中,我们将看到当我们使用新技术来解决实际问题时新技术的承诺是如何被实现的。具体地说,我们将针对以下问题来分析实际的业务情景:

  1. 解决方案的业务目标是什么?
  2. 解决方案所实现的业务模式和应用程序模式是什么?
  3. 应用程序的逻辑体系结构是什么?
  4. 在构建应用程序的过程中,如何使用 Web 服务技术?在哪里使用它?为什么使用它?
  5. 通过在应用程序中使用 Web 服务,所得到的具体好处是什么?
  6. 对于所用的技术和方法,您取得了哪些经验和教训?

我们编写本系列文章的目标之一是使用实际的客户情景,在这些情景中工作的 IBM 的 Emerging Technologies jStart 小组和 IBM 的 Global Services 小组实现了 Web 服务或与 Web 服务类似的应用程序。在本文和后续的文章中给出的分析是直接基于这些情景的。为了不公开、不损害 IBM 与我们的客户的关系,我们使用了虚构的公司名。但是,这些项目是真实的而不是假设的练习。我们将获得的最佳实践是基于实现的真实情况而不是理论或我们认为的应该的作法。

业务目标

Hopewell International Trading Company(HITC)是主要的、大规模金融服务公司。与许多大公司类似,HITC 由许多为适应向内部客户和外部客户提供服务而设立的单独的业务部门(line of business,LOB)组成。HITC 的 Investment Management and Private Banking Group 就是这样一个 LOB。它提供一整套全球性的功能以满足共同基金的股东、投资专业伙伴和机构的需求。在我们的情景中,Managed Accounts Group 是 HITC 中的另一个部门,也是接受 Investment Management and Private Banking Group 的服务的客户之一。

Managed Accounts Group 为构成它的客户群的投资者提供详细的财务状况表(它还提供其他服务);它使用 Microsoft Word 来创建这些财务状况表。财务状况表类似于会计报表;但是,它不仅提供某个帐户中持有的所有财产价值的逐条记录,还提供每一时刻每笔财产的状态的详细信息。一笔财产的状态可以是 付清的,这意味着帐户中分别对应于流出现金和流入股本的借方交易和贷方交易的完成。其他财产可处于 未决的未定的(in-flight)状态,处于这些状态的借贷交易尚未完成。

为了简化工作,Managed Account Group 的工作人员需要创建使用宏来按需访问后端投资银行数据的模板文档。Investment Management and Private Banking Group 向 Managed Accounts Group 提供这些数据。

我们需构建的解决方案必须处理一个关键问题:Managed Accounts Group 使用基于 Microsoft 技术的基础结构,而 Investment Management and Private Banking Group 是运行 IBM WebSphere Application Server 和 Sybase 的 J2EE 商店(有一个正在运作的项目将把 Sybase 迁移到 IBM DB2 以用于生产环境)。该解决方案必须在输出端使用 Sybase,但能够迁移到 DB2 而无需对客户机端的代码进行任何更改。此外,该解决方案需建立客户机与服务器之间的互操作性同时要避免迫使 Managed Account Group 扩展它目前的 Microsoft 操作环境。

这个情景中的业务目标是清楚的。业务流程( 创建详细的投资财务状况表)需要与位于伙伴机构( Investment Management and Private Banking Group)的流程和信息集成。

关键的技术目标也是同样地清楚。服务供应商( Investment Management and Private Banking Group)需要为它的数据提供平台独立且编程语言独立的接口。具体说来,该接口必须允许 Microsoft Office 的宏直接与部署在 J2EE 环境中的软件应用程序通信。

选择适用的电子商务和应用程序模式

当我们对要求有了一点理解后,我们就可以开始分析如何提供解决方案。在下面的 表 1中(您应该认识这个出现在本系列的第 2 部分的表),我们把业务要求映射到具体的电子商务模式。我们使用这个表来帮助我们确定具体的电子商务模式,该模式有助于我们了解我们需要构建的解决方案的基本组件。在这个表中,我们突出显示了最适用于我们的情景的要求。

表 1. 选择电子商务模式
业务和 IT 驱动程序业务模式集成模式
自助服务协作信息聚集扩展企业访问集成应用程序集成
最终用户和客户需要直接与业务流程和/或数据进行交互。
业务流程需要与现有的业务系统和信息进行集成。
业务流程需要与存在于伙伴组织的流程和信息进行集成。XX
业务活动需要聚集、组织并展示来自于组织内外的各种来源中的信息。
必须能以一种常见的、一致的并且简化的方式通过多个传输通道获得业务流程。
业务活动要求并鼓励协作并能在协作的参与者之间共享信息。

电子商务模式:应用程序集成

通过阅读这个表,我们看到了两个可能适用的模式: 扩展企业模式和 应用程序集成模式。简要地回顾一下这两种模式将有助于演示如何为这个情景选择最合适的模式。

扩展企业业务模式(也被称为 企业-到-企业(Business-to-Business,B2B)模式)处理不同企业中的业务流程之间的交互和协作。这种模式常被用于实现连接企业内部应用程序的编程接口的解决方案。同样,它不包括由跨越组织边界的业务伙伴通过用户界面直接调用的应用程序。 应用程序集成集中了多个应用程序和信息源而用户无需直接调用它们;它的焦点是应用程序和数据之间的关系。考虑到这一点,根据已经讨论过的解决方案的要求,应用程序集成模式显然应该是我们项目的最佳选择。

应用程序模式:直接连接

当我们为我们的情景选择了通用的电子商务模式后,下一步是为这个情景选择具体的应用程序模式。应用程序模式有助于改进业务模式以使它们可被实现成基于计算机的解决方案。通过找出并描述高级的逻辑组件(这些组件需被用来实现在每个业务模式中找出的主要功能),这些模式有助于为业务模式提供结构。从本质上说,应用程序集成有两种不同的方式:

  • 流程集成是应用程序之间处理的功能流程的集成。
  • 数据集成是应用程序所用的信息的集成。

因为我们的情景需要与某个客户的帐户关联的所有的财务状况表的合并的视图,所以,以流程为重点的应用程序集成模式是最为合适的。这一点是显然的,因为 Microsoft Word 的宏发出的每个请求必将触发一个收集、总结所有所需的信息并以只读格式把它返回给 Microsoft Word 的模板的流程。

对应用程序集成的电子商务模式的各种应用程序模式(可在 IBM 的电子商务模式的 Web 站点上查看;请参阅 参考资料中的链接)的探讨可以为我们的解决方案揭示多个可能的配置。然而,最适合的应用程序模式是直接连接模式,该模式在仅有两个应用程序通过标准的或相互理解的编程接口被集成时是适用的。 图 1说明了这个应用程序模式。

图 1. 直接连接的应用程序模式
直接连接的应用程序模式
直接连接的应用程序模式

在直接连接的模式中有两个角色: 启动者(initiator)(在我们的情况中是 Microsoft Word 的宏)和 提供者(provider)(在我们的情况中是提供数据的 J2EE 应用程序)。因为我们的情景需要基于表单的应用程序(Microsoft Word)参与请求/响应握手,所以启动者与提供者之间的通信必须是同步的。

当我们理解了基于适用的模式的解决方案的角色和基本操作后,我们可以开始了解逻辑的体系结构,如 图 2所示。

图 2. HITC 的直接连接的解决方案的基本的运行时体系结构
HITC 的直接连接的解决方案的基本的运行时体系结构
HITC 的直接连接的解决方案的基本的运行时体系结构

逻辑的解决方案体系结构

当我们建立了基本的业务目标、选择了具体的应用程序模式并对最终解决方案的模样有了一个基本的了解后,下一步可以探讨具体如何来实现该应用程序。

在解决方案的体系结构中,Microsoft Word 模板使用帐号来调用查询应用程序(该应用程序托管于后端的 WebSphere Application Server)的宏。为了使基于 Microsoft 的客户机能够连接到基于 J2EE 的服务器环境,我们通过基于 SOAP 的 Web 服务来通信。客户机宏执行对运行于 WebSphere 的 Web 服务的 SOAP RPC 调用。该 Web 服务只不过是访问 JDBC 数据源的 Java 类的前端,它接着触发 Sybase 或 DB2(这取决于 Investment Management and Private Banking Group 目前正在使用哪个数据库)中的存储过程。

图 3. 逻辑的应用程序体系结构
逻辑的应用程序体系结构
逻辑的应用程序体系结构

我们使用 IBM WebSphere Studio Application Developer Integration Edition 开发工具来构建 Web 服务(请参阅 参考资料中的链接)。我们使用 Application Developer 来生成对运行于 Sybase 或 DB2 中的存储过程进行 JDBC 调用的 JavaBean。在这一时刻,我们必须作出两个重要的设计决定。第一,Investment Management and Private Banking Group 的 IT 策略规定所有的业务逻辑应该驻留在存储过程中而不是驻留在中间层(应用程序服务器)级别。该策略便于我们达到使解决方案不限于任何特定的数据存储的目标。通过在两个数据存储中使用相同名称的存储过程并确保每个数据存储所返回的具体数据的一致性,可以尽量减少迁移(从 Sybase 到 DB2)时所需的更改。这意味着数据存储迁移的影响仅限于 JDBC 连接参数。

第二,我们选择不用企业 JavaBeans(Enterprise JavaBeans,EJB)组件。我们已决定使用存储过程,EJB 仅提供事务性的行为,这些行为不必要地复制了存储过程已提供的功能。所以,一个 JavaBean 被用于实现。

接下来,我们使用 WSAD/IE 来自动生成把 JavaBean 部署到 WebSphere Web 服务运行时环境所需的 WSDL 文档和 Web 服务部署助诊文件。您可以研究清单 1 中生成的 WSDL 文档的片断。我们设计了返回包含编码的 XML 文档的字符串值的每个操作;每个文档符合 Investment Management and Private Banking Group 为这一目的特别创建的 XML 模式。该模式至少包括一个 AccountDetail 元素和零个或更多个 Position 元素,这些元素提供目前分配到帐户的或未定的(付清的和未决的)的财务状况的高级视图。

清单 1. 生成的 Web 服务描述的片断
<message name="getPositionsRequest">
  <part name="requestorID" type="xsd:string"/>
  <part name="accountID" type="xsd:int"/>
  <part name="date" type="xsd:dateTime"/>
</message>
<message name="getPositionsResponse">
  <part name="result" type="xsd:string"/>
</message>
<message name="getAccountDetailRequest">
  <part name="requestorID" type="xsd:string"/>
  <part name="accountID" type="xsd:int"/>
</message>
<message name="getAccountDetailResponse">
  <part name="result" type="xsd:string"/>
</message>
<message name="getNumPositionsRequest">
  <part name="requestorID" type="xsd:string"/>
  <part name="accountID" type="xsd:int"/>
  <part name="date" type="xsd:dateTime"/>
</message>
<message name="getNumPositionsResponse">
  <part name="result" type="xsd:string"/>
</message>

在客户机端,我们使用内置于 Microsoft Office Suite 的宏开发工具和 Microsoft SOAP Toolkit for COM 来创建 Microsoft Word 模板。我们构造从用户那里获取必要的信息的简单的用户界面,然后构建使用 WSDL 并对 Web 服务进行必要的调用的流程。

Web 服务的适用性和它们的具体好处

在本系列的第 2 部分中,我们介绍了一个一般原则:

在所有必须交换信息的边界上(这个边界可以存在于业务之间、应用程序之间或是解决方案的逻辑组件之间,等等),Web 服务将影响业务模式、集成模式以及应用程序模式的实现。

在我们的情景中,集成点位于运行 Web 服务的中间层应用程序服务器与调用它的 Microsoft Word 模板之间。(最终被调用的)金融数据服务(Financial Data Service)发布一个或多个转换成对财务状况数据的简单信息的请求的 RPC 操作。无论使用中的后端数据存储或应用程序环境是什么,请求的应用程序(Microsoft Word 模板)通过使用帐号都可获得某个帐号的 XML 格式的信息。

通过使用本系列的第 1 部分中列出的术语,我们把在直接连接的解决方案中实现的 Web 服务归类为 XML Web 服务,因为它把 WSDL、SOAP 和 HTTP 分别用作描述协议、消息传递协议和传输协议。欲知详情,请看从第 1 部分复制过来的 图 4图 5

图 4. 面向服务的应用程序协议
面向服务的应用程序协议
面向服务的应用程序协议
图 5. Web 服务协议的域
Web 服务协议的域
Web 服务协议的域

然而,还有一条在这一情景中实现的集成边界没有以任何方式使用 Web 服务技术:J2EE 应用程序与后端数据存储之间的边界。我们使用 JDBC 来跨越该边界并连接、调用 Sybase 或 DB2 中的存储过程。

为什么 Web 服务不适用于这第二条边界?我们在第 2 部分中的另一条评论中已提到了这个原因:

Web 服务技术的设计意图是实实在在地改善集成点的互操作性和灵活性。

因为 WebSphere Application Server、DB2 和 Sybase 都是启用 JDBC 的环境,所以互操作性不是问题。因为我们这里的业务逻辑被包含在存储过程中而不是被包含在应用程序服务器上,所以灵活性是固有的。否则,Web 服务无法使连接更有价值。然而,基于 Microsoft 的开发环境与基于 J2EE 的应用程序服务器环境之间的互操作性是经典的挑战,由于需要确保被访问数据的数据存储不了解的视图,使得这一挑战变得更困难。

促使 Web 服务适用于第一条边界而不适用于第二条边界的另一个关键因素是 Investment Management and Private Banking Group 在第二条边界上控制着连接的两端 ― 也就是说,应用程序服务器和数据存储环境。然而,在第一条边界上,客户机环境是 Managed Accounts Group 的全部责任。所以,Investment Management and Private Banking Group 必须提供 Managed Accounts Group 所选择的特定的应用程序环境完全不了解的解决方案。假定 Investment Management and Private Banking Group 控制着客户机环境和服务器环境,那么我们仍然可以使用 Web 服务来实现灵活性或互操作性目标,但是我们将有更多的选项来优化跨越边界的通信。例如,我们可以使用通过 JMS 的 SOAP,以实现比通过 HTTP 的 SOAP 的异步连接的可伸缩性更好的异步连接。

吸取的经验教训

通过使用刚刚建立的术语表以及与 IBM 电子商务模式的联系,我们能够进行真实的案例分析并快速地阐明适合我们的情景的运行时拓扑结构和 Web 服务的适用性。

结果,在为客户提供主题为 Microsoft 技术与各种其他 SOAP 工具箱(Apache SOAP 和 Apache Axis)之间的 SOAP 互操作性的咨询时,这个情景扮演了重要角色。在互操作性方面吸取的重要的经验教训:虽然自从第一个 SOAP 工具箱被发布以来已取得了很大进展(请参阅 参考资料以了解更多关于 SOAP 互操作性的信息),但是仍有许多问题有待解决。随着有关工具越来越成熟,互操作性的状况将会改善。例如,如果 Managed Accounts Group 决定改用未来的 Microsoft Office 的启用 Microsoft .Net 的版本,那么它将可以使用内置于 .Net 框架的明显改进的 Web 服务互操作性功能。

客户还从我们的 Web 服务方式中学到了另一条重要的经验: 从小规模开始,快速扩大!这是明智的决定,因为这个情景是这个企业的组织间第一个 Web 服务的生产实现。我们的目标是使它简单小巧。我们的客户不愿意在他们的业务环境中太多、太快地应用 Web 服务。随着时间的流逝、业务需求的发展、技术的成熟和经验的增加,我们可以处理更复杂的情景,但是从小规模开始,然后自己扩展它,这样做要容易得多。

我们在先前讨论 JDBC 的使用时已阐明,在更深的技术层次上,我们还认识到 Web 服务并 适合所有的地方。试图使 Web 服务适合于企业的一切业务是不合理的。为了使它们提供它们应提供的价值,它们必须被用于它们的设计者所设想的确切目的。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=SOA and web services
ArticleID=55127
ArticleTitle=Web 服务的最佳实践: 回到基础部分,第 3 部分
publish-date=11012002