熱點推薦:
您现在的位置: 電腦知識網 >> 編程 >> .NET編程 >> 正文

用Web Services來整合.NET和J2EE

2013-11-13 10:13:05  來源: .NET編程 

  互用性(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的交互
From:http://tw.wingwit.com/Article/program/net/201311/12952.html
    Copyright © 2005-2013 電腦知識網 Computer Knowledge   All rights reserved.