级别： 初级 Rimas Rekasius (rimas@us.ibm.com), 高级软件工程师, IBM
2003 年 3 月 01 日 最近，Web 服务互操作性组织（Web Services Interoperability Organization，WS-I）发布了 WS-I 样本应用程序使用案例和体系结构文档的公开的工作组草稿，这些草稿向您展示了 WS-I 在开发第一个主要的可提交的文件 － WS-I 基本概要文件中所取得的进展。本文将介绍 WS-I 样本应用程序，让您先睹为快。
关于 WS-I
在 WS-I 基本概要文件版本 1.0 规范的第一个公开的工作组草稿（Chris Ferris 的优秀文章“初识 WS-I 基本概要 1.0”描述了这个草稿）和 WS-I 使用情形文档（这是我的上一篇文章“First look at the WS-I Usage Scenarios”的主题）被发布后不久，WS-I 样本应用程序使用案例和体系结构文档也被发布（如果您想获取更多信息和这些文档和文章的链接，请参阅
参考资料）。在该组织中，使用案例和体系结构草稿文档已经过了几个审阅周期，因此，它们的作者（即情形和样本应用程序工作组的成员）认为它们很稳定。但是，在审阅这些文档的过程中，根据 WS-I 组织的章程和规章的规定，还有可能对这些文档进行进一步的修订。
在写作本文的时候，Web 服务互操作性组织是一个由大约 160 个公司组成的联盟，这些公司代表了许多行业，包括汽车、消费品制造、金融、政府、保险、媒体、电信、旅游和（理所当然的）计算机行业。WS-I 致力于促进不同计算环境和编程语言之间的 Web 服务应用程序的互操作性。为此，它提供建议、最佳做法和其它旨在帮助 Web 服务应用程序的开发者的参考资料。更具体地说，WS-I 打算开发它所说的互操作的 Web 服务的
概要文件（profile）。那么，准确地说，概要文件是什么？WS-I 词汇表把它定义成：
概要文件：支持互操作性的一组要求。为了实现互操作的 Web 服务，WS-I 将提交一组支持技术要求和规范的概要文件。
第一个概要文件（目前仍在开发中）被称为
WS-Basic 概要文件 1.0。它的重点是 Web 服务所依赖的核心基础技术：HTTP、SOAP、WSDL、UDDI、XML 和 XML 模式。WS-Basic 概要文件 1.0 将在基础的连接性级别上提供互操作性。一旦完成后，WS-Basic 概要文件 1.0 将包括以下所有的东西：
-
概要文件规范：实际的概要文件规范包括某些版本级别上的非专有的、与 Web 服务相关的规范列表以及这些规范的说明和限制的列表。这些说明和限制旨在为开发互操作的 Web 服务提供便利。
-
使用情形：与 WS-Basic 概要文件 1.0 一起被提供的使用情形可被看作以符合概要文件的方式来使用 Web 服务的技术要求。这并不意味着以不同的方式使用 Web 服务就不符合概要文件。它只意味着遵守 WS-I 使用情形的指导是确保符合概要文件的一种方式。
-
样本应用程序：为了向 Web 服务开发者演示如何使用 WS-Basic 概要文件 1.0 来开发互操作的 Web 服务，WS-I 特许设立了创建样本应用程序的工作组。样本应用程序将描绘虚构的消费类电子产品零售商的供应链管理应用程序。
-
测试工具：除了以上所有的东西外，WS-I 还提供测试工具的参考实现，供开发者用来测试 Web 服务是否符合概要文件。有一个工具监视 Web 服务与它的客户机之间的所有交互，把它捕获的信息记录到文件中。另一个工具分析生成的日志文件以确定交换的消息和 Web 服务的其它助诊文件（它的 WSDL 和 UDDI 注册）是否符合概要文件中规定的指导意见。
样本应用程序概述
为了向 Web 服务开发者演示如何使用 WS-Basic 概要文件 1.0 来开发互操作的 Web 服务，WS-I 特许设立了创建样本应用程序的工作组。样本应用程序的一个主要目的是在一个应用程序中尽可能多地、合理地涵盖 WS-I 基本概要文件 1.0 规范（请参阅
参考资料）。这以许多方式显示了它自己，包括模式和 WSDL 中各种命名约定的使用和概要文件所允许的两种 SOAP 消息样式（即 RPC/lit 和 doc/lit）的使用等。换言之，虽然样本应用程序中设计和实现的 Web 服务是互操作的，但是它们未必代表设计和实现 Web 服务的最佳做法。
样本应用程序将描绘虚构的消费类电子产品零售商的供应链管理应用程序。消费者访问零售商提供的 Web 页面并定购产品。提供的产品包括来自以下每个制造商的电视、DVD 播放机和摄像机：
Brand1、
Brand2和
Brand3。零售商在三个仓库中保存库存。在处理来自客户的定单时，零售商试图一个接一个地从每个仓库中运送定购的产品。当仓库被要求运送客户定单中的产品时，它试图从它的现有库存中运送。每个仓库把它能完成客户定单的哪个部分（如果有）的报告返回给零售商。零售商汇总来自它的仓库的报告并把合成的结果返回给客户。同时，如果仓库能够供应定单的一部分而且如果这样做将导致仓库的某种产品的现有库存低于最小阈值级别，那么它通过从适当的制造商定购成品来再次补充它的库存。类似地，如果制造商对成品定单的处理导致它的现有库存低于最小阈值级别，那么它启动生产运行。
样本应用程序的开发过程
在详细介绍样本应用程序本身之前，我应该先介绍情形和样本应用程序工作组的成员使用的开发过程。两个小组完成样本应用程序的开发：使用案例和设计（Use Case and Design，UCD）小组和实现（和测试）小组。UCD 小组的第一步是以使用案例的形式找出需求。该小组选择把统一建模语言（Unified Modeling Language，UML）用于系统的建模，因为多数组员似乎知道并理解它。虽然找出需求很费时，但实际上相当简单。体系结构和设计相对要难一点。
当 UCD 小组解决了所有与使用案例相关的问题后，他们开始样本应用程序的体系结构和设计工作。该小组开始为整个供应链管理样本应用程序建立一个单一的全局对象模型。然而，该小组很快意识到这既不实际，也很不现实：在现实世界中，供应链由不同的公司组成，每个公司有自己的信息处理系统。所以，他们把样本应用程序分为三个不同的逻辑系统：零售商系统、制造系统和演示系统。［
注意：为满足未来的概要文件要求，第四个系统 － 零件供应商系统可以容易地扩展样本应用程序的体系结构。］
他们分别设计每个系统。在每个系统中，他们通常先找出跨系统的接口。这些接口就成了应用程序中的 Web 服务。然后为每个系统创建对象模型和序列图。对象模型的主要目的是在 UCD 小组和实现小组之间帮助建立一组共同的术语，而不是一定要准确地描述 Web 服务的实现的详细信息。工作组发现，在跨越系统和组织边界的应用程序中，与非常详细的对象模型相比，清楚定义和一致的 Web 服务接口对于应用程序的成功更关键。
在样本应用程序的开发过程中，工作组取得的另一个重要经验与序列图有关。起初，UCD 小组完成的序列图与对象图有关。然而，随着实现小组开始研究样本应用程序的体系结构和设计，他们认为如果序列图与 Web 服务有关（即 Web 服务的操作而不是对象的方法），那么序列图将更有用。还有，在跨越系统和组织边界的应用程序中，定义系统之间的操作顺序比系统内的更重要。
使用案例
在供应链管理样本应用程序的开发的需求收集阶段，小组找出以下使用案例：
- UC1：购买商品
- UC2：运送商品
- UC3：补充库存
- UC4：供应成品
- UC5：制造成品
- UC6：配置和运行演示
- UC7：记录事件
- UC8：查看事件
图 1用 UML 使用案例图描绘了这些使用案例。请注意，准确地说，这个图不是
纯粹的UML，因为 UML 常常被用来模拟一个系统，而样本应用程序实际上由三个系统组成。一般来说，参与者被显示在表示被模拟的系统的方框的外面。然而，在处理 Web 服务时，一个系统是另一个系统的参与者。在
图 1中，表示它的方法是把参与者画在参与另一个系统的系统中。
前三个使用案例（UC1：购买商品、UC2：运送商品和 UC3：补充库存）都与零售商系统有关。它们表示与以下关联的操作：在零售商的 Web 站点购买消费类电子产品、把购买的商品从一个或多个仓库中送到消费者手中和在必要时补充仓库的库存量。
中间两个使用案例（UC4：供应成品和 UC5：制造成品）与制造系统有关。它们表示某些消费类电子产品的制造商（这些制造商处理来自零售商（或者更准确地说，从它的一个仓库中）的购买定单），它们还表示当制造商的成品库存耗尽时必须启动的生产运行。
最后三个使用案例（UC6：配置和运行演示、UC7：记录事件和 UC8：查看事件）都与演示系统有关。它们表示样本应用程序演示的用户，该用户配置应用程序的 Web 服务的不同实现并运行演示以查看不同实现的互操作。在样本应用程序的执行过程中，事件被记录以使演示用户可以看到各种 Web 服务在幕后的交互。
零售商系统
供应链管理样本应用程序中的第一个系统是零售商系统，如
图 2所示。
图 2中的部署图显示零售商系统由以下三个 Web 服务组成：
- 零售商服务
- 仓库服务
- 仓库回调服务
零售商服务有两个操作：getCatalog 和 submitOrder。第一个操作 getCatalog 是 UC1 的一部分。它返回零售商销售的所有产品的列表。零售商的
商店前台Web 站点调用该操作，消费者可看到显示的结果。第二个操作 submitOrder 也是 UC1 的一部分。它取得有关客户和定购的产品的信息（这些信息是它的输入），并返回有关哪些定购的产品已被运送的状态信息。体系结构文档提供了零售商服务的高级描述，但是，感兴趣的读者可从 Retailer.wsdl 文件（及关联的包含文件 － 请参阅
参考资料）中了解详细信息。
仓库服务仅有一个操作 ShipGoods，ShipGoods 是 UC2 的一部分。它取得尚未运送的定购商品的列表和定购的客户的引用（列表和引用都是它的输入）。对于定单中的每个行项，如果仓库中的数量不少于定购数量，那么仓库运送商品并降低它的库存级别。如果新的库存级别低于最低阈值，那么仓库将向制造商定货以补充它的库存。零售商服务调用该操作，该操作返回带有状态（状态表示可以运送哪些行项）的列表。使用案例文档包括非功能性的要求，这个要求规定一个零售商拥有恰好三个仓库（被简称为 A、B 和 C）。所以，零售商服务一个接一个地调用每个仓库的 ShipGoods 操作，直到完成整个客户定单。您可以在 Warehouse.wsdl 文件中找到仓库服务的定义（请参阅
参考资料）。
仓库回调服务实际上被定义为制造系统的一部分，但它由零售商系统来实现。它有两个操作：SubmitSN 和 ErrorPO。这个服务实现了 UC3。制造系统调用仓库回调服务的 SubmitSN 操作，以表示制造商已成功完成了对购买定单的异步处理（购买定单来自仓库，用于补充仓库库存）。输入是送货单文档；输出的只是已接收到送货单的指示符。反之，如果制造商无法处理购买定单，那么它通过调用 ErrorPO 操作来表示这种情况并提供错误原因。这是 WS-I 使用情形文档中描述的基本回调情形的最后的请求／响应部分。仓库回调服务被定义在 Manufacturer.wsdl 文件中（请参阅
参考资料）。
图 3显示的是零售商系统的类图。它反映了以上讨论的概念并表示出概念之间的关系。
制造系统
供应链管理样本应用程序中的第二个系统被称为制造系统，如
图 4所示。
制造系统仅由一个 Web 服务组成：
制造商服务仅有一个操作：submitPO，submitPO 与 UC4 和 UC5 有关。submitPO 操作的目的是通过网络发送制成品的购买定单。在确定了库存级别低于某个最低级别的时候，仓库调用 submitPO 操作。操作的输入是购买定单文档，输出是表明购买定单已被接收到并已验证的响应。这是 WS-I 使用情形文档中描述的
基本回调情形的
初始请求／响应部分。制造商服务被定义在 Manufacturer.wsdl 文件中。
请注意，使用案例文档包括非功能性的要求，这个要求规定零售商只销售三类消费类电子产品（即电视、DVD 播放机和摄像机），三个不同的制造商（简称为 Brand1、Brand2 和 Brand3）均生产这三类产品。所以，零售商提供九种不同的产品：
- Brand1 电视
- Brand2 电视
- Brand3 电视
- Brand1 DVD 播放机
- Brand2 DVD 播放机
- Brand3 DVD 播放机
- Brand1 摄像机
- Brand2 摄像机
- Brand3 摄像机
图 5显示的是制造系统的类图，它显示了系统实现中的许多类之间的关系。
演示系统
供应链管理样本应用程序中的第三个（也是最后一个）系统是演示系统，它被描绘在
图 6中。演示系统实际上不是供应链管理应用程序的一部分；它包括使用供应链管理应用程序来有效地演示 Web 服务互操作性所需的基础结构。
演示系统由一对 Web 服务组成：
配置程序 Web 服务仅有一个操作：getConfigurationOptions，这个操作被用于 UC6 的实现。这个操作的目的是返回构成供应链管理应用程序的 Web 服务的所有注册的实现的列表。唯一的输入是用来表示要求进行 UDDI 查询（与之相对的是允许返回以前查询所获得的、保存在高速缓存中的值）的标志。这个操作由演示
配置Web 页面（位于零售商的 Web 页面的前面）来调用。您可以在 Configurator.wsdl 文件中找到这个 Web 服务的详细信息（请参阅
参考资料）。
记录工具 Web 服务包括两个操作：logEvent 和 getEvents，这些操作被分别用于 UC7 和 UC8 的实现。logEvent 操作的目的是记录信息，这些信息与由于执行供应链管理样本应用程序而发生的某些事件有关。样本应用程序中的每个 Web 服务调用这个操作。另一方面，getEvents 操作的目的是检索以前记录的事件。与样本应用程序的一次执行关联的所有事件被检索。在样本应用程序的执行中，演示用户请求查看幕后进行的操作后，这个操作被调用。记录工具 Web 服务被定义在 LoggingFacility.wsdl 文件中（请参阅
参考资料）。
演示系统的类图被显示在
图 7中。它显示了在系统的实现中可能需要的对象类型（以及它们的关系）。
概要文件的涵盖
前面已提到，样本应用程序的主要目的之一是尽可能多地涵盖 WS-Basic 概要文件 1.0。在许多情况下，这个目的与样本应用程序的另一个目的（最近我已在新闻界读到该目的）相矛盾；相矛盾的目的是成为开发互操作的 Web 服务的最佳做法的来源。说明它的最好方法是总结样本应用程序中 Web 服务的一些不同的方面，我已在
表 1中这样做了。
您可以看到，样本应用程序中至少有一个 Web 服务实现了 WS-I 定义的三个使用情形中的每一个情形。所有的 Web 服务使用同步请求／响应使用情形，制造商和仓库回调实现了基本回调使用情形，记录工具使用单向使用情形。
WS-Basic 概要文件 1.0 允许 Web 服务使用两种样式的 SOAP 消息：RPC/literal 和 Doc/literal。样本应用程序 Web 服务混用这两种样式。WS-Basic 概要文件 1.0 允许符合规范的 Web 服务把 SOAP 头用于特定于应用程序的目的。同样，样本应用程序的一部分 Web 服务使用了 SOAP 头，另一部分则没有使用。
数据类型是样本应用程序中必须权衡概要文件涵盖与某种真实的外表的一个地方：毕竟没有太多的真实的应用程序使用编程语言或运行时环境允许的每种数据类型。情形和样本应用程序工作组选择了它认为的一些最常用的数据类型。
同样，在 WSDL 和 XML 模式文件中，有的使用了 XML 属性，有的未使用，有的指定了 SOAP 操作，有的未指定，各种不同的命名约定都被使用。情形和样本应用程序工作组似乎受到不一致的困扰，但这是为了强调互操作性而有意这样做的。可论证特别是在 B2B（
business-to-business，商家到商家）环境中，不同组织之间的一致性是不太可能的。事实上，即便在一个组织中，保持一致性也可能是困难的。这恰恰是互操作性重要的原因。
外部视图
至此，您已在内部透视图中看到了 WS-I 样本应用程序。
图 8试图从外部视角来显示样本应用程序。
除了为样本应用程序提供要求（使用案例文档）、设计（体系结构文档）和源代码之外，情形和样本应用程序工作组的成员还计划把样本应用程序展示成活生生的互操作性演示。如
图 8所示，在使用该演示时，您先从公共的 WS-I.org Web 站点开始。在公共的 WS-I.org Web 站点上有另一个 Web 页面（这个页面描述了样本应用程序以及如何运行演示）的链接。这个 Web 页面还包括至少一个情形和样本应用程序工作组成员的 Web 站点（这个站点托管了互操作性演示和供应链管理样本应用程序的用户界面（user interface，UI））的链接。这个 Web 页面被称为
配置Web 页面，因为这是您配置互操作性演示的地方。互操作性演示的配置由选择样本应用程序中每个 Web 服务的实现组成：零售商、仓库 A、仓库 B、仓库 C、制造商 1、制造商 2、制造商 3 和记录工具。请注意，仓库
X实际上指一对 Web 服务：仓库和仓库回调。配置程序 Web 服务本身是不可配置的；相反，它被硬编码在 UI 中，这一点也需要引起注意。
配置完演示后，您接着访问下一个 Web 页面，这个页面被称为
ShoppingCart页面。在这里，您可以选择想购买的商品和每种商品的数量。当您作出最后的选择时，您把定单提交给零售商。零售商询问它的仓库，接着仓库可能（异步地）把它自己的定单提交给一个或多个制造商。当您的（消费者的）定单的处理完成时，您将看到
OrderStatusWeb 页面，这个页面将告诉您零售商是否不能满足您的定单的某些部分。这时，您很有可能访问
TrackOrderWeb 页面，系统在这个页面上显示在处理定单期间发生的事件的日志。这没有太多的定单跟踪，因为它在查看构成样本应用程序的 Web 服务之间的交互。
总结
Web 服务互操作性组织的主要目标是确保 Web 服务可以无缝地互操作，无论编写它们所用的语言和它们的部署平台是什么。为了实现这一目标，WS-I 正在开发互操作的 Web 服务的概要文件，第一个概要文件是 WS-Basic 概要文件 1.0。概要文件规范旨在定义应该做什么（应该不做什么）以确保 Web 服务的互操作性，而样本应用程序旨在提供符合 WS-Basic 概要文件规范并由此容易地实现了互操作性的 Web 服务的示例。除了样本应用程序外，WS-I 还将提供测试工具（这些工具可用来测试您自己的 Web 服务是否符合 WS-Basic 概要文件规范）的参考实现。这将是今后的文章主题。
参考资料
关于作者  | | | 目前，Rimas 是 IBM 的新兴电子商务行业标准体系结构小组的架构师，他是 IBM 派到 WS-I 中的情形和样本应用程序工作组的代表。在开始目前的工作之前，Rimas 曾多年与 IBM 的客户一起工作以帮助他们实现他们企业中的分布式计算技术。您可以通过
rimas@us.ibm.com与 Rimas 联系。
|
对本文的评价
| 
