内容


Web 服务的最佳实践

一个受管的公共流程和私有流程应用程序模式情景

语义框架的形成

Comments

系列内容:

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

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

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

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

在本系列的头两篇文章(请参阅 参考资料)中,我们介绍了一个语义框架并应用 IBM 电子商务模式的技术提出了一种方法,该方法用于分析为什么 Web 服务可以在电子商务应用程序中起作用以及可以在电子商务应用程序中的什么地方起作用。我们所采取的方式一直是着眼于实际的客户向我们提出的各种业务问题,并且用 IBM 电子商务模式为我们提供的语义的和组织的框架来探讨已经开发出来用于解决这些问题的解决方案。在这篇文章中,我们将着重讨论一个独立软件供应商(independent software vendor,ISV),它打算将 Web 服务技术结合到产品套件中以便使它们的客户能够将自己的软件更好地集成到定制的第三方解决方案中。

对于许多正在试图应用 Web 服务的开发者和应用程序设计师来说,主要的挑战是:目前几乎没有提供关于如何在实际的业务情景中用最好的方式应用诸如 SOAP 和 WSDL 之类新技术的指导。本文的目标是采用一个实际的业务示例并针对我们在前几篇文章中列出的概念来分析它;在此过程中,要吸取一些经验,了解如何把这项新技术的承诺与用它解决现实问题的现实性结合起来。具体来说,我们将针对下面一组问题来分析该示例情景:

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

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

业务目标

协作型企业软件(Collaborative Enterprise Software,CES)是一个开发并提供企业范围的解决方案的 ISV,这些解决方案提供一套 ERP 应用程序和 CRM 应用程序供客户运营他们的企业。许多 ISV 都是这样的,CES 需要一种方法来使它们的客户能够把第三方应用程序和它们的工具套件提供的业务功能集成在一起。具体来说,CES 需要一个满足下面列出的所有功能目标的解决方案:

  • 使客户能够在因特网上执行第三方应用程序。
  • 使位于客户环境外部(例如在防火墙外)的第三方应用程序能够执行客户业务流程或功能以实现企业到企业(B2B)的协作。
  • 一个提供一组公共的基础结构服务的框架,这些基础结构服务供支持 B2B 消息交换的客户应用程序使用。例如:安全性、消息验证、数据转换、不可抵赖性、超时/重试等。
  • 集成现有业务组件和功能。
  • 将业务服务发布到公共注册中心和私有注册中心。
  • 各种运行时和开发平台之间的互操作性。
  • 为日志记录、跟踪消息交换以及安全性策略实施提供操作支持。
  • 定义并实现服务策略的质量要求。
  • 支持现有的因特网和 B2B 安全性工具(认证/授权、持久安全性上下文、单点登录)以及新兴的安全性模型。
  • 为创建和部署服务、数据同步、发现和发布服务、开发和管理定制解决方案组件提供工具支持。
  • 支持外部分类法(索引系统)以对业务流程和功能进行分类。

另外,该解决方案还提出了许多非功能性要求。这些要求不一定会影响解决方案组件本身的开发,但却会影响客户解决方案的操作环境。这个环境包括操作系统,但并不仅限于操作系统,还包括软件应用程序服务器和技术兼容性。所提出的非操作性要求如下所示:

  • 坚持使用开放的标准和业界支持的公共规范以支持互操作性。
  • 一个可以在 J2EE 版本 1.3 兼容的 Application Server 上部署的、遵循 Java 2 企业版(Java 2 Enterprise Edition,J2EE)的框架,。
  • 支持各种各样的操作系统,包括:IBM AIX、IBM OS/400、Sun Solaris、HP HP-UX 以及使用一台应用程序服务器的 Microsoft Windows NT 和 Microsoft Windows 2000。
  • 可伸缩的并且是轻量级的,能够适应将来的发展并且对服务的执行性能产生最小的影响。
  • 支持轻松的经营和管理。
  • 支持通过一组集成 API 的轻松的开发。

