互用性(Interoperability)問題說起來容易但通常實現起來卻比較困難
盡管Web service曾承諾要提供最佳的解決方案來銜接基於
NET和J
EE的應用程序
但其過程卻並不簡單
我們發現在使用SOAPBuilders和Web Services Interoperability Demo (WSID) 時還需要考慮許多問題
近期發布的Web Services Interoperability Organization (WS
I)對此也提供了很多有價值的深層見解
本文包括了從這個demo的開發過程
參與SOAPBuilders互用性測試
以及WS
I於近期發布的有關互用性的規范中獲得的經驗總結(想了解更多關於WS
I的資料
可以查閱工具條中的
談談WS
I
)
以下
我們就開始研究在哪些范圍可以通過使用Web services來實現互用性以減少你目前以及未來在
NET和J
EE上的投資
我們提供的結論將有助於你決定是否應該同時對這兩種平台進行投資
以及基於Web service互用性的局限性是否會使你只選擇其中的一個平台
互用性問題出現於計算機行業發展的早期階段
當時軟件的開發是為了適應某一特定的硬件應運而生的
近期則是為了適應采用特定硬件配置的特定操作系統
然而
操作系統是會經常更換的
而且經常會采用新的硬件或對硬件進行升級
因此
盡管計算機應用程序使用了基於操作系統的編譯或解釋語言
但仍然受到操作系統改變的沖擊
這的確是事實
盡管有一些高級語言(有時被稱為第三或第四代語言
比如Visual Basic
C#和Java)的幕後想法是使程序員在一種更高級別的抽象層中來開發程序
在計算機應用的早期階段
人們沒有太多地考慮接口連接或整合程序的問題
這種狀況一直持續到計算機體現出了重要的商業用途
使部分或所有商業操作實現自動化
一些有關投資保護(investment protection)
整合以及互用性等實際問題才隨之產生
商業要求無論投資何種軟件
他們都可以持續使用這些程序
而不管硬件
操作系統和開發技術是否發生變化
這就使得軟件在完全不同的硬件和操作系統之間的兼容性成為企業最大的
花費最高的問題
因為它直接影響到生產力(productivity)
停工期(downtime )
機會的把握和其他一些失效方面的問題
NET和J
EE的互用性問題之所以非常重要
是因為大多數企業都在使用其中之一或同時使用這兩種平台來開發程序
NET和J
EE分別代表了解決本質上相同的問題的不同方法:開發
部署和管理定制商業程序
定制商業程序的重要性在於商務本身有著不同的運作
如果不能使其具有獨特之處則會影響管理存貨(inventory)
處理定單或提供財政服務(financial services )這些問題
實際上
企業之間的相互競爭經常是很激烈的;比如
Wal
Mart曾吹捧自己著名的進銷存系統(inventory management system)
說它可以近實時地鞏固來自於其所有店鋪的購買力
而且能夠使用這些信息從供應商處得到較低進價
了解NET和JEE的區別 在一個完美世界裡
用於自定義應用程序的主要開發平台之間是完全兼容的
為某一平台編寫的程序能夠完全適用於其他平台
然而
我們離完美的世界還差得很遠
目前的軟件行業還相當不成熟
甚至可以說還沒有完全標准化
和電子行業及其他行業不同
計算機行業一直在為建立一套標准而努力
就在不久以前
DVD Forum成功地發布了一套用於DVD
ROM軟件和硬件的標准
所有DVD播放器均可播放任何DVD碟
所有DVD硬件制造商以及DVD碟制造商都將依照相同的編碼標准
而在軟件行業中
各主要開發商均實行各自不兼容的軟件系統
他們鼓吹各自的產品對開發人員如何有用
以此期望開發人員使用他們的產品來開發項目
因為一旦程序開發進入生產(production)階段
一般就不會更換使用其他產品了
軟件開發商們不是要建立一種所有人共同參與的市場
而是為了在這個復雜的開發市場中占有一席之地
Microsoft
NET的最初想法是希望進行接近操作系統平台的定制開發
當然
這是指使用Windows(目前是 XP
ME和
)
Visual Basic和C#是
NET平台上最重要的開發語言
並且它們不能在其他平台上運作
而基於Java的J#和
NET平台也是互不兼容的
Microsoft聲稱有許多開發商在開發與
NET common language runtime (CLR)相合作的語言
但直到今天
我們看到CLR還只是一個Windows
版
的技術
這就說明存在一個重要的互用性問題
因為每種編程語言(根據定義來劃分)都有其各自特定的數據類型和數據結構
僅憑一個簡單的HTTP連接是無法實現互用性的
因為程序是在操作系統之上的編程語言抽象層中進行開發的
NET和J
EE平台上的開發編程語言有著本質上的區別(
NET比較私有化而J
EE則更開放)
另一個重要的區別是對
NET來說
開發環境和操作系統是由同一開發商所提供的
NET和J
EE針對分布式應用程序有著不同的
不相兼容的二進制通訊協議(binary communication protocols):它們分別是
NET remoting和Remote Method Invocation/Internet Inter
Orb Protocol (IIOP)
當然和VB
C#
甚至J#相比
Java有著不同的數據類型和數據結構
通常解決互用性的首要問題就是處理數據類型和結構的不兼容型
這也是在測試Web services互用性過程中的一個重要挑戰
盡管Java運行於Windows平台
但J
EE應用程序卻能夠在任何平台上進行開發
並以通常被稱為
松散耦合
(loosely coupled)的方式和任何操作系統相連
換言之
J
EE盡量避免了使用操作系統特有的(operating
system
specific)特性和功能
比如直接內存管理(direct memory management);或是平台特有的(platform
specific)通信機制
比如Microsoft Remote Procedure Call (RPC)
NET開發環境能夠充分利用操作系統的
緊密耦合
(tightly coupled)或
本地
(native)實現的優勢
並能隨意使用Microsoft特定的功能和操作系統服務
總體來說
NET更容易使用
它比J
EE更好地結合了Windows本身的特性;但J
EE程序的優勢在於可以運行於其他操作系統之中
在編程語言行為(programming language behavior)
本地分布式計算協議
數據類型和結構
以及從操作系統服務中分離(isolation)等方面的不同都會對互用性產生影響
除非所有人都使用相同的編程語言
操作系統和應用程序
否則你還是需要了解各種復雜的互用性問題
以及哪種方案更值得去研究
權衡Web Services解決方案 用來解決互用性問題的Web services規范已經出台了
其中包括解決
NET和J
EE的互用性方案以及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 (W
C)底層的標准
W
C還負責定制HTML和XML領域的各種規范
另外
W
C還為Web Services Architecture Working Group提供贊助
該組織負責開發一個用於包含基本規范的Web service參考架構(reference architecture)
Web service規范和實現它們的底層平台是完全獨立開的
這和HTTP與HTML之間的情況相似
同時它們能在
NET和J
EE平台上運行的很好
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和J
EE的二進制通信協議裡
使用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
