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

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

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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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


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

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

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

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

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

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

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

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

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

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

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


關于作者:
Richard Bonneau是IONA Technologies的一名著名工程師。他以前曾擔任Web Services Integration Platform Products的技術主管，現(xiàn)在則成為Technology Research的一名主管。Rich還在Digital Equipment Corp./Compaq Computer公司從事過不同系統(tǒng)的整合和軟件技術的研究，他代表IONA出席了本文中提到的WSID和WS-I大會。你可以通過[email protected]和他聯(lián)系。
Eric Newcomer是IONA Technologies的CTO，該公司為Web service的整合提供獨立的電子商務平臺。Eric主要負責定制IONA的技術藍圖和IONA的Orbix E2A E-business Platforms的發(fā)展方向，因為它們和標準采用、架構和產(chǎn)品設計相關。他是World Wide Web Consortium中的XML Protocols 和Web Services Architecture Working Group的成員，也是Understanding Web Services (Addison-Wesley, 2002)一書的作者。他的聯(lián)系方式是[email protected]。