从纯商业角度讲,ISV 过去一直在寻求一种方法以使客户能够将解决方案与它们的软件集成,这样将减少集成成本(为 ISV 和客户)、增加现有资产的使用、改善客户和业务伙伴的关系,使客户能够访问一组更广泛的客户机和业务伙伴、给他们更大的灵活性以跟上业务要求的不断变化以及缩短开发和部署生命周期。

适用的电子商务模式:受管的公共流程和私有流程

根据所述的业务目标和技术要求,我们已经能够得出解决方案的整体需求,从而提供一个集中的控制点,通过该控制点可以集成、管理和监视公共的和私有的业务流程及功能。解决方案特别需要提供一个可插的体系结构,在利用一组公共的基础结构服务的同时,ISV 的客户可以在这个体系结构中无缝部署业务功能以及企业到企业流程。

表 1(这张表在我们以前的文章中出现过,您应该认识它)中,我们已经将业务要求映射到了具体的电子商务模式。我们可以用这张表来帮助我们确定具体的电子商务模式,该模式有助于我们了解需要构建的解决方案的基本组件。在这张表中,我们已经突出显示了适用于当前情景的要求,淡蓝色显示的是最适用的。

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

阅读这张表,我们面前出现了许多不同的选项。为了最终确定一个适当的模式,我们需要用我们所述的需求作为向导更深入地研究电子商务模式的目录。回顾一下表中突出显示的三行,通过对业务目标和技术目标的回顾,您应该很清楚地看到第二个要求(“ 业务流程需要与存在于伙伴组织中的流程和信息进行集成。”)是最关键的。有两组能让我们满足这一要求的模式:扩展企业(Extended Enterprise)和应用程序集成(Application Integration)。

扩展企业业务模式(也被称为企业到企业模式或 B2B 模式)处理不同企业中的业务流程之间的交互和协作。这种模式常被用于实现连接企业内部应用程序的编程接口的解决方案。同样,它不包括由跨越组织边界的业务伙伴通过用户界面直接调用的应用程序(这将通过自助服务业务模式解决)。无需用户直接调用多个应用程序和信息源,应用程序集成模式就可以集中它们;应用程序集成模式将重点放在应用程序和数据之间的关系上。

我们已经讨论过了,ISV 正在寻求的解决方案包括跨企业域集成业务流程和功能的能力。记住了这一点,就应该清楚扩展企业模式最适合我们的项目。如果还不清楚,那么记住:我们有意于将电子商务模式意用作应用程序设计的通用指南;任何单独的业务解决方案(尤其是那些有可能和 <Company Name/> 请求的业务解决方案一样复杂的业务解决方案)都非常有可能适合多种模式。给定了目标,窍门就在于查找最适合的模式。在这个例子中,最适合的模式碰巧就是扩展企业模式。

进一步回顾旨在实现扩展企业解决方案的应用程序模式时就会发现,对于给定的要求来说,受管的公共流程和私有流程模式逐渐表明它是最优秀的。这种模式概述了一个能够集成多个业务伙伴的流程和功能的系统,这些业务伙伴将长时间运行的外部事务映射为内部业务流程和工作流。

图 1. 受管的公共流程和私有流程应用程序模式
图 1. 受管的公共流程和私有流程应用程序模式
图 1. 受管的公共流程和私有流程应用程序模式

实现这种模式的解决方案一般要涉及到创建公共流程组件和私有流程组件。公共组件主要负责实施一致通过的业务协议和服务质量协议。私有组件负责管理长时间运行的事务并将它们映射为内部业务流程和工作流。这些组件一起工作,使内部应用程序和外部应用程序能够使用各种协议彼此集成。

就 ISV 请求的解决方案而言,实现基于受管的公共流程和私有流程模式的解决方案意味着该框架将需要创建一个由这些公共组件和私有组件组成的流程管理网关、将它们的核心基础结构服务集成到该网关中并使用非专用消息传递和通信协议以使第三方能够与网关集成。

