互用性（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大會。你可以通過[email protected]和他聯系。
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)一書的作者。他的聯系方式是[email protected]。