互用性（Interoperability）問題說起來容易但通常實(shí)現(xiàn)起來卻比較困難。盡管Web service曾承諾要提供最佳的解決方案來銜接基于.NET和J2EE的應(yīng)用程序，但其過程卻并不簡單。我們發(fā)現(xiàn)在使用SOAPBuilders和Web Services Interoperability Demo (WSID) 時(shí)還需要考慮許多問題。近期發(fā)布的Web Services Interoperability Organization (WS-I)對(duì)此也提供了很多有價(jià)值的深層見解。

本文包括了從這個(gè)demo的開發(fā)過程、參與SOAPBuilders互用性測(cè)試，以及WS-I于近期發(fā)布的有關(guān)互用性的規(guī)范中獲得的經(jīng)驗(yàn)總結(jié)（想了解更多關(guān)于WS-I的資料，可以查閱工具條中的“談?wù)刉S-I”）。以下，我們就開始研究在哪些范圍可以通過使用Web services來實(shí)現(xiàn)互用性以減少你目前以及未來在.NET和J2EE上的投資。我們提供的結(jié)論將有助于你決定是否應(yīng)該同時(shí)對(duì)這兩種平臺(tái)進(jìn)行投資，以及基于Web service互用性的局限性是否會(huì)使你只選擇其中的一個(gè)平臺(tái)。

互用性問題出現(xiàn)于計(jì)算機(jī)行業(yè)發(fā)展的早期階段。當(dāng)時(shí)軟件的開發(fā)是為了適應(yīng)某一特定的硬件應(yīng)運(yùn)而生的，近期則是為了適應(yīng)采用特定硬件配置的特定操作系統(tǒng)。然而，操作系統(tǒng)是會(huì)經(jīng)常更換的，而且經(jīng)常會(huì)采用新的硬件或?qū)τ布�進(jìn)行升級(jí)。因此，盡管計(jì)算機(jī)應(yīng)用程序使用了基于操作系統(tǒng)的編譯或解釋語言，但仍然受到操作系統(tǒng)改變的沖擊。這的確是事實(shí)，盡管有一些高級(jí)語言（有時(shí)被稱為第三或第四代語言，比如Visual Basic、C#和Java）的幕后想法是使程序員在一種更高級(jí)別的抽象層中來開發(fā)程序。

在計(jì)算機(jī)應(yīng)用的早期階段，人們沒有太多地考慮接口連接或整合程序的問題。這種狀況一直持續(xù)到計(jì)算機(jī)體現(xiàn)出了重要的商業(yè)用途 -- 使部分或所有商業(yè)操作實(shí)現(xiàn)自動(dòng)化，一些有關(guān)投資保護(hù)（investment protection）、整合以及互用性等實(shí)際問題才隨之產(chǎn)生。商業(yè)要求無論投資何種軟件，他們都可以持續(xù)使用這些程序，而不管硬件、操作系統(tǒng)和開發(fā)技術(shù)是否發(fā)生變化。這就使得軟件在完全不同的硬件和操作系統(tǒng)之間的兼容性成為企業(yè)最大的、花費(fèi)最高的問題，因?yàn)樗�直接影響到生產(chǎn)力（productivity）、停工期（downtime ）、機(jī)會(huì)的把握和其他一些失效方面的問題。

.NET和J2EE的互用性問題之所以非常重要，是因?yàn)榇蠖鄶?shù)企業(yè)都在使用其中之一或同時(shí)使用這兩種平臺(tái)來開發(fā)程序。.NET和J2EE分別代表了解決本質(zhì)上相同的問題的不同方法：開發(fā)、部署和管理定制商業(yè)程序。定制商業(yè)程序的重要性在于商務(wù)本身有著不同的運(yùn)作，如果不能使其具有獨(dú)特之處則會(huì)影響管理存貨（inventory）、處理定單或提供財(cái)政服務(wù)（financial services ）這些問題。實(shí)際上，企業(yè)之間的相互競爭經(jīng)常是很激烈的；比如，Wal-Mart曾吹捧自己著名的進(jìn)銷存系統(tǒng)（inventory management system），說它可以近實(shí)時(shí)地鞏固來自于其所有店鋪的購買力，而且能夠使用這些信息從供應(yīng)商處得到較低進(jìn)價(jià)。

