内容


Web 服务的最佳实践

第 5 部分

利用现有旧应用程序的多通道解决方案

Comments

系列内容:

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

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

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

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

构建在 第 1 部分所介绍的语义框架之上并且应用 第 2 部分所讨论的 IBM 电子商务模式的技术,本文将继续讨论在真实的业务情景中 Web 服务为什么能以及在哪里起作用。在整个讨论过程中,我们的方法都着眼于由实际的 IBM 客户向我们提出的各种业务问题,并且探究一些用来解决这些问题的解决方案(这些解决方案利用了 IBM 的电子商务模式向我们提供的语义的、组织的构架。)。在这部分中,将关注一家金融服务公司,这家公司在寻求不再充当客户软件提供商和维护角色且想节省同业务伙伴集成的成本。同时他们想改善当前 24 小时批处理且想为他们的业务伙伴提供一种“近似”实时的解决方案。

对于许多正在试图应用 Web 服务的开发者和应用程序设计师来说,主要挑战是:目前几乎没有提供关于如何在真实的业务情景中用最好的方式应用诸如 SOAP 和 WSDL 之类新技术的指导。本文的目的就是举一个真实的业务示例,按照前面几篇文章所列出的概念对这个示例进行分析;并在分析过程得出一些关于这种新技术的承诺和使用这种新技术来解决实际问题的现实如何相一致的经验教训。具体来说,我们将针对下面一组问题来分析该示例情景:

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

另外,需要提一下,我们将这一系列文章放在一起的目的之一是使用实际的客户情景,IBM 的 Emerging Technologies jStart 小组和 IBM 的 Global Services 小组为这些客户情景实现了 Web 服务或类似于 Web 服务的应用程序。在本文和后续的文章中给出的分析是直接基于这些情景的。然而,为了保护 IBM 与我们的客户的关系的机密性和完整性,我们使用了虚构的公司名。但是,在此要记住的关键的一点是:这些项目是真实的,而不是基于假设的练习。我们将获得的最佳实践是基于设法使工作完成的真实情况,而不是基于理论或我们想当然的做法。

业务目标


GalaxyCard(GC)是一家拥有包括 GalaxyCard 信用卡在内的一些广为人知且具有良好声誉的支付工具的全球支付公司。GC 建立服务(GC Establishment Services,GC-ES)负责建立新的商家帐户。这些新帐户允许商家接受 GC 品牌的信用卡作为支付形式。大家知道,商家收购(Merchant Acquisition)这个过程的管理要跨越许多间接销售通道进行。外部销售代理(External Sales Agent,ESA)是充当 GC 和商家之间的经纪人的企业实体。ESA 是独立地向商家销售各种有品牌信用卡(包括但不限于 GC 卡)的收单银行或机构。ESA 赚取的钱来自于它们按照给 GC 新带来的商业收购所收取的佣金。GC-ES 小组负责实现 ESA 和 GC 同这些公司的全面的关系管理。

GC 维系着同各个 ESA 实体之间的许多关系。GC 总计要处理约 275 家 ESA。这 275 家 ESA 中大约 20 家就给 GC 带来 80% 的业务量。在这 20 家中有类似于 First Data Merchant Services(FDMS)、Retriever 以及 Concord EFS 这样的公司。 虽然 ESA 能够直接和 GC 往来,但在有些情况下,它们将供给给更大的 ESA 的供应商,后者接着再与 GC 发生联系。这种分层供应链模型如 图 1所示。

ESA 供应链
ESA 供应链

当前,GC 向它的 ESA 实体提供许多不同的与商业收购过程集成的方法。在所有不同的选择中,文件传送(File Transfer)和一个被称为 ESA-Link 的由 GC 生产并支持的胖客户机应用程序最受欢迎。尽管这些方法很有效,但所涉及的成本和复杂性却让人生畏,GC 不想让自己再充当为它的 ESA 提供客户机软件和维护支持的角色,从而能够转而把注意力和投资集中在其核心竞争力上。

