Web 服务的最佳实践: 回到基础部分，第 1 部分

随着有关 Web 服务的广告宣传的减少以及这项技术进入到其采用生命周期的觉醒阶段，企业实体现在正需要一些最佳实践来为他们的采用技术努力提供帮助。本文是一个系列文章中的第一篇，该系列将讨论 Web 服务的构件、适用的业务情形以及企业和 IT 专业人员应用 Web 服务时采用的最佳实践方法。我们首先要做的是回到基础部分列出一个术语集，这将使我们的讨论更加清晰。

正在开发中的用于实现 Web 服务的承诺的技术难题已经（在我们看来）终于被克服了，这使我们能够开始从最初的广告宣传和激动中走出来，全心投入到实际的实现中去。2002 年 4 月，Google 宣布它将让开发者能够使用 WSDL 和 SOAP 技术从他们自己的应用程序上直接查询 20 亿个以上 Web 文档；如果没有什么意外，那这就说明使用 Web 服务来提供实际的应用程序的想法已经真正开始在开发者的头脑中扎根了。实际上，在我们的许多客户服务接触活动中，我们都在见证一个趋势：是客户（而不是传道士）正在推动 Web 服务技术在企业内外的迅速采用。

然而，对于许多正在试图应用这些技术的开发者和应用程序设计师来说，主要的挑战是：在所有的广告宣传中，目前几乎没有提供关于如何在实际的业务情形中最好地应用诸如 SOAP、WSDL 和 UDDI 之类新技术的指导。认识到这个不足之后，来自 IBM 的 Global Services、jStart 和 Emerging Technologies Groups 的许多开发者和设计师已经试图针对各种情形找出 Web 服务技术的实际应用程序的一组最佳实践并对其归档。

其过程很简单。我们的方法的关键在于我们将研究实际的业务情形 ― 不是拼凑起来说明我们认为事情应该怎么样的假想情形，而是客户在他们的企业中 实际应用这些技术来解决实际问题的情形。在这些情形中，我们问一些非常关键的问题：

解决方案的业务目标是什么？

解决方案实现哪种通用的电子商务模式？

应用程序的逻辑体系结构是什么？

如何、在何处以及为什么将 Web 服务技术用于构建应用程序？

在应用程序中使用 Web 服务获得了哪些特别的优点？

关于所使用的技术和方法学我们学到了什么（正面的和负面的）？

本文是归档和探讨我们的发现的系列文章的第一篇；这个系列文章对解决方案设计师以及其他处在需要决定应该如何（或是否）在某个特定项目中采用 Web 服务技术和设计方法学的情况下的人员将最有帮助。本系列文章的路线图将相当简明。我们将首先奠定一个基础，用来解释我们用来确定和分类各种最佳实践的语言和方法。这个过程将包括我们在这第一篇文章中将要定义的一个 术语集，或者说是一组公共术语，以及重点介绍 IBM 的电子商务模式（请参阅 参考资料）与我们的最佳实践成果之间的关系的第二篇文章。第三篇及随后的几篇文章将针对一组实际的业务情形就上述六个问题中的每一个进行讨论。最后，我们将提供一篇总结性的文章，文中将提出我们对这一组最佳实践的建议。

Web 服务是什么？

这样说可能是公正的，即最初有关 Web 服务的广告宣传的数量已经如天文数字般庞大，这些广告宣传是如此之多以至于用于描述什么是 Web 服务以及如何着手实现 Web 服务的语言正变得含义过多，而且十分混乱。事实上，最近刚刚组建的 W3C Web Services Architecture Working Group 迄今为止所面临的最困难的任务之一就是确定下面这个看似简单的问题的答案： Web 服务的一般定义是什么？按照所有的广告宣传来看，您可能认为获得这样的一个定义并不困难。然而，难点在于要解决定义过多的问题，大多数定义是相互矛盾的且仅揭示了 Web 服务可以是什么或者可能成为什么的一部分。

