内容


Web 服务的最佳实践

回到基础部分,第 2 部分

面向服务的体系结构、Web 服务和 IBM 电子商务模式

Comments

系列内容:

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

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

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

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

本系列的第一篇文章中,我们提供了一个精确的术语表以使先前混乱的主题变得有条理的、清晰的。我们研究了不同类型的面向服务的体系结构,这些体系结构融合了开放的和专有的技术,并且我们创建了一个术语表以将它们归入 Web 服务的子类型中或是把他们描述为类似 Web 服务的实现。在掌握了这个新的术语表后,IT 设计师和业务流程的所有者就能更轻易地把他们的独一无二的需求映射到已建立的最佳实践设计技术和模式中。

在过于深入之前,我们想要先简要地重申一下什么是我们所谓的 面向服务的体系结构(service-oriented architecture,SOA),因为我们 不能仅仅讨论 Web 服务。SOA 是设计和构建松散耦合的软件解决方案的方法,这个解决方案能够以程序化的可访问的软件服务的形式公开业务功能,以使其他应用程序可以通过已发布的和可发现的接口来使用这些服务。通过应用 SOA,一个企业可以使用一组分布式服务来构成并组织应用程序;这样,他们就能通过重用他们自己的资产和他们伙伴的业务功能来构造新的应用程序和修改现有的应用程序。Web 服务代表了面向服务的体系结构的一种实现,但并不能认为所有的 SOA 应用程序都是 Web 服务。您可以通过访问下面的 参考资料部分中的有关链接来获得关于面向服务的体系结构的更多信息。

许多电子商务应用程序都能处理一组常用的需求,比如集成、互操作性、安全性、可靠性、可伸缩性以及可用性。您不必感到太惊讶的是一组常用的基础结构概念能支持各种特定的解决方案需求从而最大程度地减少体系结构工作量和运作成本。为了促进基于实际经验的最佳实践,IBM developerWorks 已经记录了一组电子商务模式以使解决方案设计师能够发现已被证明成功的解决方案的本质和常用的要素。我们通过叙述每个模式所处理的问题以及应用每个模式时需考虑的注意事项来描述每个模式。电子商务模式是一组可重用的资产,它能有助于加快基于 Web 的应用程序(包括那些利用 Web 服务的应用程序)的开发过程。

在本文中,我们将探讨 IBM 的电子商务模式,并且要了解它们与 Web 服务的关联有多密切。随着这一系列文章的延续,我们将使用这些模式以及我们在本系列第一部分中创建的新术语表来指导我们如何对利用了 Web 服务技术的特定的实际业务情景进行研究。

快速浏览 IBM 电子商务模式

IBM 电子商务模式是根据 IBM 设计师的共同经验发展而来的一组最佳实践模式。通过运用在真实客户情景中被证明成功的常用概念,开发者可以使用这些模式快速而高效地构建解决方案。这些模式本身被分为截然不同的四类(您可以通过访问下面的 参考资料部分中的链接来获得更多信息):

  • 业务模式是能够被用于建立任何解决方案的主要业务目的的高级构造。
  • 集成模式将单独的业务模式聚集起来以满足一个完整的电子商务解决方案的整体需求。
  • 应用程序模式有助于改善业务模式以使它们能为基于计算机的解决方案所实现。通过找出并描述高级的逻辑组件(这些组件需被用来实现在每个业务模式中找出的主要功能),这些模式有助于改善业务模式的结构。
  • 运行时模式被用来定义逻辑中间层结构,这些逻辑中间层结构被用来支持应用程序模式。运行时模式代表了主要的中间层节点、它们的角色以及它们之间的接口。它们也考虑如何将处理逻辑和数据放置在这些节点上。

您常常听说应用程序模式和运行时模式被称为 设计模式,这是因为它们反映了所构建的应用程序的具体的物理设计。

当您在阅读电子商务模式的文献时,您还将遇到 合成模式这一术语。合成模式将多个业务模式和集成模式组合在一起以处理更大的一组公共需求。合成模式能够被应用到用于各种目的的应用程序中,这些应用程序包括电子交易、门户网站以及帐户访问程序。(请参阅 参考资料中上述三者的链接。)

需要着重指出的是诸如 Web 服务之类特定技术的出现并未直接影响 现有的业务模式、集成模式以及应用程序模式。然而,这些技术对如何在运行时模式的应用程序中 实现集成模式的确影响颇深。此外,由于业务模型以及它们的相关需求在本质上是不断演化的,通过成功地应用 Web 服务,新模式随着时间的推移而不断出现将是完全可能的。

