發展中的SOAP互操作性

　　在過去這半年中，在不同平臺的多種SOAP協議實現之間的互操作性問題上已經取得了重大的進展。在這篇文章中，Tony Hong考察了一些SOAP工具包實現者所面臨的互操作性方面的早期更改，以及開發人員社群為解決這些問題所採取的各個步驟。

　　過去，軟體系統之間的通訊，尤其是兩個或兩個以上不同體系結構之間的通訊，通常是由各種特殊方法和專利協議隨便地拼湊在一起。這種整合軟體的方法通常難度大、成本高、並且費時間，尤其是當體系結構必須支援的連線數量增加時更是如此。

　　Web服務運作的一個關鍵目標一直是：開發一系列被普遍支援的協議，它們在比以往更大的規模上實現“一把抓”的系統對系統通訊。SOAP就是這樣一種協議，它為系統對系統通訊定義了一個基於XML的編碼和封裝的標準。

　　自從首次介紹這種規範以來，至今已經出現了50多個SOAP工具包，而且其數量還在繼續增長。工具包的數量和多樣性突出表現了計算機界是多麼迅速地接受了SOAP。然而，只有確保實現工具包之間的互操作性，才能體現出SOAP的全部價值。

　　本文中，我將著眼於工具包實現者在SOAP互操作性前沿曾面對的一些難題，以及他們怎樣齊心協力克服其中的一些難題。我還會考查一個案例研究，它清楚地說明了經過改進的互操作性環境。

　　互操作性難題

　　應用程式使用SOAP工具包(通常以庫的形式來使用)來制定基於XML的SOAP信封，通過HTTP或SMTP這樣的傳輸協議傳送這些信封，並且對進入的SOAP信封進行處理。如果兩個SOAP工具包對如何建立和解釋信封作出了不同的設想，就可能產生互操作性問題。

　　例如：

　　·一或兩個SOAP工具包實現的可能僅僅是全部SOAP或XML規範的一部分。某些情況下，一個系統傳送了其它系統無法處理的SOAP文件，這就會在支援的功能上發生不匹配。

　　·SOAP規範使某些東西可選 ― 比如，SOAP規範使您能夠選擇為已編碼的引數傳送型別資訊。如果一個實現假定型別資訊存在於它所接收到的訊息中，它就可能無法和另一個選擇不傳送該資訊的實現進行互操作。

　　·對於規範語言表達不明確的部分，兩個實現者可能會給出不同的解釋。

　　最終，實現者可能很容易地在他們的工具包中犯下了一些單機測試中顯示不出來的錯誤。這樣的錯誤可能會導致當兩個不同的工具包試圖掛接到一起時所產生的互操作性問題。

　　解決方案：通訊和測試

　　為了幫助解決上述問題並且從總體上提高SOAP互操作性，建立了SOAPBuilders線上組。該組織的成員各式各樣，有的來自象IBM、Microsoft這樣的大公司，也有的是有自己的開放原始碼工具包的個人。為增進交流並提供跨工具包測試的機會，SOAPBuilders線上組為工具包實現者社群提供了下列工具：

　　·一個郵件列表，作為討論實現和互操作性問題的論壇。

　　·一個互操作性測試套件規範

　　·一個測試伺服器端點目錄

　　·連線測試結果的連結

　　為了支援互操作性測試的上述需要，成立了SOAPBuilders互操作性實驗室(Interoperability Lab，ILAB)。您可以從 參考資料部分的連結中找到關於ILAB的更多內容。

　　SOAPBuilders測試套件

　　清單中活動的核心是一套SOAPBuilders互操作性測試套件。它是一個簡單的“回送”SOAP遠端過程呼叫(RPC)請求的集合，在RPC中客戶機傳送一個某種型別(例如整型、字串型等)的引數，伺服器簡單地返回一個同樣型別的等值的引數。然後客戶檢查該返回值，確定是否與傳送的值相匹配。 圖1說明了這樣一個echoString測試的整個往返過程：

　通過執行此往返過程，該測試運用了：

　　·伺服器對客戶端SOAP信封進行語法分析的能力。

　　·伺服器對信封中包含的已編碼引數進行無序化處理的能力。

　　·客戶機對伺服器響應所傳送的SOAP信封進行語法分析的能力。

　　·客戶機對伺服器傳送回來的已編碼引數進行無序化處理的能力。

　　目前，回送方法是為下列資料型別定義的：

　　·string

　　·integer

　　·float

　　·struct

　　·dateTime

　　·base64Binary

　　·string陣列

　　·integer陣列

　　·float陣列

　　·struct陣列

　　當一個客戶機與伺服器一起執行這種測試時，會記錄每次測試的狀態：“通過”或者“失敗”。許多實現者已經公佈了他們的客戶機結果(請參閱 參考資料)。 表1顯示了用工具包“X”建立的客戶機與各種伺服器之間的一系列樣本測試結果。

