级别： 初级 Tony Hong (thong@xmethods.net), 创始人, XMethods
2001 年 6 月 01 日 在过去这半年中，在不同平台的多种 SOAP 协议实现之间的互操作性问题上已经取得了重大的进展。在这篇文章中，Tony Hong 考察了一些 SOAP 工具包实现者所面临的互操作性方面的早期更改，以及开发人员社区为解决这些问题所采取的各个步骤。
（请加入关于本文的
讨论论坛。）
过去，软件系统之间的通信，尤其是两个或两个以上不同体系结构之间的通信，通常是由各种特殊方法和专利协议随便地拼凑在一起。这种集成软件的方法通常难度大、成本高、并且费时间，尤其是当体系结构必须支持的连接数量增加时更是如此。
Web 服务运作的一个关键目标一直是：开发一系列被普遍支持的协议，它们在比以往更大的规模上实现“一把抓”的系统对系统通信。SOAP 就是这样一种协议，它为系统对系统通信定义了一个基于 XML 的编码和封装的标准。
自从首次介绍这种规范以来，至今已经出现了 50 多个 SOAP 工具包，而且其数量还在继续增长。工具包的数量和多样性突出表现了计算机界是多么迅速地接受了 SOAP。然而，只有确保实现工具包之间的互操作性，才能体现出 SOAP 的全部价值。
本文中，我将着眼于工具包实现者在 SOAP 互操作性前沿曾面对的一些难题，以及他们怎样齐心协力克服其中的一些难题。我还会考查一个案例研究，它清楚地说明了经过改进的互操作性环境。
互操作性难题
应用程序使用 SOAP 工具包（通常以库的形式来使用）来制定基于 XML 的 SOAP 信封，通过 HTTP 或 SMTP 这样的传输协议发送这些信封，并且对进入的 SOAP 信封进行处理。如果两个 SOAP 工具包对如何建立和解释信封作出了不同的设想，就可能产生互操作性问题。
例如：
- 一或两个 SOAP 工具包实现的可能仅仅是全部 SOAP 或 XML 规范的一部分。某些情况下，一个系统发送了其它系统无法处理的 SOAP 文档，这就会在支持的功能上发生不匹配。
- SOAP 规范使某些东西可选 ― 比如，SOAP 规范使您能够选择为已编码的参数传送类型信息。如果一个实现假定类型信息存在于它所接收到的消息中，它就可能无法和另一个选择不传送该信息的实现进行互操作。
- 对于规范语言表达不明确的部分，两个实现者可能会给出不同的解释。
最终，实现者可能很容易地在他们的工具包中犯下了一些单机测试中显示不出来的错误。这样的错误可能会导致当两个不同的工具包试图挂接到一起时所产生的互操作性问题。
解决方案：通信和测试
为了帮助解决上述问题并且从总体上提高 SOAP 互操作性，创建了 SOAPBuilders 在线组。该组织的成员各式各样，有的来自象 IBM、Microsoft 这样的大公司，也有的是有自己的开放源代码工具包的个人。为增进交流并提供跨工具包测试的机会，SOAPBuilders 在线组为工具包实现者社区提供了下列工具：
- 一个邮件列表，作为讨论实现和互操作性问题的论坛。
- 一个互操作性测试套件规范
- 一个测试服务器端点目录
- 连接测试结果的链接
为了支持互操作性测试的上述需要，成立了 SOAPBuilders 互操作性实验室（Interoperability Lab，ILAB）。您可以从
参考资料部分的链接中找到关于 ILAB 的更多内容。
SOAPBuilders 测试套件
清单中活动的核心是一套 SOAPBuilders 互操作性测试套件。它是一个简单的“回送”SOAP 远程过程调用（RPC）请求的集合，在 RPC 中客户机发送一个某种类型（例如整型、字符串型等）的参数，服务器简单地返回一个同样类型的等值的参数。然后客户检查该返回值，确定是否与发送的值相匹配。
图 1 说明了这样一个
echoString 测试的整个往返过程：
图 1：图解 SOAPBuilders echoString() 测试
通过执行此往返过程，该测试运用了：
- 服务器对客户端 SOAP 信封进行语法分析的能力。
- 服务器对信封中包含的已编码参数进行无序化处理的能力。
- 客户机对服务器响应所发送的 SOAP 信封进行语法分析的能力。
- 客户机对服务器发送回来的已编码参数进行无序化处理的能力。
目前，回送方法是为下列数据类型定义的：
- string
- integer
- float
- struct
- dateTime
- base64Binary
- string 数组
- integer 数组
- float 数组
- struct 数组
当一个客户机与服务器一起执行这种测试时，会记录每次测试的状态：“通过”或者“失败”。许多实现者已经公布了他们的客户机结果（请参阅
参考资料）。
表 1显示了用工具包“X”建立的客户机与各种服务器之间的一系列样本测试结果。
表 1：样本客户机测试结果矩阵
|
工具包 X 客户机
| |
echoString
|
echoInteger
|
echoFloat
|
echoStruct
|
echoBase64
| |
工具包 A 服务器
| 通过 | 通过 | 通过 | 失败 | 失败 | |
工具包 B 服务器
| 通过 | 通过 | 通过 | 通过 | 通过 | |
工具包 C 服务器
| 通过 | 通过 | 失败 | 失败 | 通过 |
一旦一对客户机―服务器在一个（或者全部）测试中进行交互操作失败，这一问题通常会在列表中公布出来，这样实现者社区就有机会立即探讨失败的原因以及应该怎样纠正错误。
一个样本互操作性问题列表
下面列出了一些在测试中遇到的和论坛中讨论的问题示例。这里没有详尽列出所有的问题，而是提供了一个过去曾经出现过的问题类型样本。
- 当绑定到 HTTP 时，SOAP 强制使用被称为“SOAPAction”的 HTTP 报头。与 SOAP 规范相反，一些工具包不引用 SOAPAction HTTP 报头值，这就会使那些假定所有的 SOAPAction 值都将被引用的工具包出现问题。
- SOAP 规范允许但不需要参数的明确“on-the-wire”分类信息。“on-the-wire”分类信息是直接包括在 SOAP 消息信封中的类型信息。一些工具包对指令进行无序化处理要依靠“on-the-wire”分类信息，而其它工具包则不发送“on-the-wire”类型信息。
- SOAP 规范不强制使用 XSD 模式的特定版本，考虑到在 SOAP 规范创建时，XML 模式的标准还没有固定下来，这一点可以理解。工具包有时不能对使用不同版本的 XML 模式的其它工具包发送过来的已编码参数进行无序化处理（例如使用 2001 版 XML 模式的工具包就不能对使用 1999 版 XML 模式的工具包发送过来的已编码参数进行无序化处理）。
- 有些工具包不能对其它工具包发送过来的 Unicode 字节顺序标志进行语法分析。
- 有些工具包不能处理对 XML ID/HREF 引用机制的使用（位于接收中的 SOAP 信封内部）。
关于这些问题及其解决方案的更详细信息，请参阅 SOAPBuilders 消息档案文件（请参见
参考资料）。
案例研究：SOAP 互操作性示范
实现者社区的共同努力已经在非常短的时间内取得了一定的、切实的成效，发现和修正了一些错误，澄清了一些对规范的解释。因此，许多工具包都已经通过补丁程序进行了修改，并修正了一些错误，来提高互操作性。
为了举例说明改进后的互操作性的状况，微软和 IBM 在 2001 年 5 月举办的 Networld+Interop 展示会上共同发起了一个 SOAP 互操作性活动，该展示会有若干厂商和个人参加，展示了 SOAPBuilder 组的许多工作成果。在这一展示会上，利用多种平台上基于 SOAP 的客户机和服务器，示范了一种简单的商业对商业模型，请参见
图 2。
图 2：SOAP 互操作事件案例
- 卖方向注册方登记自己的出席状况。
- 买方从注册方那里获取所有登记过的卖方列表。
- 买方向卖方发出一个项目的报价请求。
- 卖方响应，向买方报价。
- 在买方和若干其他卖方之间重复第 3 和第 4 个步骤。
- 买方向选出的卖方发送该项目的购买定单。
在定义了商业案例之后，SOAPBuilder 组又定义了支持该案例的程序接口。接着，每个参与者或者作为启用 SOAP 的服务端点实现此接口（在卖方和注册方实现的情况下）、或者作为可以利用这些端点的客户实现此接口（在买方实现的情况下），一个由买方、卖方和注册方组成的活动网络就此诞生。
由于 SOAPBuilders 组已经完成了交叉实现互操作性的工作，十多个基于许多不同平台和语言（Java、COM、.NET、Perl 等）的工具包能够相对容易地实现集成。
后续步骤
当前形式的 SOAPBuilders 互操作性测试套件只是个开始，它还将继续发展完善。测试过程的今后发展将极有可能包括以下几个方面：
- 被测试的数据类型将会更加广泛（主要包括目前 W3C 推荐的 XML 模式规范定义的一整套基本类型）。
- 更多关于 SOAP 的有趣的变化会集成到测试中去。
- 将对工具包严格遵守标准 WSDL 服务描述的能力进行测试。
- 集成更多的一般文档风格的 SOAP，而当前是把重点放在“section 5”方法调用／参数编码上。
- 测试过程和进程的附加自动化操作随着测试参与者数目的增长而不断增加。
结论
SOAP 互操作性的状况已经大大改观，这要归功于实现者之间交流的改善和工具包之间测试的使用。随着新实现的出现和其它现有实现的改进，SOAP 互操作性测试将是一个持续性的过程，它将成为 Web 服务互操作性测试的早期示例。仍然有许多工作需要去完成，而现在实现者社区已经为 SOAP 互操作性的持续发展和改进奠定了坚实的基础。
参考资料
关于作者  | | | Tony Hong 是一个 SOAP Web 服务的在线清单 ―
XMethods的创始人。在创建 XMethods 之前，Tony 是 Ventro Corp 负责 EAI 和 B2B 集成的工程技术主管，还是一名 Ariba 的专业服务组的技术顾问。他在 Accenture（以前是 Andersen Consulting）开始从事 IT 方面的工作。可以通过
thong@xmethods.net和他联系。
|
对本文的评价
| 