了解.NET和J2EE的區(qū)別
在一個(gè)完美世界里，用于自定義應(yīng)用程序的主要開發(fā)平臺(tái)之間是完全兼容的，為某一平臺(tái)編寫的程序能夠完全適用于其他平臺(tái)。然而，我們離完美的世界還差得很遠(yuǎn)。目前的軟件行業(yè)還相當(dāng)不成熟，甚至可以說還沒有完全標(biāo)準(zhǔn)化。

和電子行業(yè)及其他行業(yè)不同，計(jì)算機(jī)行業(yè)一直在為建立一套標(biāo)準(zhǔn)而努力。就在不久以前，DVD Forum成功地發(fā)布了一套用于DVD-ROM軟件和硬件的標(biāo)準(zhǔn)。所有DVD播放器均可播放任何DVD碟，所有DVD硬件制造商以及DVD碟制造商都將依照相同的編碼標(biāo)準(zhǔn)。而在軟件行業(yè)中，各主要開發(fā)商均實(shí)行各自不兼容的軟件系統(tǒng)。他們鼓吹各自的產(chǎn)品對(duì)開發(fā)人員如何有用，以此期望開發(fā)人員使用他們的產(chǎn)品來開發(fā)項(xiàng)目，因?yàn)橐坏┏绦蜷_發(fā)進(jìn)入生產(chǎn)（production）階段，一般就不會(huì)更換使用其他產(chǎn)品了。軟件開發(fā)商們不是要建立一種所有人共同參與的市場(chǎng)，而是為了在這個(gè)復(fù)雜的開發(fā)市場(chǎng)中占有一席之地。

Microsoft.NET的最初想法是希望進(jìn)行接近操作系統(tǒng)平臺(tái)的定制開發(fā)，當(dāng)然，這是指使用Windows（目前是 XP、ME和2000）。Visual Basic和C#是.NET平臺(tái)上最重要的開發(fā)語言，并且它們不能在其他平臺(tái)上運(yùn)作。而基于Java的J#和.NET平臺(tái)也是互不兼容的。Microsoft聲稱有許多開發(fā)商在開發(fā)與.NET common language runtime (CLR)相合作的語言，但直到今天，我們看到CLR還只是一個(gè)Windows“版”的技術(shù)。這就說明存在一個(gè)重要的互用性問題，因?yàn)槊糠N編程語言（根據(jù)定義來劃分）都有其各自特定的數(shù)據(jù)類型和數(shù)據(jù)結(jié)構(gòu)。


圖1. 比較.NET和J2EE
僅憑一個(gè)簡單的HTTP連接是無法實(shí)現(xiàn)互用性的，因?yàn)槌绦蚴窃诓僮飨到y(tǒng)之上的編程語言抽象層中進(jìn)行開發(fā)的（見圖1）。.NET和J2EE平臺(tái)上的開發(fā)編程語言有著本質(zhì)上的區(qū)別（.NET比較私有化而J2EE則更開放）。另一個(gè)重要的區(qū)別是對(duì).NET來說，開發(fā)環(huán)境和操作系統(tǒng)是由同一開發(fā)商所提供的。.NET和J2EE針對(duì)分布式應(yīng)用程序有著不同的、不相兼容的二進(jìn)制通訊協(xié)議（binary communication protocols）：它們分別是.NET remoting和Remote Method Invocation/Internet Inter-Orb Protocol (IIOP)。

當(dāng)然和VB、C#、甚至J#相比，Java有著不同的數(shù)據(jù)類型和數(shù)據(jù)結(jié)構(gòu)。通常解決互用性的首要問題就是處理數(shù)據(jù)類型和結(jié)構(gòu)的不兼容型，這也是在測(cè)試Web services互用性過程中的一個(gè)重要挑戰(zhàn)。

盡管Java運(yùn)行于Windows平臺(tái)，但J2EE應(yīng)用程序卻能夠在任何平臺(tái)上進(jìn)行開發(fā)，并以通常被稱為“松散耦合”（loosely coupled）的方式和任何操作系統(tǒng)相連。換言之，J2EE盡量避免了使用操作系統(tǒng)特有的（operating-system-specific）特性和功能，比如直接內(nèi)存管理（direct memory management）；或是平臺(tái)特有的（platform-specific）通信機(jī)制，比如Microsoft Remote Procedure Call (RPC)。