　　表1：樣本客戶機測試結果矩陣

　　一旦一對客戶機―伺服器在一個(或者全部)測試中進行互動操作失敗，這一問題通常會在列表中公佈出來，這樣實現者社群就有機會立即探討失敗的原因以及應該怎樣糾正錯誤。

　　一個樣本互操作性問題列表

　　下面列出了一些在測試中遇到的和論壇中討論的問題示例。這裡沒有詳盡列出所有的問題，而是提供了一個過去曾經出現過的問題型別樣本。

　　·當繫結到HTTP時，SOAP強制使用被稱為“SOAPAction”的HTTP報頭。與SOAP規範相反，一些工具包不引用SOAPAction HTTP報頭值，這就會使那些假定所有的SOAPAction值都將被引用的工具包出現問題。

　　·SOAP規範允許但不需要引數的明確“on-the-wire”分類資訊。“on-the-wire”分類資訊是直接包括在 SOAP 訊息信封中的型別資訊。一些工具包對指令進行無序化處理要依靠“on-the-wire”分類資訊，而其它工具包則不傳送“on-the-wire”型別資訊。

　　·SOAP規範不強制使用XSD模式的特定版本，考慮到在SOAP規範建立時，XML模式的標準還沒有固定下來，這一點可以理解。工具包有時不能對使用不同版本的XML模式的其它工具包傳送過來的已編碼引數進行無序化處理(例如使用2001版XML模式的工具包就不能對使用1999版XML模式的工具包傳送過來的已編碼引數進行無序化處理)。

　　·有些工具包不能對其它工具包傳送過來的Unicode位元組順序標誌進行語法分析。

　　·有些工具包不能處理對XML ID/HREF引用機制的使用(位於接收中的SOAP信封內部)。

　關於這些問題及其解決方案的更詳細資訊，請參閱 SOAPBuilders 訊息檔案檔案(請參見參考資料)。

　　案例研究：SOAP互操作性示範

　　實現者社群的共同努力已經在非常短的時間內取得了一定的、切實的成效，發現和修正了一些錯誤，澄清了一些對規範的解釋。因此，許多工具包都已經通過補丁程式進行了修改，並修正了一些錯誤，來提高互操作性。

　　為了舉例說明改進後的互操作性的狀況，微軟和IBM在2001年5月舉辦的Networld+Interop展示會上共同發起了一個SOAP互操作性活動，該展示會有若干廠商和個人參加，展示了SOAPBuilder組的許多工作成果。在這一展示會上，利用多種平臺上基於SOAP的客戶機和伺服器，示範了一種簡單的商業對商業模型，請參見圖2。

　　　圖2：SOAP互操作事件案例

　　·賣方向註冊方登記自己的出席狀況。

　　·買方從註冊方那裡獲取所有登記過的賣方列表。

　　·買方向賣方發出一個專案的報價請求。

　　·賣方響應，向買方報價。

　　·在買方和若干其他賣方之間重複第3和第4個步驟。

　　·買方向選出的賣方傳送該專案的購買定單。

　　在定義了商業案例之後，SOAPBuilder組又定義了支援該案例的程式介面。接著，每個參與者或者作為啟用SOAP的服務端點實現此介面(在賣方和註冊方實現的情況下)、或者作為可以利用這些端點的客戶實現此介面(在買方實現的情況下)，一個由買方、賣方和註冊方組成的活動網路就此誕生。

　　由於SOAPBuilders組已經完成了交叉實現互操作性的工作，十多個基於許多不同平臺和語言(Java、COM、.NET、Perl等)的工具包能夠相對容易地實現整合。

　　後續步驟

　　當前形式的SOAPBuilders互操作性測試套件只是個開始，它還將繼續發展完善。測試過程的今後發展將極有可能包括以下幾個方面：

　　·被測試的資料型別將會更加廣泛(主要包括目前W3C推薦的XML模式規範定義的一整套基本型別)。

　　·更多關於SOAP的有趣的變化會整合到測試中去。

　　·將對工具包嚴格遵守標準WSDL服務描述的能力進行測試。

　　·整合更多的一般文件風格的SOAP，而當前是把重點放在“section 5”方法呼叫/引數編碼上。

　　·測試過程和程式的附加自動化操作隨著測試參與者數目的增長而不斷增加。

　　結論

　　SOAP互操作性的狀況已經大大改觀，這要歸功於實現者之間交流的改善和工具包之間測試的使用。隨著新實現的出現和其它現有實現的改進，SOAP互操作性測試將是一個持續性的過程，它將成為Web服務互操作性測試的早期示例。仍然有許多工作需要去完成，而現在實現者社群已經為SOAP互操作性的持續發展和改進奠定了堅實的基礎。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14751907/viewspace-414873/，如需轉載，請註明出處，否則將追究法律責任。