随着这一系列的延续,我们将讨论业务情景,在这些业务情景中我们将概述如何使用特定的电子商务模式以及 Web 服务技术的使用对各种集成模式的实现有何影响。

您可以在下面的 参考资料部分中找到 IBM 电子商务模式的其他细节的链接。

把解决方案需求映射到电子商务模式中

在我们能彻底理解 Web 服务如何适应这些已建立的模式之前,我们需要了解如何将业务需求映射到个别的模式中。只有到那时我们才能很好地理解如何在一种给定的情况下应用 Web 服务以达到我们的业务目标。为了要这样做,我们将研究一些在着眼于电子商务解决方案的企业中相当常见的业务驱动程序。然后,通过使用 IBM 电子商务模式 Web 站点上提供的工具,我们就能够使需求与适当的模式相匹配。在 表 1中,最左边的列解释了业务驱动程序,这些业务驱动程序与列在最上端一行中的各种模式进行匹配。要详细了解每一个模式,请单击它的名称。

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

表 1顶部所列出的各种业务模式和集成模式中的每一种模式在满足所讨论的各种业务需求时都有相对的优点与缺点。然而,需要着重指出的是许多业务解决方案将包含匹配这些个别模式中的大部分的要素,而且没有哪个单独的模式能够完整地描述任何单个解决方案。设计这些模式的目的是帮助指导设计过程,而不是以任何方式来限制它。

为了举例说明所有这些是如何应用到 Web 服务中,让我们花一些时间来看看一个自助服务模式的实现如何帮助一个组织向它的伙伴开放它的业务流程。对于这个组织来说,显而易见的解决方案是以 Web 服务的形式发布它的业务流程。在这样一个上下文中,Web 服务技术被广泛地用于简化信息的访问、聚集与演示。有了这些技术以后,我们能集成各种后端服务以提供可从多个通道来访问的无缝的前端。

采用相同的方法,我们也可以研究 Web 服务技术是如何简化应用程序集成以帮助这些组织重用现有的业务流程。由于 Web 服务提供它们的接口和行为的描述而这些描述是明确定义的且可通过程序来访问,所以,在允许松散耦合的、异构的环境的同时将它们直接集成到其他应用程序中也是可能的。

同样,这里的目的只是提供基本的概述,以说明在根据起初的一组业务需求来设计面向服务的应用程序的过程中,如何使用电子商务模式来指导设计。这个讨论并不打算提供电子商务模式的完整描述。我们强烈推荐您花一些时间来回顾 developerWorks 电子商务模式 Web 站点(请参阅 参考资料),逐个了解各类模式,理解每种模式的业务驱动程序,并熟悉每个模式被设计所要模拟的解决方案的类型。这样做将帮助您更好的理解应用程序中 Web 服务的角色。

Web 服务如何影响运行时模式

就像我们所提及的那样,Web 服务几乎不影响现有的一组业务模式、集成模式以及应用程序模式。然而,它们的确对那些模式的 实现影响很大。要理解 Web 服务如何以及为什么影响那些模式的实现,让我们首先回顾设计 Web 服务技术所要实现的主要优点:

  • Web 服务通过将业务流程封装在可重用的组件中来帮助降低复杂性。
  • Web 服务通过包装旧的或特定于平台的应用程序来帮助提高互操作性。
  • 通过整合 Web 服务来执行更高级的业务功能。
  • Web 通过使用标准的或者众所周知的接口定义来帮助隐藏后端的实现细节。
  • Web 服务通过提升松散耦合和延时绑定来实现即时集成。
  • Web 服务与平台和实现无关,因而它促进了真正的互操作性。
  • Web 服务利用现有的、已建立的因特网标准。

在回顾各种更高级的电子商务模式时,我们清楚地意识到为了确定 Web 服务如何适应某个解决方案或模式,我们需要分析实现模式或运行时模式,并指出在模式的何处可以使用 Web 服务来改进现有技术当前所提供的优点。

举例来说,一个被用来实现自助服务业务模式的公共应用程序模式被称之为直接集成的单通道(Directly Integrated Single Channel),如 图 1所示。在这个模式中,外部业务伙伴通过单个前端应用程序与多个后端业务流程进行交互。