.NET開發(fā)環(huán)境能夠充分利用操作系統(tǒng)的“緊密耦合”（tightly coupled）或“本地”（native）實(shí)現(xiàn)的優(yōu)勢(shì)，并能隨意使用Microsoft特定的功能和操作系統(tǒng)服務(wù)�？傮w來說.NET更容易使用，它比J2EE更好地結(jié)合了Windows本身的特性；但J2EE程序的優(yōu)勢(shì)在于可以運(yùn)行于其他操作系統(tǒng)之中（見資源）。

在編程語言行為（programming language behavior）、本地分布式計(jì)算協(xié)議、數(shù)據(jù)類型和結(jié)構(gòu)，以及從操作系統(tǒng)服務(wù)中分離（isolation）等方面的不同都會(huì)對(duì)互用性產(chǎn)生影響。除非所有人都使用相同的編程語言、操作系統(tǒng)和應(yīng)用程序，否則你還是需要了解各種復(fù)雜的互用性問題，以及哪種方案更值得去研究。

權(quán)衡Web Services解決方案
用來解決互用性問題的Web services規(guī)范已經(jīng)出臺(tái)了，其中包括解決.NET和J2EE的互用性方案以及Simple Object Access Protocol (SOAP)、Web Services Description Language (WSDL)、Universal Description、Discovery和Integration (UDDI)等協(xié)議。了解它們真正能解決什么問題以及如何通過使用它們來解決問題是相當(dāng)重要的（見圖2）。


圖2. 回顧基本的Web Services架構(gòu)
SOAP規(guī)范定義了從HTTP到TCP/IP數(shù)據(jù)傳送的消息格式，WSDL規(guī)范定義了如何描述一個(gè)Web service，而UDDI則定義了如何注冊(cè)（register）和發(fā)現(xiàn)（discover）Web service描述。SOAP和WSDL是位于World Wide Web Consortium (W3C)底層的標(biāo)準(zhǔn)。W3C還負(fù)責(zé)定制HTML和XML領(lǐng)域的各種規(guī)范。

另外，W3C還為Web Services Architecture Working Group提供贊助，該組織負(fù)責(zé)開發(fā)一個(gè)用于包含基本規(guī)范的Web service參考架構(gòu)（reference architecture）。如圖2中可以看到架構(gòu)規(guī)范的工作草案圖表中所顯示的SOAP、WSDL和UDDI的關(guān)系。Web service規(guī)范和實(shí)現(xiàn)它們的底層平臺(tái)是完全獨(dú)立開的，這和HTTP與HTML之間的情況相似，同時(shí)它們能在.NET和J2EE平臺(tái)上運(yùn)行的很好。想了解更多關(guān)于.NET和J2EE對(duì)Web service規(guī)范的支持差異的比較，請(qǐng)查閱Eric的文章“Decide Between J2EE and .NET Web Services”。

Web Services Architecture Working Group還制定了一些擴(kuò)展規(guī)范（extended specification），比如在安全性、協(xié)調(diào)（orchestration）和事務(wù)處理方面的規(guī)范。用來實(shí)現(xiàn)這些規(guī)范的產(chǎn)品并不是很多，因此在這里我就不詳細(xì)地介紹了，除非說到一些更為復(fù)雜的互用性問題，因?yàn)槟惚仨毩私釽eb service交互的每個(gè)部分是否支持其他規(guī)范，以及它們支持哪些規(guī)范。但從到目前為止的經(jīng)驗(yàn)來看，即使是最基本的Web service規(guī)范也試圖向互用性挑戰(zhàn)，這是因?yàn)閃eb service技術(shù)存在于一個(gè)高級(jí)的抽象層中，它包括兩種主要的交互方式（interaction style），每種都有其各自考慮的范圍。

訪問機(jī)制
一般來說，開發(fā)人員會(huì)使用兩種機(jī)制來訪問一個(gè)遠(yuǎn)程程序（就是從位于一個(gè)不同地址空間(address space)的程序中調(diào)用另一個(gè)應(yīng)用程序）：RPC，它主要包括定義和使用外部程序調(diào)用接口；以及文件或隊(duì)列（queue）操作，其中程序通過對(duì)文件或隊(duì)列的讀寫來實(shí)現(xiàn)數(shù)據(jù)共享。

