[摘要]互用性（Interoperability）问题说起来容易但通常实现起来却比较困难。尽管Web service曾承诺要提供最佳的解决方案来衔接基于.NET和J2EE的应用程序，但其过程却并不简单。我们发现在使用SOAPBuilders和Web Services Interoperability De...
互用性（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“版”的技术。这就说明存在一个重要的互用性问题，因为每种编程语言（根据定义来划分）都有其各自特定的数据类型和数据结构。
图1. 比较.NET和J2EE
仅凭一个简单的HTTP连接是无法实现互用性的，因为程序是在操作系统之上的编程语言抽象层中进行开发的（见图1）。.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)等协议。了解它们真正能解决什么问题以及如何通过使用它们来解决问题是相当重要的（见图2）。
图2. 回顾基本的Web Services架构
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）。如图2中可以看到架构规范的工作草案图表中所显示的SOAP、WSDL和UDDI的关系。Web service规范和实现它们的底层平台是完全独立开的，这和HTTP与HTML之间的情况相似，同时它们能在.NET和J2EE平台上运行的很好。想了解更多关于.NET和J2EE对Web service规范的支持差异的比较，请查阅Eric的文章“Decide Between J2EE and .NET Web Services”。
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的交互方式在WSID中完成的 -- 主要是通过“调试”或在多个SOAP产品实现中找到所支持数据类型和架构的共同点（common denominator）。其结果定义了一组可以用来实现互用性的数据类型和结构。因此该列表成为你检查正在使用的.NET和J2EE Web service产品的首要事情。在本文的后面部分我会教你怎么做。
较低层次的互用性工作是用面向文档的交互方式来完成的。然而，WS-I曾声称很难用面向RPC方式来实现广泛的互用性，并且呼吁企业使用面向文档方式来获得更好的结果。面向文档方式实现了“文件共享”模式。传输SOAP消息就如同通过一个消息代理（message broker）-- 如Microsoft Message Queue (MSMQ) 或MQ Series的Java Messaging Services（JMS）来传送异步消息（asynchronous message），其差别仅仅在于传输是在TCP/IP 上使用HTTP ，同时消息格式是由WSDL定义的。实际上，面向文档方式尽量避免在Web service层中解决数据类型和结构问题，但开发此类程序还需要做更多工作。我们将在本文的后面部分谈到这个问题。
使用面向连接（Connection-Oriented）的协议
面向RPC和面向文档交互之间的关系相当于同步和异步通信协议之间的关系。同步通信通过阻塞（block）调用程序直到被调用的程序返回一个响应来模拟一个子程序。如果被调用的程序没有完成则调用程序会收到错误消息，不管被调用的程序是在远程网络上还是在本地机器中运行。但实现这种模式的一个必要条件是调用程序和被调用程序之间必须保持一种连接或会话（conversation）。这种持续连接会消耗大量的网络资源，这也是HTTP不支持它的原因。
这就意味着你在使用.NET和J2EE对象模式时会有很多限制条件。比如，你无法在HTTP上使用依赖于同一对话的多个交互操作的SOAP，而且你无法执行对象生命周期管理（object lifecycle management ）功能，比如建构（create）、析构（destroy）和碎片整理（garbage collection）。
但通过异步调用，你可以通过一个程序写入文件，随后用另一个程序来从文件中读出数据。你只需要在读写文件的过程中有一个网络连接。这些程序可以在同一机器或不同机器的相同或不同地址空间中运行，只要由“调用”（或生成）程序写入的数据能够被“被调用”（或使用）程序所接受就可以了。然而，在异步调用的情况下，调用程序在没收到返回数据时无法了解到底发生了什么；而定制标准的错误处理和结果分析（resolution）又成为另外的互用性问题。
当你无法决定Web service是不是正确的选择时可以用它来衡量，了解你是否需要使用同步协议是非常重要的。从定义来说，基于HTTP 的Web service 是一种单向（one-way）异步消息，因此，它是解决基于文件或基于队列的互用性问题的最好方法。比如，如果互用性需要包含用数据更新来同步用户响应，那么Web service可能就不是个好办法了。然而尽管它有明显的缺陷，却还是能够实现互用性的。
图3. 建立联系
深入了解WSID
WSID是由Tony Hong (XMethods.net的创始人和主席)、SIGS/101会议和Web services技术的主要公司，包括Microsoft、IBM、IONA、eXcelon（现在是一个Progress Software）、Mind Electric、AmberPoint和WebMethods共同发起的，用来研究多开发商共同实现Web service兼容性的问题。其目标是通过使用一个简单却不平凡的、切实的商业背景（business scenario）来实现一个多开发商共同开发的、跨平台的Web service互用性范例。目前大多数demo实现是基于J2EE的产品，但由于Microsoft也是这个demo的发起者之一，所以.NET也被包括在内。
WSID已经在2002年8月在Boston 的Web Services One 大会上公布了，尽管其在线版（online version）的计划还在酝酿之中（见资源）。该范例使用了一个简单的购买网络（purchasing network）。供应商为用户提供目录，而用户则给供应商提交一份购买清单。供应商会首先检查用户当前的信用情况，然后向代理商店发出送货单（见图3）。出于几个原因，XMethod通过提供静态的XML文件和Web service接口实现其在demo网络的重要作用：
一个带Web service和浏览器接口的、包含所有参与者及其相关终端的列表。
从Customer到bank的映射关系。
保持WSDL文件和列出终端用户的UDDI记录。
包含所有已定义接口的标准WSDL文件的在线集合。
一个日志服务（logging service）。
这些接口都被包含在一个单独的文档中，你可以从XMethods Web site中找到它们（见资源）。这个很棒的Demo中包括用于内部组件通信（inter-component communication）必须的RPC-encoded结合和document-literal结合实例。以及跨越所有平台的大量的参与调节这些方式和编码结合。Demo内部操作成功与否主要取决于操作精度和WSDL Web service操作定义的相对简单。而且，所有demo的行为都通过一个logging Web service来完成，这个service最初是由Xmethods网站提供的。
当一部分人开始对WSID进行组装的时候，另一个由大约15个Web services供应商组成的非正式组织将共同执行一套普通测试版，通过使用SOAPBuilders来提高互用性水平。所有开发商均发布测试版终端以证明其实现互用性的水平。其他供应商则可以测试其自身实现，使用已发布的测试终端，然后和其他供应商一起完成对互用性水平的测定（见资源）。
SOAPBuilder是通过和其他成员一起讨论来完成评估的，期间完成定制和校正的工作并得到一个新的测试版。每次讨论的目的是通过一些重要的方法来提高互用性水平，比如在测试版中包括更多数据类型和结构，或者在WSDL规范中包含更多内容。该组织集中使用通过测试大量开发商对SOAP规范中RPC编码的阐述，用面向RPC的交互方式来解决互用性问题。截至发稿日期，SOAPBuilder已经完成了五次讨论并得到大量的讨论结果，结论证明用简单数据类型（如整数型和文本型）比复杂数据类型（如数组和结构型）更容易实现互用性。使用的数据类型越复杂，通过所有测试的开发商数量就越少。大多数开发商使用的是J2EE平台，因此很容易找到J2EE供应商并找到每个供应商能够在互用性测试中支持哪种数据类型及多少数据类型。你可以查看SOAPBuilder的结果以了解哪种数据类型和结构在面向RPC 方式中是可用的。
由于该组织是非正式的，因此SOAPBuilders的章程还在商议之中。一些人认为既然WS-I已经发布了其最初的建议书（见资源），因此目前并不需要SOAPBuilders。然而，许多开发商还是坚持支持基于RPC方式的Web services产品，而且使用RPC会简化面向RPC中间件的互用性实现，比如.NET、J2EE和CORBA。在许多情况下SOAPBuilder和WS-I是交替使用的，因为它们的目标都是建立一个实现互用性的通用Web service规范。
依照Web Service发展蓝图
当Web service的应用变得成熟并成为主流产品的时候，就需要在现有的Web service标准中增加一些其他功能，为了实现这些需求，WS-I计划发布一个结构蓝图（architectural road map），用于识别功能区和需要在将来的Web service规范中关注的功能。由于很多标准组织不断建立和采用新的规范来增强现有的Web service功能，WS-I将继续推出一个确保测试资料支持现有要求和内部独立性的论坛 。
我们要强调的是WS-I提出的两个用于工具和基本应用程序的主要开发平台：C# (.NET)和Java (J2EE)。这就是说WS-I将来的工作很可能直接同.NET和J2EE的互用性相关，这将具有很重要的意义，因为WS-I建议中的工具和策略将肯定（至少）能够正确运行于这两个大的开发平台之上。
SOAPBuilder花费了大约1年的时间用来测试面向RPC方式的互用性（调试每种RPC的编码实现）。然而WS-I的 Basic Profile Working Group (BPWG) 声称使用RPC编码很难实现互用性，尤其在处理RPC编码认可的普通数据类型和数据结构时。它将被从最近提出的互用性资料中（详细资料见Go Online box）剔除出来。这意味着WS-I建议仅适用于通过面向文档类型来实现互用性问题。但这将问题退回到应用程序上，而使Web services从本质上只能是在Internet上来回传送文件。这还是不能解决互用性问题。
.NET和J2EE平台的基本性能的发展归功于对内部企业局域网（corporate LANs ）或其他受控的公司内部网络中对自定义应用程序开发支持的需求。程序开发最初的主要范围被假定在一个公司里。围绕.NET和J2EE建立的产品和service是直接销往各个公司的，它们提供用于商业业务处理的商用应用程序工程开发的支持 。
以特定的语言和平台来支持业务数据处理会将用户局限于一种语言、产品或中间件构造中，它们决定了软件开发商能获得多少收益，有关这种收益的竞争就是出现各种各样平台的原因。
Web service标准承诺通过提供一个通用的XML消息抽象层来解决.NET和J2EE之间的差异。然而，该规范本身的局限性以及在其实现中的局限性都将限制互用性实现的级别。
软件工业还在持续着收益之争，因为大量建立的软件公司的商业模式是基于此的。它们在目前的客户群（installed base）不受威胁的情况下不可能做出改变，或者放弃它们所依赖的现有客户。这就是说，当你在业务中使用Web service时，它们可能会在其中增加一个解决重要问题的抽象层。然而，在你处理.NET和J2EE之间的互用性时，了解其可能性和局限性是非常重要的，这同样适用于成功实现论证（比如WSID提供的图表）和WS-I提供的大量建议。
关于作者:
Richard Bonneau是IONA Technologies的一名著名工程师。他以前曾担任Web Services Integration Platform Products的技术主管，现在则成为Technology Research的一名主管。Rich还在Digital Equipment Corp./Compaq Computer公司从事过不同系统的整合和软件技术的研究，他代表IONA出席了本文中提到的WSID和WS-I大会。你可以通过rich.Bonneau@iona.com和他联系。
Eric Newcomer是IONA Technologies的CTO，该公司为Web service的整合提供独立的电子商务平台。Eric主要负责定制IONA的技术蓝图和IONA的Orbix E2A E-business Platforms的发展方向，因为它们和标准采用、架构和产品设计相关。他是World Wide Web Consortium中的XML Protocols 和Web Services Architecture Working Group的成员，也是Understanding Web Services (Addison-Wesley, 2002)一书的作者。他的联系方式是eric.newcomer@iona.com。
……