在挑选一组最佳实践时，最重要的首要步骤之一是要确保用于描述各种核心概念的语言是清楚、简炼且准确的。遗憾的是，您还不得不在已经存在的且已被接受的术语集范围内进行工作（不管现有的名称或术语可能多么令人困惑）。例如，SOAP 协议本身就是 Web 服务领域中命名不恰当的技术的“典范”：尽管该首字母缩写代表 简单对象访问协议（Simple Object Access Protocol），但是它描述的却是一个与对象没有多大关系并且实现起来也远非那么简单的消息传递协议规范。

W3C Web Services Architecture 小组达成一致意见的 Web 服务的暂行定义如下所示：

Web 服务是由 URI 标识的软件应用程序，其接口和绑定可以通过 XML 构件进行定义、描述和发现，Web 服务支持通过基于因特网的协议使用基于 XML 的消息与其他软件应用程序直接交互。
对于那些认为 Web 服务仅限于是用于通过 HTTP 连接来调用应用程序的方法的 SOAP 消息（如传统的 SOAP 股票报价服务所做的那样）的人来说，这个定义可能有点儿令人吃惊。但是，这个定义告诉了我们两件与我们的公共术语集目标相关的、我们感兴趣的事情：

Web 服务可以不需要 SOAP。

Web 服务可以不需要 HTTP。

然而，Web 服务确实需要可以用来描述服务的形式和功能的某种基于 XML 的描述机制（如 WSDL）。请记住，有关 Web 服务技术的这种业界范围的倡议的背景框架是一个面向服务的体系结构（service-oriented architecture，SOA；如需更多信息，请参阅下面的 参考资料部分）。因此，一个基于非 XML 的描述机制（如 IDL）将使 SOAP 实现更复杂且开放程度更低。

还要注意到，W3C 的定义尽管提到了服务发现，但并未提到 UDDI 或其他任何特定的发现机制。在我们逐个讲述各种业务情形并探讨如何以及为什么使用某些特定的服务发现机制时，这个事实将变得很重要。具体来说，尽管关于 Web 服务体系结构的早期文献断言 UDDI 要扮演一个核心的、至关重要的角色，但使用 Web 服务的业务解决方案的实际实现却证明，UDDI 实际上仅在目前这个时候能起到最重要的作用；事实上，人们构建了许多并未以任何方式使用 UDDI 的 Web 服务解决方案。在当前的绝大多数业务案例中，可以有把握地说，这些发现机制还不是用于集成业务伙伴之间的流程的核心组件。

回页首

定义我们的术语，缩小我们的重点

W3C 的 Web 服务定义具有深远的影响，这表现在字面上可以被称作 Web 服务的东西的范围包括可以使用 XML 语法唯一地标识和描述的 任何软件组件。这个范围可能是无限的，对我们概述一组最佳实践根本没有任何帮助。术语 Web 服务本身难以表示符合宽泛的 W3C 定义的应用程序的整个范围，因为许多这样的应用程序可能永远不会涉及 Web 或构建 Web 时所依托的技术。尽管如此，我们还是必须以某种方式将术语 Web 服务包括在我们的术语集中，因为它已经与我们的讨论所涉及的技术领域联系在一起了。

在开始分析客户情形的时候，我们发现需要提出新的观点和术语集来区分在使用现有的不同描述协议、消息协议和传输协议的过程中出现的各种 Web 服务 子类型。我们从 图 1所示的文氏图入手，该图标识了一系列可能的开放协议，这些开放协议在面向服务的应用程序中可能会用到，也可能用不到。

图 1. 面向服务的应用程序协议



我们从 图 1中得出我们新术语集中的头两个定义：

Web 服务（Web services）是使用以下三个主要技术类别中的一些特定技术开发的软件组件：

基于 XML 的描述格式（例如，WSDL）

应用程序消息传递协议（例如，SOAP）

一组传输协议（例如，HTTP）

在上述每个类别中，都有专有（特定于供应商或平台的）技术和开放（与供应商或平台无关的）技术可供使用。

面向服务的应用程序（Service-oriented application）包括 可能利用 Web 服务技术（如 SOAP）但 可能不包括 WSDL 或其他基于 XML 的描述的应用程序。这样的应用程序被看作是 类似于 Web 服务的，但从技术上讲它们不是 Web 服务。