SOAP是被指定且考慮了這兩種途徑而編寫的（協(xié)議）。在Web service領(lǐng)域里，它們被稱為面向RPC（RPC-oriented） 和面向文檔（document-oriented）的交互方式。面向RPC方法在同步通信功能中比較常見，比如用在CORBA、COM，以及用在.NET和J2EE的二進(jìn)制通信協(xié)議里。使用RPC的一個(gè)好處是請(qǐng)求者（requestor）能看到接口定義（interface definition ）中有關(guān)service的定義；就是說，程序或方法名以及調(diào)用參數(shù)可以用來提供有關(guān)service行為的信息。使用基于工具包的 RPC方法的另一個(gè)好處是用于實(shí)現(xiàn)RPC方式的編程接口會(huì)自動(dòng)實(shí)現(xiàn)真實(shí)的數(shù)據(jù)類型與XML結(jié)構(gòu)之間的轉(zhuǎn)換。這樣會(huì)使程序員從數(shù)據(jù)轉(zhuǎn)換中解脫出來。使用面向文檔（或稱為消息傳輸）方式的優(yōu)勢(shì)在于請(qǐng)求者和提供者只需在數(shù)據(jù)（或schema）定義上取得一致就可以了，而對(duì)程序或方法調(diào)用的具體細(xì)節(jié)不作要求。然而，面向文檔方式僅限于使用XML文檔發(fā)送和接收數(shù)據(jù)。由于現(xiàn)在基于XML文檔的使用越來越廣泛，所以這也不是什么問題，盡管早期的使用者更愿意將非XML信息轉(zhuǎn)換到合適的XML結(jié)構(gòu)中，以此提高文件交互方式。最終，使用基于RPC還是基于文檔方式將由各自service的調(diào)用方法（你是否需要在一個(gè)普通文檔上用詳細(xì)的參數(shù)或相對(duì)較少的調(diào)用操作來完成大量特定的方法調(diào)用呢？）和被傳輸?shù)臄?shù)據(jù)類型（你需要轉(zhuǎn)換的數(shù)據(jù)是簡單的還是復(fù)雜的數(shù)據(jù)類型？）來決定。

大量的互用性工作是由 SOAPBuilders通過面向RPC的交互方式在WSID中完成的 -- 主要是通過“調(diào)試”或在多個(gè)SOAP產(chǎn)品實(shí)現(xiàn)中找到所支持?jǐn)?shù)據(jù)類型和架構(gòu)的共同點(diǎn)（common denominator）。其結(jié)果定義了一組可以用來實(shí)現(xiàn)互用性的數(shù)據(jù)類型和結(jié)構(gòu)。因此該列表成為你檢查正在使用的.NET和J2EE Web service產(chǎn)品的首要事情。在本文的后面部分我會(huì)教你怎么做。

較低層次的互用性工作是用面向文檔的交互方式來完成的。然而，WS-I曾聲稱很難用面向RPC方式來實(shí)現(xiàn)廣泛的互用性，并且呼吁企業(yè)使用面向文檔方式來獲得更好的結(jié)果。面向文檔方式實(shí)現(xiàn)了“文件共享”模式。傳輸SOAP消息就如同通過一個(gè)消息代理（message broker）-- 如Microsoft Message Queue (MSMQ) 或MQ Series的Java Messaging Services（JMS）來傳送異步消息（asynchronous message），其差別僅僅在于傳輸是在TCP/IP 上使用HTTP ，同時(shí)消息格式是由WSDL定義的。實(shí)際上，面向文檔方式盡量避免在Web service層中解決數(shù)據(jù)類型和結(jié)構(gòu)問題，但開發(fā)此類程序還需要做更多工作。我們將在本文的后面部分談到這個(gè)問題。

使用面向連接（Connection-Oriented）的協(xié)議
面向RPC和面向文檔交互之間的關(guān)系相當(dāng)于同步和異步通信協(xié)議之間的關(guān)系。同步通信通過阻塞（block）調(diào)用程序直到被調(diào)用的程序返回一個(gè)響應(yīng)來模擬一個(gè)子程序。如果被調(diào)用的程序沒有完成則調(diào)用程序會(huì)收到錯(cuò)誤消息，不管被調(diào)用的程序是在遠(yuǎn)程網(wǎng)絡(luò)上還是在本地機(jī)器中運(yùn)行。但實(shí)現(xiàn)這種模式的一個(gè)必要條件是調(diào)用程序和被調(diào)用程序之間必須保持一種連接或會(huì)話（conversation）。這種持續(xù)連接會(huì)消耗大量的網(wǎng)絡(luò)資源，這也是HTTP不支持它的原因。