图 2:ISV 的集成网关的基本运行时体系结构
图 2:ISV 的集成网关的基本运行时体系结构
图 2:ISV 的集成网关的基本运行时体系结构

逻辑解决方案体系结构

既然我们已经建立了基本的业务目标、选择了一个具体的应用程序模式并且对于最终解决方案的样式有了基本的概念,那么就该研究基础结构解决方案的体系结构了。

在解决方案体系结构中,将使用 J2EE 编程模型和连接器体系结构以及新兴的一组 Web 服务标准来构建 ISV 的集成网关。就 Web 服务基础结构而言,所使用的方法就是最大程度地使用中间件组件(它们利用了 Web 服务技术)、利用现有系统组件的功能并利用集成点来集成现有的软件资产。

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

受管的公共流程和私有流程应用程序模式的公共组件包含一个实现了 Web 服务代理功能的 Web 应用程序服务器,它使得 ISV 的公共基础结构服务和客户的业务流程能被作为 Web 服务公开,使外部业务伙伴能够访问和调用它们而不用考虑正在使用的操作系统或开发平台。

受管的公共流程和私有流程应用程序模式的私有组件将由 Web 应用程序服务器(托管 ISV 提供的各种应用程序)和定制解决方案(由客户或第三方软件供应商开发的)组成。这些应用程序中的每一个都将实现那些将被作为 Web 服务公开的业务流程和功能。公共组件和私有组件将使用 Java 技术本机机制(如 RMI 和 JMS)彼此进行通信。当一个新的业务流程被部署到私有应用程序环境中时,它将在公共环境中被注册为 Web 服务并被发布到私有的和公共的 UDDI 注册中心。私有的 UDDI 注册中心帮助公共组件了解在哪里实现私有流程以及如何实现私有流程。公共的 UDDI 注册中心使外部业务伙伴能够发现和访问已公开的业务流程的 Web 服务接口。

Web 服务调用的双向支持对于阐述已定义的体系结构如何使 ISV 满足它们所有的状态要求是很重要的。

Web 服务的适用性

在本专栏的第二篇文章中,我们介绍了一个一般的规则“只要必须跨边界(业务之间、应用程序之间、一个解决方案的逻辑组件之间等)交换信息,Web 服务就会影响业务、集成和应用程序模式的实现。”(请参阅 参考资料。)在这种情景下,整个解决方案定义了一个专门为集成组件设计的体系结构。因此,一个完全构建在 Web 服务技术上的解决方案是适当的,至少对于应用程序的公共组件而言是适当的。

具体来说,这个解决方案采用了内部应用程序组件(它们不是 Web 服务)并将它们作为 Web 服务在外部公开。我们将使用本专栏的第一篇文章中列出的术语对那些被作为 XML Web 服务公开的 Web 服务进行分类,这些 Web 服务由于使用 WSDL、SOAP 和 HTTP 而分别被分类为描述、消息传递和传输协议。(请参阅 参考资料。)这么做是为了允许外部流程和内部流程之间最大程度的互操作性。

