引言
Web 服务希望并且承诺将分散的应用程序以一种无缝的方式进行集成。但企业应用程序是在不同的平台上采用不同的技术构建的，因此，跨业务的集成并不是一件轻而易举的事。最近出现的基于 Web 服务的业务流程执行语言（BPEL）为定义 Web 服务的行为提供了一个高层描述语言。它提供一个标准和可移植的语言来将多个 Web 服务融合到一个商业流程中。由于 BPEL 受到一些主要厂商的欢迎，一些用来自动设计商业流程的集成开发工具，如 IBM WebSphere Studio Application Developer Integration Edition (Application Developer) 已经进入市场。这些工具减少了 Web 服务集成时需要的大量编码工作，并允许您通过拖拽 WSDL 文件到工具中的方式构建商业流程。我们期望这些工具能够自动产生调用 Web 服务的客户端的存根。因此，集成的成功目前很大程度上一来于底层复杂的工具支撑。这就更加要求开发成员采用最佳实践来确保共享 Web 服务的内在互操作性。
正如我在本文以及随后的文章中所讲的，以下几个问题需要特别关注：
利用厂商工具根据实现代码得到 WSDL 中的 Web 服务语言非常方便。但是这种方式忽略了消息脚本的设计，但这一点正是异构的环境（如 J2EE 技术对.NET）中 Web 服务互操作的关键。
流行的 RPC/encoded 方式以其简单、灵活且熟悉的特点对开发人员是个有吸引力地选择。然而，在厂商之间对抽象 SOAP 编码数据模型的同步实现带来的困难成为 Web 服务互操作的一个困难性的挑战。
弱类型的集合对象、包含空元素的数组和特定的本地数据类型都给互操作性带来一定的问题，特别是：
对于厂商提供的工具来讲，准确地解释代表弱类型集合对象的 XML 脚本并将它们映射到本地数据类型是不可能的。
带有空元素的数组的 XML 表示在 .NET 和 Websphere 之间是不同的。
由于本地数据类型和 XSD 数据类型并不具有一一对应关系，在转换过程中，信息或精度将会丢失。
由于使用相对 URI 引用，Java 技术和 .NET之间不同命名转换将会导致命名空间冲突。
从 WSDL 开始
所有 Web 服务的互操作问题都可以归结到 WSDL 文件上。WSDL 是 Web 服务的接口定义语言（IDL）和服务器与客户间的协议。服务语法，即 WSDL 文件中的消息类型、数据类型和交互方式，是构建松耦合的系统的关键。尽管 WSDL 并不要求使用特定的类型系统， XML 脚本数据类型（XSD）在 Web 服务领域内广受欢迎。
XSD 提供了大量的内置的基本类型并允许服务提供者进一步定义定制的复杂类型。XSD 的类型系统比任何编程语言的类型系统都更加复杂和强大，并且更重要的是，它是独立于编程语言的，因此，它成为 WSDL 定义 Web 服务语法的逻辑起点。
理论上讲，就像 COM 和 CORBA 的 IDL，您应该首先创建并编辑 WSDL --在您基于 WSDL中的服务语法来构建 Web 服务和特定实现语言的客户程序之前，定义接口、消息和数据类型。
然而，事实上，即使经验丰富的都不会那么做。他们最初开始实现特定于语言的接口，如 Java 接口，然后依赖厂商的工具从它们的实现代码中获取 WSDL 服务语法；再把这些 WSDL 服务语法交给 Web 服务客户程序以便根据 WSDL 找出如何来调用 Web 服务。最后，在他们经常不需要知道 WSDL 之前， 他们就能够创建并运行复杂的 Web 服务。他们可能在异构的环境中运行他们的客户和服务器程序，即或者 J2EE 平台，或者 .NET 平台，或者二者都有。
目前厂商的集成开发工具下面的方向发展，即所有的东西，包括 WSDL都可以自动生成，不需要写任何代码（或者，至少许多厂商都声称并希望如此）。这一趋势很有吸引力，因为它开发效率很高，且相对于人工编码它很少出错（当然在工具功能合适且可靠的条件下）。在单一的平台上，互操作性一般不成问题，只要 Web 服务和客户都使用同样的开发工具。
当对跨越异构的环境产生互操作性要求时，问题变得比较明显。现在，您从实现语言来创建 Web 服务交互的关键构件，然后利用平台独立的工具将它们映射到 WSDL 中语言独立的元素。当客户平台上的工具根据 工具生成的 WSDL 来产生服务代理时，将进行另外一个映射。这一流程基于下面的事实，WSDL 是 Web 服务的接口定义语言。语言独立的 WSDL 应该成为客户和服务器的共同基础。以这种方式使用开发工具将双倍增加映射过程中信息丢失的可能。
这并不意味着您应该放弃这些工具，所有的厂商应该停止生产并在市场上销售这些工具。在当前的企业应用程序开发领域自动化已经成为一个重要的因素。工具本身很强大，关键在您怎么利用它们的力量？您可以利用这些工具产生一个框架 WSDL 来作为起点或者模板。脚本、消息部件和数据绑定必须仔细设计来遵循 WS-I 一致性要求。就像您出于数据库效率的考虑而不希望由工具产生数据库脚本一样，您不应该忽视手工设计高效 Web 服务消息和数据类型。有时，即使元素的名字也要仔细设计来遵循潜在的异构平台间的命名转换。对于 Web 服务互操作性来讲， WSDL 是唯一比较重要的构件。程序员必须学会基于原始 XML 消息进行编程，至少学会读取 XSD、 WSDL 和 SOAP 消息。