這就意味著你在使用.NET和J2EE對(duì)象模式時(shí)會(huì)有很多限制條件。比如，你無法在HTTP上使用依賴于同一對(duì)話的多個(gè)交互操作的SOAP，而且你無法執(zhí)行對(duì)象生命周期管理（object lifecycle management ）功能，比如建構(gòu)（create）、析構(gòu)（destroy）和碎片整理（garbage collection）。

但通過異步調(diào)用，你可以通過一個(gè)程序?qū)懭胛募�，隨后用另一個(gè)程序來從文件中讀出數(shù)據(jù)。你只需要在讀寫文件的過程中有一個(gè)網(wǎng)絡(luò)連接。這些程序可以在同一機(jī)器或不同機(jī)器的相同或不同地址空間中運(yùn)行，只要由“調(diào)用”（或生成）程序?qū)懭氲臄?shù)據(jù)能夠被“被調(diào)用”（或使用）程序所接受就可以了。然而，在異步調(diào)用的情況下，調(diào)用程序在沒收到返回?cái)?shù)據(jù)時(shí)無法了解到底發(fā)生了什么；而定制標(biāo)準(zhǔn)的錯(cuò)誤處理和結(jié)果分析（resolution）又成為另外的互用性問題。

當(dāng)你無法決定Web service是不是正確的選擇時(shí)可以用它來衡量，了解你是否需要使用同步協(xié)議是非常重要的。從定義來說，基于HTTP 的Web service 是一種單向（one-way）異步消息，因此，它是解決基于文件或基于隊(duì)列的互用性問題的最好方法。比如，如果互用性需要包含用數(shù)據(jù)更新來同步用戶響應(yīng)，那么Web service可能就不是個(gè)好辦法了。然而盡管它有明顯的缺陷，卻還是能夠?qū)崿F(xiàn)互用性的。


圖3. 建立聯(lián)系
深入了解WSID
WSID是由Tony Hong (XMethods.net的創(chuàng)始人和主席)、SIGS/101會(huì)議和Web services技術(shù)的主要公司，包括Microsoft、IBM、IONA、eXcelon（現(xiàn)在是一個(gè)Progress Software）、Mind Electric、AmberPoint和WebMethods共同發(fā)起的，用來研究多開發(fā)商共同實(shí)現(xiàn)Web service兼容性的問題。其目標(biāo)是通過使用一個(gè)簡單卻不平凡的、切實(shí)的商業(yè)背景（business scenario）來實(shí)現(xiàn)一個(gè)多開發(fā)商共同開發(fā)的、跨平臺(tái)的Web service互用性范例。目前大多數(shù)demo實(shí)現(xiàn)是基于J2EE的產(chǎn)品，但由于Microsoft也是這個(gè)demo的發(fā)起者之一，所以.NET也被包括在內(nèi)。

WSID已經(jīng)在2002年8月在Boston 的Web Services One 大會(huì)上公布了，盡管其在線版（online version）的計(jì)劃還在醞釀之中（見資源）。該范例使用了一個(gè)簡單的購買網(wǎng)絡(luò)（purchasing network）。供應(yīng)商為用戶提供目錄，而用戶則給供應(yīng)商提交一份購買清單。供應(yīng)商會(huì)首先檢查用戶當(dāng)前的信用情況，然后向代理商店發(fā)出送貨單（見圖3）。出于幾個(gè)原因，XMethod通過提供靜態(tài)的XML文件和Web service接口實(shí)現(xiàn)其在demo網(wǎng)絡(luò)的重要作用：

一個(gè)帶Web service和瀏覽器接口的、包含所有參與者及其相關(guān)終端的列表。
從Customer到bank的映射關(guān)系。
保持WSDL文件和列出終端用戶的UDDI記錄。
包含所有已定義接口的標(biāo)準(zhǔn)WSDL文件的在線集合。
一個(gè)日志服務(wù)（logging service）。