他们正在寻求的解决方案是一种统一的商家自助服务的方法,这种方法能够支持所有可能的收购通道,而同时又能够解除对将按日程退出的现有资产的依赖。为了解决这一难题,启动了 ESA-Enablement 项目,该项目旨在设计并构建组合式 Web 应用程序和主机到主机(Host-to-Host)集成解决方案,这个解决方案提供:

  • 用于让所有利益相关人以电子方式发送和接收实时信息的安全的软件服务。
  • 用户友好的 Web 站点包含:
    • 实时的 ESA 性能。
    • 实时地建立商家帐户。
    • 用于系统和关系更新、警告以及调查的伙伴通信。
    • 文件传送功能。
多通道 ESA 实现的商家帐户管理

图 2中的示意图表明,这个项目的技术目的是:

  • 创建一个统一的接口(MAM Services),用来支持建立所有商家收购通道(Merchant Acquisition Channel)的商家帐户。
  • 新建一个 GC 品牌的因特网应用程序,用来为 ESA 提供建立帐户的功能。
  • 利用 MAM 服务来更新允许商家建立他们自己帐户的现有解决方案。
  • 创建一个应用程序到应用程序(application-to-application)解决方案,以考虑以编程方式集成 GC 和它的 ESA 的情况。

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


既然我们对要求完成什么任务有了一些了解,那我们就可以开始分析应该如何得到解决方案了。在下面的 表 1中(您已从这个专栏的前面几篇文章中熟识),我们将业务要求映射到特定的电子商务模式。我们使用这张表来帮助确定特定的电子商务模式,该模式有助于我们识别我们需要构建的解决方案的基本组件。在这张表中,我们突出显示了最适用于我们的情景的要求。

选择电子商务模式

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

定制的电子商务模式:自助服务 + 扩展企业


在许多实际情景中,所提出的业务要求经常让人很难找出能适用于整个解决方案的单个电子商务模式。在这样的情况下,最好的做法是混合最匹配的模式,开发出新的组合或定制模式。在 GC 的商家帐户管理服务解决方案这个案例中,案例的要求将我们导向自助服务和扩展企业业务模式。快速回顾一下这两种模式将有助于阐述为何对于这个情景它们是最适用的。

扩展企业业务模式(也称为企业到企业(Business-to-Business)模式或 B2B 模式)处理不同企业中的业务流程之间的交互与协作。这种模式常被用于实现连接企业内部应用程序的编程接口的解决方案。因此,它不包含由用户接口直接调用的应用程序。

在 GC 的解决方案这个案例中,要求允许一些 ESA 以编程方式与 MAM 服务集成。要达到这个要求,采用扩展企业方式是适当的。然而,还有另外一个要求,即要求允许那些不想以编程方式进行集成的 ESA 能访问基于浏览器的 Web 应用程序(它是 MAM 服务解决方案的前端)。自助服务模式处理一个业务和它的各种类型的用户之间的用户接口驱动的交互。

由于目标是最终构建这样一个运行时基础结构,它可以通过代码重用为所有可能的通道服务,同时又能实现降低操作和维护的总成本这一目标,所以很难选择任何单个应用程序模式来实现这个目标,但这并非完全不可能。所提出的适当方法是将解决方案拆分成多个组件,并独立于其他组件对每一个组件进行研究。

应用程序模式:公开业务模式


位于为 GC 设计的解决方案的中心的是集中式 MAM 服务,它将在多个集成通道之间重用。对几个适用的业务模式进行彻底的分析后,我们发现扩展企业公开业务服务(Extended Enterprise Exposed Business Services)应用程序模式用来为 MAM 服务组件建模是最合适的。应用程序模式帮助我们完善业务模式,以便可以将它们实现为基于计算机的解决方案。通过找出并描述高级别的逻辑组件(这些组件需被用来实现在每个业务模式中规定的主要功能),这些模式有助于为业务模式提供结构。