考虑了 W3C 的定义和 图 1中的文氏图之后，我们可以说，使用某种基于 XML 的描述机制描述的软件的任何部分都可以成为 Web 服务。即便这样的应用程序使用了任何其他 Web 服务技术也没有关系。使用与编程语言相关的消息传递协议（例如，JMS）和专有传输协议（例如，MQSeries）的应用程序，只需提供该应用程序接口的 WSDL 描述，就完全可以成为一个完全符合定义的 Web 服务。反之，通过 HTTP 发送 SOAP 消息但不提供 WSDL 描述的应用程序则不能成为 Web 服务，尽管它将被看作类似于 Web 服务的并且被视为面向服务的应用程序。

既然已经给出了我们对Web服务的新定义，现在让我们将重点放在 图 1中表示开放的基于 XML 的描述的圈上。此外，让我们将重点还放在 Web 服务技术原先就瞄准的“痛处”上：集成和互操作性。这两个“痛处”与企业内部和外部的应用程序开发都有关系。无论您是需要与后台办公系统（back office）中的传统 COBOL 应用程序集成，还是需要与因特网上某个外部服务器中的分布式应用程序集成，您都需要在应用程序中构建一些抽象点，以确保集成和互操作性的简单易行。这个领域中的一种 事实标准描述语言是 WSDL，创建该语言的目的是给服务的接口和实现提供一个抽象层。

因为 WSDL 是一种可能的、开放的、基于 XML 的描述语言，所以存在着一类选择使用 WSDL 作为它们的描述协议的 Web 服务。在图 2 中，我们说明了 Web 服务的一个这样的子集，并且得出了三个新术语添加到我们的术语集。

图 2. Web 服务协议域



企业 Web 服务（Enterprise Web services）是肯定提供了 WSDL 描述但 可能使用专有应用程序消息传递协议或传输协议的 Web 服务。使用 JMS 通过 IBM MQSeries 发送 SOAP 消息的 Web 服务就是这种服务的一个示例。

因特网 Web 服务（Internet Web services）是 必须仅使用开放的应用程序消息传递协议或传输协议的企业 Web 服务。通过 HTTP 发送 OTA XML 消息的企业 Web 服务就是这种服务的一个示例。

XML Web 服务（XML Web services）表示因特网 Web 服务的一个很小的子集，这类服务 必须使用已经被 W3C 采用的、通过为数不多的几种传输协议进行传递的、基于 XML 的消息传递协议。具体来说，XML Web 服务将只发送 SOAP 消息，并且只能通过 HTTP、SMTP 或原始 TCP/IP 连接来发送这些 SOAP 消息。

这些新定义记录了过去几年间业界中许多人所传播的概念，同时提供了对组件子集进行归类的语义框架，这些组件子集是原来的（含义过多的）术语 Web 服务试图记录但却没能表述准确的。例如，Microsoft 的 .Net 策略将重点放在 XML Web 服务上，而 CommerceQuest 的 CICS Process Integrator（CPI）则将重点放在企业 Web 服务上。就 Web 服务技术而言，这个新的术语集为理解这两家公司的意图提供了一个框架。

回页首

以后的文章将讨论哪些内容？

就像我们在开篇时所叙述的，这个系列文章的目的就是探讨各种实际的业务情形，并从中挑选出一组针对企业环境下 Web 服务的设计和实现的最佳实践。本系列中将来的文章每篇都将重点介绍一种情形，并且将使用这第一篇文章中介绍的语言和分类对我们的发现进行归类。这个过程的关键要素是拙作只讨论那些能很好地反映今天所能做到的角度的实际情形。我们不打算讨论理论或假想的推测。我们将根据公共的、经验证的设计模式、策略和企业环境的最佳实践来分析和评估每一种情形。而且，对于在任何给定情形下，使用 Web 服务技术会如何帮助（或妨碍）体系结构，我们都将实事求是地讨论。

Web 服务并不是万灵丹，但对于许多客户情形却是非常适合的一种变通方案。Web 服务在企业中扮演着重要角色。我们的目标就是的提供一组能帮助设计师和开发者将 Web 服务技术集成到他们的电子商务应用程序中的最佳实践。