這些接口都被包含在一個(gè)單獨(dú)的文檔中，你可以從XMethods Web site中找到它們（見資源）。這個(gè)很棒的Demo中包括用于內(nèi)部組件通信（inter-component communication）必須的RPC-encoded結(jié)合和document-literal結(jié)合實(shí)例。以及跨越所有平臺(tái)的大量的參與調(diào)節(jié)這些方式和編碼結(jié)合。Demo內(nèi)部操作成功與否主要取決于操作精度和WSDL Web service操作定義的相對(duì)簡單。而且，所有demo的行為都通過一個(gè)logging Web service來完成，這個(gè)service最初是由Xmethods網(wǎng)站提供的。

當(dāng)一部分人開始對(duì)WSID進(jìn)行組裝的時(shí)候，另一個(gè)由大約15個(gè)Web services供應(yīng)商組成的非正式組織將共同執(zhí)行一套普通測(cè)試版，通過使用SOAPBuilders來提高互用性水平。所有開發(fā)商均發(fā)布測(cè)試版終端以證明其實(shí)現(xiàn)互用性的水平。其他供應(yīng)商則可以測(cè)試其自身實(shí)現(xiàn)，使用已發(fā)布的測(cè)試終端，然后和其他供應(yīng)商一起完成對(duì)互用性水平的測(cè)定（見資源）。

SOAPBuilder是通過和其他成員一起討論來完成評(píng)估的，期間完成定制和校正的工作并得到一個(gè)新的測(cè)試版。每次討論的目的是通過一些重要的方法來提高互用性水平，比如在測(cè)試版中包括更多數(shù)據(jù)類型和結(jié)構(gòu)，或者在WSDL規(guī)范中包含更多內(nèi)容。該組織集中使用通過測(cè)試大量開發(fā)商對(duì)SOAP規(guī)范中RPC編碼的闡述，用面向RPC的交互方式來解決互用性問題。截至發(fā)稿日期，SOAPBuilder已經(jīng)完成了五次討論并得到大量的討論結(jié)果，結(jié)論證明用簡單數(shù)據(jù)類型（如整數(shù)型和文本型）比復(fù)雜數(shù)據(jù)類型（如數(shù)組和結(jié)構(gòu)型）更容易實(shí)現(xiàn)互用性。使用的數(shù)據(jù)類型越復(fù)雜，通過所有測(cè)試的開發(fā)商數(shù)量就越少。大多數(shù)開發(fā)商使用的是J2EE平臺(tái)，因此很容易找到J2EE供應(yīng)商并找到每個(gè)供應(yīng)商能夠在互用性測(cè)試中支持哪種數(shù)據(jù)類型及多少數(shù)據(jù)類型。你可以查看SOAPBuilder的結(jié)果以了解哪種數(shù)據(jù)類型和結(jié)構(gòu)在面向RPC 方式中是可用的。

由于該組織是非正式的，因此SOAPBuilders的章程還在商議之中。一些人認(rèn)為既然WS-I已經(jīng)發(fā)布了其最初的建議書（見資源），因此目前并不需要SOAPBuilders。然而，許多開發(fā)商還是堅(jiān)持支持基于RPC方式的Web services產(chǎn)品，而且使用RPC會(huì)簡化面向RPC中間件的互用性實(shí)現(xiàn)，比如.NET、J2EE和CORBA。在許多情況下SOAPBuilder和WS-I是交替使用的，因?yàn)樗鼈兊哪繕?biāo)都是建立一個(gè)實(shí)現(xiàn)互用性的通用Web service規(guī)范。

依照Web Service發(fā)展藍(lán)圖
當(dāng)Web service的應(yīng)用變得成熟并成為主流產(chǎn)品的時(shí)候，就需要在現(xiàn)有的Web service標(biāo)準(zhǔn)中增加一些其他功能，為了實(shí)現(xiàn)這些需求，WS-I計(jì)劃發(fā)布一個(gè)結(jié)構(gòu)藍(lán)圖（architectural road map），用于識(shí)別功能區(qū)和需要在將來的Web service規(guī)范中關(guān)注的功能。由于很多標(biāo)準(zhǔn)組織不斷建立和采用新的規(guī)范來增強(qiáng)現(xiàn)有的Web service功能，WS-I將繼續(xù)推出一個(gè)確保測(cè)試資料支持現(xiàn)有要求和內(nèi)部獨(dú)立性的論壇 。

