在过去这半年中，在不同平台的多种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：样本客户机测试结果矩阵

　　一旦一对客户机―服务器在一个（或者全部）测试中进行交互操作失败，这一问题通常会在列表中公布出来，这样实现者社区就有机会立即探讨失败的原因以及应该怎样纠正错误。

　　一个样本互操作性问题列表

　　下面列出了一些在测试中遇到的和论坛中讨论的问题示例。这里没有详尽列出所有的问题，而是提供了一个过去曾经出现过的问题类型样本。

　　·当绑定到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和他联系。