公开业务服务(Exposed Business Services)应用程序模式确定了能公开特定服务的系统设计,这些特定服务可由伙伴系统跨组织边界直接进行调用。帮助选择公开业务服务应用程序模式的主要业务和 IT 驱动因素有:

  • 支持伙伴实时访问应用程序/应用程序实时访问伙伴。
  • 支持伙伴实时访问业务服务/业务服务实时访问伙伴。
  • 利用现有的技能。
  • 利用以前的投资。
  • 后端应用程序集成。
  • 使应用程序复杂性降到最低。
  • 使企业复杂性降到最低。
  • 减少伙伴对特定应用程序的依赖。

选择这个应用程序模式的主要业务驱动因素是要使业务伙伴系统能获得对特定业务服务的直接访问。

公开业务服务应用程序模式
公开业务服务应用程序模式

图 3所示,这个应用程序模式设计时至少用到了三个逻辑层:Partner、Exposed Business Services 以及 Backend Application。然而在我们的情景中,在 Partner 和 Exposed Business Services 组件之间引入了第四个组件 Channel Interfaces,如 图 4所描述。

基本运行时体系结构
基本运行时体系结构

Partner 层代表了一组伙伴应用程序,这些应用程序对调用 Exposed Business Services 层上的特定服务感兴趣。在我们的情景中,这将是那些提供远程建立商家帐户功能的 ESA 应用程序。

Channel Interfaces 层是一些用户接口组件和一些可编程服务的集合,它们允许多个通道重用一组公共业务服务,后者在我们案例中被称为 MAM 服务。伙伴选择的通道类型不同则会有不同的业务模式适用。例如,一个选择基于浏览器的 Web 通道的伙伴将选择自助模式,而一个选择程序化接口的伙伴将选择扩展企业模式。不过,无论选择了何种通道,所有的通道都访问同一公开业务服务。

Exposed Business Services 层接收来自通道接口组件的请求并智能地将它们路由到适当的后端应用程序。它也负责将复合请求拆分成几个且较简单的请求,然后将它们路由到多个后端系统。最后,它还负责消息转换及管理不同级别的安全性。在完成这些任务的过程中,它通常使用本地只读数据库来存储路由规则、分解规则、重新组合规则以及转换规则。这些功能考虑到了后面的应用程序模式所采用的私有处理规则一个级别的实现。Exposed Business Services 层通常只实现最少的业务逻辑。业务逻辑的大部分集中在 Backend Application 层。就我们这个情景而言,MAM 服务组件代表 Exposed Business Servieces。

Backend Application 层代表 IMS、DB2 和其他旧应用程序(MAM 服务与这些旧应用程序发生事务操作)的集合。

在大多数情况下,这种应用程序模式使用异步的面向消息的中间件进行实现。组成 Exposed Business Services 层的关键节点中有一个是消息代理节点,它能够执行智能路由、消息转换、分解和重新组合。消息代理通常使用基于规则的产品(如 IBM 的 MQSeries Integrator)来实现。

逻辑解决方案体系结构


既然我们已经确立了基本的业务目标,也选择了一个特定的应用程序模式(或是像本文中的案例那样,选择了几个模式),并且对最终解决方案应该是什么样子有了基本了解,现在是探究基础结构解决方案的特定体系结构的时候了。

逻辑应用程序体系结构
逻辑应用程序体系结构

图 5表明,实际商家或 ESA 伙伴可以通过 Web 浏览器与任何可能的 Channel Interfaces(直接的或间接的)交互。如果大型的 ESA(如 Tier 1)希望扩展他们的商家收购应用程序来远程地与 GC 的 ESA Enablement 解决方案进行交互,那么他们会利用为 GC 的主机到主机通道接口(host-to-host Channel Interface)发布的 MAM 服务 WSDL 文档。不管选择了何种通道交互作用,相关联的 Channel Interface 组件都将会使用 SOAP 消息传递来与 MAM 服务通信。接着 MAM 服务会利用 Web 服务技术(XML、SOAP 和 WSDL)。商家帐户管理(Merchant Account Management,MAM)服务是将在 WebSphere Application Server(它连接到后端中的 MQ-hub)上运行的一组 JavaBean。这些 JavaBean 将实现完成这篇文档中确定的用例所必需的各种操作。一般情况下,JavaBean 实现的操作与在 MAM-WSDL 文档中发布的操作之间存在一对一(1-1)的关系。MAM-WSDL 文档是对以 MAM 服务的形式提供的操作、参数以及数据类型的基于 XML 的服务描述。

