用Web Services來整合.NET和J2EE

互用性(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「版」的技術。這就說明存在一個重要的互用性問題，由於每種編程語言(根據定義來劃分)都有其各自特定的數據類型和數據結構。
　　
　　僅憑一個簡單的HTTP鏈接是沒法實現互用性的，由於程序是在操做系統之上的編程語言抽象層中進行開發的。.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)等協議。瞭解它們真正能解決什麼問題以及如何經過使用它們來解決問題是至關重要的。
　　
　　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)。Web service規範和實現它們的底層平臺是徹底獨立開的，這和HTTP與HTML之間的狀況類似，同時它們能在.NET和J2EE平臺上運行的很好。
　　
　　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的調用方法(你是否須要在一個普通文檔上用詳細的參數或相對較少的調用操做來完成大量特定的方法調用呢?)和被傳輸的數據類型(你須要轉換的數據是簡單的仍是複雜的數據類型?)來決定。

 

原文：http://www.it28.cn/ASPNET/WebService/256485.html