图 1. 直接集成的单通道应用程序模式
直接集成的单通道应用程序模式
直接集成的单通道应用程序模式

我们能用许多不同的方法来实现这一模式。 图 2说明了其中的一种方法:一个组织可以建立一个提供图形用户界面的因特网 Web 站点,业务伙伴能够登录该站点并访问各种后端流程。虽然这是一种有效的解决方案,但它对想要把目标组织的公开的服务更紧密地集成到他们自己的业务流程中的业务伙伴提出了严峻的挑战。基于浏览器的 Web 界面适合于与用户交互,但当集成需要发生在应用程序到应用程序级别时他们就不再那么管用了。

图 2.直接集成的单通道应用程序模式的传统 Web 设计
直接集成的单通道应用程序模式的传统 Web 设计
直接集成的单通道应用程序模式的传统 Web 设计

应用我们已经探讨过的基本工具,我们可以看到,在我们的组织与它的伙伴之间实现可编程的集成的更好的方式是使该组织利用组合了自助服务业务模式和扩展企业业务模式的合成模式来以 Web 服务的形式公开它的前端应用程序。这些伙伴随后就能将这些服务直接插入他们自己的流程中。通过运用 Web 服务技术,使直接集成更容易维护与发展,并且还能降低总体成本。与此同时,该组织可继续向相同的业务流程公开基于浏览器的、人类可阅读的界面同时利用相同的基于 Web 服务的基础结构。

图 3. 直接集成的单通道应用程序模式的基于 Web 服务的设计
直接集成的单通道应用程序模式的基于 Web 服务的设计
直接集成的单通道应用程序模式的基于 Web 服务的设计

作为一般的规则,在所有必须交换信息的边界上(这个边界可以存在于业务之间、应用程序之间或是解决方案的逻辑组件之间,等等),Web 服务将影响业务模式、集成模式以及应用程序模式的实现。Web 服务技术的设计意图是实实在在地改善那些信息交换边界的互操作性和灵活性。然而,在那些边界上 Web 服务技术 应该的应用程度完全取决于每个解决方案的个别需求,这一点我们将在本系列随后的文章中所探讨的特定的实际情景中实现。

Web 服务运行时模式的行为

应该牢记的要点:虽然具体的编程模型不了解各种应用程序模式和运行时模式,但是这些模式通常指出是倾向于选择同步实现还是异步实现,是选择 RPC 样式还是文档交换样式。这样的决定对如何实现业务目标影响很大。

Web 服务总是被设计成至少适用于两种基本的编程模型: 远程过程调用(remote procedure calls,RPC)和 文档交换。RPC 需要有一个客户机/服务器模型,在这个模型中客户机要求服务器执行特定的活动,该活动的结果应该被立即返回到客户机。RPC 模型中的通信通常是同步的,并且请求的操作通常代表了细致且个别的工作项(例如:检查一个订单的状态)。文档交换通常是异步的并且它涉及到在对等伙伴之间移动业务文档(比如说一个购买订单)。(要获得更多有关两者的差异的信息,请参阅下面的 参考资料部分。)

不幸的是,由于对术语的错误使用和混淆,文档样式 Web 服务和 RPC 样式 Web 服务之间的差异正变得极为模糊。许多 Web 服务实现当前所调用的文档样式 Web 服务实际上却是 RPC 样式Web 服务,该 RPC 样式 Web 服务使用某一种机制来定义并确认被交换的 Web 服务消息的内容。我们将在今后的文章中更详细地探讨这个问题。

展望未来

本文和前一篇文章共同的目标是建立一个基本的语义的、有组织的基础,我们可在此基础上开始分析那些由 Web 服务在其中扮演关键角色的实际业务应用程序。分析的最终结果将产生一组 Web 服务体系结构与设计的通用的最佳实践。在今后的文章中,我们将开始介绍一个在金融服务业中需要应用程序集成的电子商务应用程序的示例,并由此开始探讨那些实际应用程序。我们将更为详细地研究特定的需求、模式、设计以及据此作出的实现决定 - 并且看看 Web 服务技术如何演好这个角色。

致谢

从消费品制造工业中的一个客户处所获得的实用的经验直接影响了本文。为那个项目作出贡献的人是 William A. Brown、Raghu Varadan 以及 Martin J. Burns。作者同样对 IBM 电子商务模式主要的设计师的帮助表示感谢,感谢他们为本系列的文章提供反馈。


相关主题


评论

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

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