一般情况下,每一种 MAM 服务(或 JavaBean 操作)进行如下一般活动:

  1. 按照操作的适当的 XML-Schema 验证任何入站 XML 参数数据的有效性。实际的数据验证是后端应用程序的职责。
  2. 从入站数据创建 IMS 格式的事务。
  3. 将 IMS 事务放到(PUT)IMS Input Queue。
  4. 从 IMS_Output_Queue 获取(GET)IMS 事务响应。
  5. 使用与操作和从 IMS 发送回来的响应数据相关联的 XML 模式创建 XML 响应消息。
  6. 将 XML 响应数据返回到发出请求的通道接口。

Web 服务的适用性


本专栏的第 2 部分中,我们介绍了一条一般规则,该规则是“在所有必须交换信息的边界上(这个边界可以存在于业务之间、应用程序之间或是解决方案的逻辑组件之间,等等),Web 服务将影响业务模式、集成模式以及应用程序模式的实现。”在这种情况下,整个解决方案定义了一个专门为集成组件设计的体系结构。由于这个体系结构,使得用 Web 服务技术进行构建的解决方案对主机到主机通道接口服务和 MAM 服务都适合。

具体来说,这个解决方案采用了内部应用程序组件(它们不是 Web 服务),并将它们作为 Web 服务在外部公开。使用 本专栏的第 1 部分的术语集(参见图 6和图 7),由于与 MAM 服务组件相关联的 Web 服务分别使用 WSDL、SOAP 和 MQSeries 作为描述协议、消息传递协议和传输协议,所以我们将把它归类为企业 Web 服务。另外,由于主机到主机通道服务组件分别使用 WSDL、SOAP 和 HTTP 作为描述协议、消息传递协议和传输协议,所以我们将把它归类为 XML Web 服务。这样做是为了使得外部和内部流程之间具有最佳的互操作性。

面向服务的应用程序协议
面向服务的应用程序协议
Web 服务协议的域
Web 服务协议的域

在通道接口和将被公开的各个业务服务之间使用特定于供应商的传输协议(如 MQ Series)上的 SOAP,有一点令人感兴趣,即它融合了基于 XML 的协议的灵活性和专有协议通常表现优越的强大、功能性和性能。在本案例中,MQSeries 能够充当智能消息代理,从而将不同消息路由到它们的适当目的地,解决方案直接从这里获得了益处。

使用 HTTP 上的 SOAP 通过通道接口在伙伴和 MAM 服务之间进行通信主要是为了确保异构运行时和开发环境(例如 Microsoft .NET 和 J2EE)之间的互操作性。我们看到这样一个完全一样的模式在前面探讨过的业务情景中已经实现。

吸取的经验教训


本专栏的第 4 部分所指出的那样,当考虑 Web 服务技术对一个给定情景的适用性时,您将发现大多数这些情景都会涉及电子商务的扩展企业模式或应用程序集成模式,原因很简单,即 Web 服务是为了给应用程序到应用程序集成情景(上述两种模式也是为了给这些情景建模而专门设计的)这样的类型提供辅助而专门设计的。

另外,这个情景也强调“每一个集成点都是进行抽象的机会”这样一个前提。在这个情景中,对 MAM 服务的接口是使用 WSDL 文档进行抽象而得到的,WSDL 文档使得当在那些服务上面分层地放置许多不同集成通道时具有很大的灵活性。这样的抽象使得组件间的连接具有更好的动态性并且开销更小。


相关主题


评论

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=SOA and web services
ArticleID=55125
ArticleTitle=Web 服务的最佳实践: 第 5 部分
publish-date=03012003