互用性(Interoperability)问题说起来容易但通常实现起来却比较困难。尽管Web service曾承诺要提供最佳的解决方案来衔接基于.NET和
J2ee的应用程序，但其过程却并不简单。我们发现在使用SOAPBuilders和Web Services Interoperability Demo (WSID) 时还需要考虑许多问题。近期发布的Web Services Interoperability Organization (WS-I)对此也提供了很多有价值的深层见解。
本文包括了从这个demo的开发过程、参与SOAPBuilders互用性测试，以及WS-I于近期发布的有关互用性的规范中获得的经验总结(想了解更多关于WS-I的资料，可以查阅工具条中的“谈谈WS-I”)。以下，我们就开始研究在哪些范围可以通过使用Web services来实现互用性以减少你目前以及未来在.NET和
J2ee上的投资。我们提供的结论将有助于你决定是否应该同时对这两种平台进行投资，以及基于Web service互用性的局限性是否会使你只选择其中的一个平台。
互用性问题出现于计算机行业发展的早期阶段。当时
软件的开发是为了适应某一特定的硬件应运而生的，近期则是为了适应采用特定硬件配置的特定操作系统。然而，操作系统是会经常更换的，而且经常会采用新的硬件或对硬件进行升级。因此，尽管计算机应用程序使用了基于操作系统的编译或解释语言，但仍然受到操作系统改变的冲击。这的确是事实，尽管有一些高级语言(有时被称为第三或第四代语言，比如Visual Basic、C#和Java)的幕后想法是使程序员在一种更高级别的抽象层中来开发程序。
在计算机应用的早期阶段，人们没有太多地考虑接口连接或
整合程序的问题。这种状况一直持续到计算机体现出了重要的商业用途 -- 使部分或所有商业操作实现自动化，一些有关投资保护(investment protection)、
整合以及互用性等实际问题才随之产生。商业要求无论投资何种
软件，他们都可以持续使用这些程序，而不管硬件、操作系统和开发技术是否发生变化。这就使得
软件在完全不同的硬件和操作系统之间的兼容性成为企业最大的、花费最高的问题，因为它直接影响到生产力(productivity)、停工期(downtime )、机会的把握和其他一些失效方面的问题。
.NET和
J2ee的互用性问题之所以非常重要，是因为大多数企业都在使用其中之一或同时使用这两种平台来开发程序。.NET和
J2ee分别代表了解决本质上相同的问题的不同方法:开发、部署和管理定制商业程序。定制商业程序的重要性在于商务本身有着不同的运作，如果不能使其具有独特之处则会影响管理存货(inventory)、处理定单或提供财政服务(financial services )这些问题。实际上，企业之间的相互竞争经常是很激烈的;比如，Wal-Mart曾吹捧自己著名的进销存系统(inventory management system)，说它可以近实时地巩固来自于其所有店铺的购买力，而且能够使用这些信息从供应商处得到较低进价。
了解.NET和J2ee的区别 在一个完美世界里，用于自定义应用程序的主要开发平台之间是完全兼容的，为某一平台编写的程序能够完全适用于其他平台。然而，我们离完美的世界还差得很远。目前的
软件行业还相当不成熟，甚至可以说还没有完全标准化。
和电子行业及其他行业不同，计算机行业一直在为建立一套标准而努力。就在不久以前，DVD Forum成功地发布了一套用于DVD-ROM
软件和硬件的标准。所有DVD播放器均可播放任何DVD碟，所有DVD硬件制造商以及DVD碟制造商都将依照相同的编码标准。而在
软件行业中，各主要开发商均实行各自不兼容的
软件系统。他们鼓吹各自的产品对开发人员如何有用，以此期望开发人员使用他们的产品来开发项目，因为一旦程序开发进入生产(production)阶段，一般就不会更换使用其他产品了。
软件开发商们不是要建立一种所有人共同参与的市场，而是为了在这个复杂的开发市场中占有一席之地。
Microsoft.NET的最初想法是希望进行接近操作系统平台的定制开发，当然，这是指使用Windows(目前是 XP、ME和2000)。Visual Basic和C#是.NET平台上最重要的开发语言，并且它们不能在其他平台上运作。而基于Java的J#和.NET平台也是互不兼容的。Microsoft声称有许多开发商在开发与.NET common language runtime (CLR)相合作的语言，但直到今天，我们看到CLR还只是一个Windows“版”的技术。这就说明存在一个重要的互用性问题，因为每种编程语言(根据定义来划分)都有其各自特定的数据类型和数据结构。
仅凭一个简单的HTTP连接是无法实现互用性的，因为程序是在操作系统之上的编程语言抽象层中进行开发的。.NET和
J2ee平台上的开发编程语言有着本质上的区别(.NET比较私有化而
J2ee则更开放)。另一个重要的区别是对.NET来说，开发环境和操作系统是由同一开发商所提供的。.NET和
J2ee针对分布式应用程序有着不同的、不相兼容的二进制通讯协议(binary communication protocols):它们分别是.NET remoting和Remote Method Invocation/Internet Inter-Orb Protocol (IIOP)。
当然和VB、C#、甚至J#相比，Java有着不同的数据类型和数据结构。通常解决互用性的首要问题就是处理数据类型和结构的不兼容型，这也是在测试Web services互用性过程中的一个重要挑战。
尽管Java运行于Windows平台，但
J2ee应用程序却能够在任何平台上进行开发，并以通常被称为“松散耦合”(loosely coupled)的方式和任何操作系统相连。换言之，
J2ee尽量避免了使用操作系统特有的(operating-system-specific)特性和功能，比如直接内存管理(direct memory management);或是平台特有的(platform-specific)通信机制，比如Microsoft Remote Procedure Call (RPC)。
.NET开发环境能够充分利用操作系统的“紧密耦合”(tightly coupled)或“本地”(native)实现的优势，并能随意使用Microsoft特定的功能和操作系统服务。总体来说.NET更容易使用，它比
J2ee更好地结合了Windows本身的特性;但
J2ee程序的优势在于可以运行于其他操作系统之中。
在编程语言行为(programming language behavior)、本地分布式计算协议、数据类型和结构，以及从操作系统服务中分离(isolation)等方面的不同都会对互用性产生影响。除非所有人都使用相同的编程语言、操作系统和应用程序，否则你还是需要了解各种复杂的互用性问题，以及哪种方案更值得去研究。
权衡Web Services解决方案 用来解决互用性问题的Web services规范已经出台了，其中包括解决.NET和
J2ee的互用性方案以及Simple Object Access Protocol (SOAP)、Web Services Description Language (WSDL)、Universal Description、Discovery和Integration (UDDI)等协议。了解它们真正能解决什么问题以及如何通过使用它们来解决问题是相当重要的。
SOAP规范定义了从HTTP到TCP/IP数据传送的消息格式，WSDL规范定义了如何描述一个Web service，而UDDI则定义了如何注册(register)和发现(discover)Web service描述。SOAP和WSDL是位于World Wide Web Consortium (W3C)底层的标准。W3C还负责定制HTML和
xml领域的各种规范。
另外，W3C还为Web Services Architecture Working Group提供赞助，该组织负责开发一个用于包含基本规范的Web service参考架构(reference architecture)。Web service规范和实现它们的底层平台是完全独立开的，这和HTTP与HTML之间的情况相似，同时它们能在.NET和
J2ee平台上运行的很好。
Web Services Architecture Working Group还制定了一些扩展规范(extended specification)，比如在安全性、协调(orchestration)和事务处理方面的规范。用来实现这些规范的产品并不是很多，因此在这里我就不详细地介绍了，除非说到一些更为复杂的互用性问题，因为你必须了解Web service交互的每个部分是否支持其他规范，以及它们支持哪些规范。但从到目前为止的经验来看，即使是最基本的Web service规范也试图向互用性挑战，这是因为Web service技术存在于一个高级的抽象层中，它包括两种主要的交互方式(interaction style)，每种都有其各自考虑的范围。
访问机制 一般来说，开发人员会使用两种机制来访问一个远程程序(就是从位于一个不同地址空间(address space)的程序中调用另一个应用程序):RPC，它主要包括定义和使用外部程序调用接口;以及文件或队列(queue)操作，其中程序通过对文件或队列的读写来实现数据共享。
SOAP是被指定且考虑了这两种途径而编写的(协议)。在Web service领域里，它们被称为面向RPC(RPC-oriented) 和面向文档(document-oriented)的交互方式。面向RPC方法在同步通信功能中比较常见，比如用在CORBA、COM，以及用在.NET和
J2ee的二进制通信协议里。使用RPC的一个好处是请求者(requestor)能看到接口定义(interface definition )中有关service的定义;就是说，程序或方法名以及调用参数可以用来提供有关service行为的信息。使用基于工具包的 RPC方法的另一个好处是用于实现RPC方式的编程接口会自动实现真实的数据类型与
xml结构之间的转换。这样会使程序员从数据转换中解脱出来。使用面向文档(或称为消息传输)方式的优势在于请求者和提供者只需在数据(或schema)定义上取得一致就可以了，而对程序或方法调用的具体细节不作要求。然而，面向文档方式仅限于使用
xml文档发送和接收数据。由于现在基于
xml文档的使用越来越广泛，所以这也不是什么问题，尽管早期的使用者更愿意将非
xml信息转换到合适的
xml结构中，以此提高文件交互方式。最终，使用基于RPC还是基于文档方式将由各自service的调用方法(你是否需要在一个普通文档上用详细的参数或相对较少的调用操作来完成大量特定的方法调用呢?)和被传输的数据类型(你需要转换的数据是简单的还是复杂的数据类型?)来决定。
大量的互用性工作是由 SOAPBuilders通过面向RPC的交互