图 4:面向服务的应用程序协议(来自于最佳实践 #1)
图 4:面向服务的应用程序协议
图 4:面向服务的应用程序协议
图 5:Web 服务协议的域
图 5:Web 服务协议的域
图 5:Web 服务协议的域

然而,解决方案的公共组件和私有组件之间的通信使用的是本机通信和消息传递协议,而不是 SOAP 和 HTTP。尽管如此,为了允许轻松地集成到 WebSphere Web 服务网关环境中,我们仍然使用 WSDL 文档来描述私有的内部应用程序,按照我们的新术语,WSDL 文档称这些私有的内部应用程序为企业 Web 服务(Enterprise Web Services)。差别虽然是细微的,但对于理解这种情景下的 Web 服务技术的适用性是很重要的。

实现 XML Web 服务主要是为了确保跨异构运行时和开发环境(例如 Microsoft .NET 和 J2EE)的互操作性。另一方面,实现企业 Web 服务是为了利用应用程序之间松散耦合的集成点。SOAP 和 HTTP 是被广泛接受的、可互操作的消息传递和传输协议(很多种环境都支持这两个协议);它们还是标准化的,或者在正在被标准化的过程中。这使得它们成为用于互操作性用途的理想对象。从术语的最严格意义上来说,JMS 和 RMI 并不是开放的标准,除 Java 技术平台外,其他平台并不支持它们,它们也不是确保互操作性的最佳工具;但是它们的确形成了一个用于集成运行在 J2EE 环境中的应用程序的优秀框架。因为 ISV 的集成网关中的公共组件和私有组件都是基于 J2EE 技术的,所以使用 JMS 和 RMI 是非常合适的,而且比 SOAP 和 HTTP 效率高得多。

还要注意,UDDI(一项用于发布和发现 Web 服务的技术)以公开的方式和私有的方式用于解决方案体系结构中。以私有的方式,UDDI 注册中心用于跟踪那些必须通过网关被作为 Web 服务公开的内部流程。以公开的方式,UDDI 注册中心用于发布那些已公开的业务流程,使第三方能够发现和访问它们的 Web 服务接口。

只要有可能,解决方案就会使用本机 API 和集成点。例如,当 Web 服务网关与内部业务流程进行交互时,无论是通过 JMS、RMI 还是通过 Java 连接器体系结构(Java Connector Architecture),它都使用本机的、内建的机制而不是通过使用与 SOAP 接口类似的东西来实现。原因很简单:这个解决方案更为高效且节约成本。几乎没有什么为这些组件重新创造接口的原因。使用了适当的开发工具,为这些本机接口创建 WSDL 描述就比较简单且直接。

吸取的经验教训

在构建这种情景的基础结构体系结构和初始原型实现时,我们吸取了涉及到的技术、标准和业务概念方面的几点重要经验教训。

  1. 业界工具对于高效重用现有的应用程序(例如用 Java 连接器体系结构资源适配器自动生成 WSDL 描述)是很重要的。
  2. 至此,Web 服务还未给定互操作性。在本系列以后的文章中我们还要解决大量待解决的问题(特别是着重讨论互操作性问题以及关于如何处理这些问题的一些最佳实践建议)。
  3. 现有的标准提供一些机制以支持这种情景所需要的异步操作类型,但异步操作还没有成为现在的标准不可或缺的一部分。Web 服务的业务流程执行语言(Business Process Execution Language for Web Services,BPEL4WS)是迈向必需的支持的一步,但还需要做更多的工作。
  4. 让现有的客户群使用新的技术模型而不停止当前产品的销售,这是一个挑战。

另一个关键的经验来自于对这种情景以及我们在本专栏系列的第三篇文章中讨论的前一种情景(请参阅 参考资料。)的回顾。这两种情景都特别重点讨论了应用程序到应用程序(application-to-application)的集成解决方案。当考虑 Web 服务技术对一个给定情景的适用性时,您将发现大多数这些情景会涉及电子商务的扩展企业模式或应用程序集成模式。

最后,这个解决方案广泛应用了 Java 技术本机通信协议和接口这个事实证明了 Web 服务技术并不是在每种情况下都适合。例如,考虑一下当上面讨论的情景广泛应用 UDDI 时,我们在本系列第三篇专栏文章中讨论的情景绝对不会使用 UDDI,也就是说 UDDI 不是必需要的。Web 服务技术是被设计用来提供各种单个组件的,这些组件 可以被集成在一起提供更复杂的功能。在开发应用程序和系统时,这会给我们带来相当大的灵活性和相当多的选择。


相关主题


评论

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=SOA and web services
ArticleID=55148
ArticleTitle=Web 服务的最佳实践: 一个受管的公共流程和私有流程应用程序模式情景
publish-date=12012002