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