我們要強(qiáng)調(diào)的是WS-I提出的兩個(gè)用于工具和基本應(yīng)用程序的主要開發(fā)平臺(tái)：C# (.NET)和Java (J2EE)。這就是說WS-I將來的工作很可能直接同.NET和J2EE的互用性相關(guān)，這將具有很重要的意義，因?yàn)閃S-I建議中的工具和策略將肯定（至少）能夠正確運(yùn)行于這兩個(gè)大的開發(fā)平臺(tái)之上。

SOAPBuilder花費(fèi)了大約1年的時(shí)間用來測(cè)試面向RPC方式的互用性（調(diào)試每種RPC的編碼實(shí)現(xiàn)）。然而WS-I的 Basic Profile Working Group (BPWG) 聲稱使用RPC編碼很難實(shí)現(xiàn)互用性，尤其在處理RPC編碼認(rèn)可的普通數(shù)據(jù)類型和數(shù)據(jù)結(jié)構(gòu)時(shí)。它將被從最近提出的互用性資料中（詳細(xì)資料見Go Online box）剔除出來。這意味著WS-I建議僅適用于通過面向文檔類型來實(shí)現(xiàn)互用性問題。但這將問題退回到應(yīng)用程序上，而使Web services從本質(zhì)上只能是在Internet上來回傳送文件。這還是不能解決互用性問題。

.NET和J2EE平臺(tái)的基本性能的發(fā)展歸功于對(duì)內(nèi)部企業(yè)局域網(wǎng)（corporate LANs ）或其他受控的公司內(nèi)部網(wǎng)絡(luò)中對(duì)自定義應(yīng)用程序開發(fā)支持的需求。程序開發(fā)最初的主要范圍被假定在一個(gè)公司里。圍繞.NET和J2EE建立的產(chǎn)品和service是直接銷往各個(gè)公司的，它們提供用于商業(yè)業(yè)務(wù)處理的商用應(yīng)用程序工程開發(fā)的支持 。

以特定的語言和平臺(tái)來支持業(yè)務(wù)數(shù)據(jù)處理會(huì)將用戶局限于一種語言、產(chǎn)品或中間件構(gòu)造中，它們決定了軟件開發(fā)商能獲得多少收益，有關(guān)這種收益的競爭就是出現(xiàn)各種各樣平臺(tái)的原因。

Web service標(biāo)準(zhǔn)承諾通過提供一個(gè)通用的XML消息抽象層來解決.NET和J2EE之間的差異。然而，該規(guī)范本身的局限性以及在其實(shí)現(xiàn)中的局限性都將限制互用性實(shí)現(xiàn)的級(jí)別。

軟件工業(yè)還在持續(xù)著收益之爭，因?yàn)榇罅拷�立的軟件公司的商業(yè)模式是基于此的。它們?cè)谀壳暗目蛻羧海╥nstalled base）不受威脅的情況下不可能做出改變，或者放棄它們所依賴的現(xiàn)有客戶。這就是說，當(dāng)你在業(yè)務(wù)中使用Web service時(shí)，它們可能會(huì)在其中增加一個(gè)解決重要問題的抽象層。然而，在你處理.NET和J2EE之間的互用性時(shí)，了解其可能性和局限性是非常重要的，這同樣適用于成功實(shí)現(xiàn)論證（比如WSID提供的圖表）和WS-I提供的大量建議。


關(guān)于作者:
Richard Bonneau是IONA Technologies的一名著名工程師。他以前曾擔(dān)任Web Services Integration Platform Products的技術(shù)主管，現(xiàn)在則成為Technology Research的一名主管。Rich還在Digital Equipment Corp./Compaq Computer公司從事過不同系統(tǒng)的整合和軟件技術(shù)的研究，他代表IONA出席了本文中提到的WSID和WS-I大會(huì)。你可以通過rich.Bonneau@iona.com和他聯(lián)系。
Eric Newcomer是IONA Technologies的CTO，該公司為Web service的整合提供獨(dú)立的電子商務(wù)平臺(tái)。Eric主要負(fù)責(zé)定制IONA的技術(shù)藍(lán)圖和IONA的Orbix E2A E-business Platforms的發(fā)展方向，因?yàn)樗鼈兒蜆?biāo)準(zhǔn)采用、架構(gòu)和產(chǎn)品設(shè)計(jì)相關(guān)。他是World Wide Web Consortium中的XML Protocols 和Web Services Architecture Working Group的成員，也是Understanding Web Services (Addison-Wesley, 2002)一書的作者。他的聯(lián)系方式是eric.newcomer@iona.com。