您是否知道鬆散類型 Web 服務和強類型 Web 服務編程方法的區別？IBM 高級技術人員 Andre Tost 將對這些區別加以說明，並將解釋爲什麼大多數情況下需要強類型服務。
Web 服務越來越多地用於企業應用程序集成（Enterprise Application Integration，EAI），在 EAI 中，服務使用者和服務提供者使用企業服務總線（Enterprise Service Bus，ESB）進行通信。企業應用程序的集成由來已久了，通常是通過創建應用程序適配器完成的，應用程序適配器會將消息轉換爲內部專用格式和協議。
從表面上看，使用 Web 服務對應用程序進行集成似乎是和以前的集成方案一樣（或者，至少十分相似）的概念。但與過去相比，Web 服務能使標準化程度更高，且能提供更好的工具，平臺與編程語言間的互操作性也更好。
描述系統的相關服務接口仍然是一個挑戰。開發人員通常使用兩種方法之一應對這項挑戰。一方面，Web 服務描述語言（Web Services Description Language，WSDL）定義可以利用消息的 XML 架構描述，允許準確描述交換的消息。另一方面，很多服務均使用通用接口構建：一個字符串傳入，另一個字符串傳出，或者交換純二進制對象。對消息的正確解釋的工作留給了使用者和提供者。儘管在出現更改時，認爲這種方法更爲靈活（因爲消息的具體細節在服務實現中處理），但同時也更容易出錯，而且要求進行更多的手動編程工作。
在本文中，我將比較這兩種方式，並會就每種方式的應用場合進行舉例說明。
  |
|
首先，讓我們定義本文範圍內的鬆散類型這一術語。鬆散類型意味着服務的接口定義（使用 WSDL）不包含強定義服務所使用的任何消息格式的架構。也就是說，應用程序可以不完全單獨遵從來自服務接口定義的消息實例。
鬆散類型描述的一個例子就是將消息的實際內容編碼爲單個字符串的 Web 服務。此服務接口描述一個 xsd:string 類型的輸入參數和一個輸出參數。其 WSDL <types> 部分可能與下面的清單 1 類似。
清單 1. WSDL <types>
|
請注意，由於這是“包裝的文檔/文本”Web 服務，因此包裝元素稱爲“execute”。（此處並顯示所有 WSDL，但剩餘部分肯定包含文檔/文本綁定。）單個輸入和輸出參數定義以粗體突出顯示。
對於此定義，您並不能準確地知道請求和響應消息的內容的格式。它可能爲字符分隔的字符串、固定長度的字符串，或者，甚至可以是 XML。無論何種情況，服務使用者和服務提供者需要就雙方都能理解的共同格式達成一致，而且雙方都需要開發代碼以正確地構建和解釋該格式。由於消息內容的具體定義並沒有包括在 WSDL 定義中，因此這裏沒有可提供幫助的工具。
有利的一面是，如果消息結構發生更改，您無須更改新 WSDL 定義。只要確保所有的參與方均知道這一更改，並且能處理更改後的格式就行了。不過，此方法的缺點通常比優點更爲突出，特別在將 XML 作爲內容發送時更是如此。
讓我們更進一步瞭解在此字符串中發送 XML 數據時的情況。當現有應用程序包含 XML 格式的信息，並且要將此數據原封不動地通過 Web 服務接口發送時，就可能出現這種情況。（由於 XML 可以表示爲字符串，所以將數據表示爲字符串參數。）例如，假設需要使用以下格式的 XML 文檔作爲客戶機請求的響應發送，如下面的清單 2 所示。
清單 2. 在字符串中發送 XML
|
清單 3 演示了當使用清單 2 中的服務接口定義時，簡單對象訪問協議 (SOAP) 響應消息的格式。
清單 3. SOAP 響應消息
|
這看起來並不像 XML，對吧？這是由於對 SOAP 引擎而言，它是一個字符串。如果將 XML 傳遞到此字符串中，將對其進行編碼，以使其不干涉 SOAP 引擎的 XML 處理。不過，在將其送回客戶機之前，會再將已編碼的字符串解碼。此過程對於實際的服務客戶機和提供者實現都是透明的，而這無疑是非常有利的。但另一方面，它增加了消息的大小，使得調試 SOAO 消息傳遞更難了，並增加了每條消息的處理時間。在本文的稍後部分，我將給出另一個示例，該示例將提供同樣的功能，但避免了其中的這些問題。在這裏我要指出的是，使用字符串參數通過 Web 服務接口發送 XML 通常被認爲是糟糕的設計，應該加以避免。
有關在字符串中發送 XML 的示例，請參閱本文中提供的 EAR 文件，GenericString.ear。
指示 WSDL 文件中不存在消息格式的嚴格定義的另一種方式就是使用 <xsd:any/> 元素。在架構中出現此元素將僅指示在運行時此位置可以出現任何類型的 XML。區別在於，實際的 XML 將進入消息中，而不會轉換爲編碼的字符串。同時，消息的處理仍然必須手動編碼，因爲 WSDL 不包含任何關於此消息的提示。
因此 Java™ APIs for XML-Based Remote Procedure Call (JAX-RPC) 規範描述了將 <xsd:any/> 映射到 javax.xml.soap.SOAPElement。此接口屬於標準 SOAP with Attachments API for Java (SAAJ API)，定義 SOAP 消息各個元素的 Java 接口。可以採用分析普通 Document Object Model (DOM) 的方式對其進行分析。我將在後面給出這一點的示例。
以下是前面所使用過的 WSDL 定義；不過，我使用 <xsd:any/> 代替了泛型字符串，如下面的清單 4 所示。
清單 4. <xsd:any/>
|
使用 <xsd:any/> 比使用泛型字符串更可取，因爲這樣就不需要對消息進行編碼。不過，它只能和 XML 消息一起使用，而且仍然要求代碼出現在服務提供者和使用者端，以分析和構建消息。清單 5 演示了將我在清單 4 中所使用的相同的 Customer XML 文檔發送回時的服務提供者的代碼：
清單 5. 服務提供者代碼
|
清單 6 顯示了以上請求的 SOAP 響應消息的內容。
清單 6. SOAP 響應消息
|
這比您在清單 5 中所看到的消息更具可讀性，因爲沒有對其進行編碼。不過，我必須手動構建響應消息。另外，我沒有指出客戶機響應的消息的架構。
本文中的 GenericAny.ear 部分提供了一個完整的示例，其中演示了 <xsd:any/> 元素的用法。
鬆散類型 Web 服務的使用經常與在 WSDL 中定義的服務樣式相關。可以將服務的調用樣式定義爲“文檔”或“RPC”，編碼方式可爲“SOAP”或“文本”。這兩項的最常見組合稱爲“文檔/文本”。大部分 Web 服務引擎在缺省情況下都使用“包裝的文檔/文本”樣式。有關這些不同樣式的相關文檔，請參閱 developerWorks 文章“Which style of WDSL should I use?”。
不過，所使用的樣式與是否創建鬆散類型或泛型的接口沒有任何關係。“包裝的文檔/文本”樣式已定義，它將以調用遠程過程結束。此遠程過程具有一個或多個泛型參數，或強類型參數。同樣，您也可以定義一個泛型接口（如上面僅接受一個字符串的接口），然後在 WSDL 綁定中將其聲明爲“rpc/encoded”。
換句話說，調用樣式和接口的強類型這兩項設計決策彼此的影響很小（如果有）。
如上所述，鬆散類型 Web 服務可以在前面的接口定義中沒有聲明數據的結構情況下發送數據。很多情況下，這都很有用。例如，假設您具有一組粗粒度的服務，這些服務將可能很大的 XML 文檔作爲輸入。這些文檔可能具有不同的結構，具體取決於其使用的上下文。而且，這個結構可能在服務的生存期中經常更改。可以採用某種方式實現一個 Web 服務，使其可以處理所有這些不同類型的消息（很可能對消息進行分析，然後將其路由到其最終的目的地）。可以對消息格式進行更改，使它們具有向後兼容性，這樣就無需更新現有的代碼。
另一個例子是使用中介。中介具有 Web 服務接口，並接收消息。但很多時候，中介將消息路由到其最終的目的地之前僅對其進行某種常規處理。例如，提供消息記錄功能的中介不需要強類型接口，因爲它只記錄其所接收到的所有消息的內容。
最後，可能存在不能在 XML 架構中描述的消息格式，或選擇的 Web 服務引擎不能處理所得到的架構。例如，JAX-RPC 和 Java Architecture for XML Binding (JAXB) 規範就沒有定義完整的 XML 架構元素的 Java 映射集。由於存在不能映射的行業標準架構，因此無論如何都必須手動對遵循這些標準的消息進行編碼。大部分 JAX-RPC 一致性工具均採用與處理 <xsd:any/> 相似的方式處理這些架構元素，即將其映射到 javax.xml.soap.SOAPElement。
另一方面，您已在上面的示例中已看到，在 SOAP 信封中發送此類任意消息經常需要 SOAP 引擎進行額外的處理。消息一旦經過編碼，其線格式可讀性可能並不好。此外，您必須手動編寫代碼以處理消息的有效負載。由於 WSDL 中並沒有消息的確切定義，因此 Web 服務工具不能生成此代碼，而這將導致此類解決方案更容易出錯。無法進行消息驗證。如果消息格式更改，那麼與確保所有使用者和提供程者正確處理新格式相比，更新服務接口並重新生成綁定代碼會更容易。
瞭解了鬆散類型方法的種種明顯缺點之後，讓我們瞭解一種更好的選擇。
|
|
就像上面討論鬆散類型服務時一樣，也需要對“強類型”這一術語加以定義。該術語指在 XML 架構中包含了完整的輸入與輸出消息定義的服務，此 XML 架構或者包含在 WSDL 定義中，或者由該 WSDL 定義引用。
服務使用者和服務提供者必須交換的唯一信息就是 WSDL 定義，因爲該定義中包含着構建它們所需的所有信息。例如，以上面將 Customer 文檔作爲 Web 服務的結果返回的示例爲例，強類型 WSDL 定義可能與下面的清單 7 類似。
清單 7. 強類型 WSDL 定義
|
現在將不會簡單地定義一個字符串或 <xsd:any/> 參數作爲返回類型，而要使用一個名爲 Customer 的已完整定義的複雜類型。可以將這用於生成 Java 代碼，以將任何消息映射到具有 getter 和 setter 的常規 Java 對象中。您無需編寫代碼來手動分析 XML。
清單 8 顯示了此類服務的 Java 實現的格式。
清單 8. 已定義的複雜類型
|
JAX-RPC 工具將生成這裏使用的 Customer 和 Address 類。與上面的清單 6 一樣，通過網上傳遞的數據是純 XML。事實上，這些數據與 <xsd:any/> 示例中的數據完全一樣。另外還有一個好處，由於存在消息的完整架構，因此可以根據此架構進行驗證（儘管大部分引擎由於性能的原因並不這樣做）。
本文提供了完整的 TypedService.ear 文件。此文件以及本文的所有其他 ear 文件都還包含測試客戶機。
我前面曾提到，某些架構元素不能映射到 Java 中。另外，服務實現者有時候也可能希望開發自己的方式映射傳入的 SOAP 消息。另一個例外就是作爲 Web 服務一部分的文檔可能具有很多元素。服務的開發人員可能不希望將其映射到具有數百個參數的服務接口。
這些情況不要求將 Web 服務設計爲鬆散類型服務，而需要就接口與實現進行討論。服務可以在其接口定義中採用強類型方式，而在其實現中採用泛型方式 。JAX-RPC 規範要求一致性引擎提供跳過常規 XML 到 Java 類型映射的方法，而使用備用機制。例如，WebSphere® Application Server (Application Server) 允許將任何請求和/或響應消息映射爲 javax.xml.soap.SOAPElement 類型的實例（與 <xsd:any/> 的映射方式相似，請參閱上面的清單 4）。例如，上面所列出的 WSDL 摘要中包含完整的類型定義，可以將其映射爲以下 Java 服務端點接口，如下面的清單 9 所示。
清單 9. Java 服務端點接口
|
在此接口中沒有 Customer 或 Address 的概念。它完全留給開發人員處理傳入和傳出的 XML。（請參閱參考資料部分，參考條目中給出了更爲詳細描述這方面的文章。）
強類型 Web 服務爲服務的使用者和提供者提供了服務的數據結構的完整定義。這種正式約定使 SOAP 和 XML 的使用對客戶端代碼和服務器端代碼透明，工具可以方便地從這種正式約定生成代碼。如上面所示，在不能或不應使用生成的代碼的情況下，可以採用鬆散類型方式實現強類型接口。順便說一下，服務提供者和服務使用者可以採用不同的方式進行實現。服務實現者可能喜歡採用手動方式對消息進行映射和分析。不過，通過爲使用者提供完整的架構，該使用者可以選擇藉助工具生成適當的映射代碼。這兩者之間不需要任何進一步的文檔。
在這兩種情況下，由於不需要進行編碼，所以通過網絡傳輸的消息通常會更小。
|
|
在本文中，我演示了 Web 服務可以如何具有不同的類型級別。鬆散類型服務使用泛型參數定義，其中不以架構的形式包含消息內容的說明。它們可以包含二進制、字符串或 XML 格式（經過編碼的）的信息，但需由服務的使用者和提供者就使用的格式達成一致，並相應地進行處理。當消息格式發生更改，消息格式會隨服務內容不同而變化，以及處理普通工具不能處理的高級複雜數據結構時，鬆散類型服務更加靈活。另外，它們還可以對消息解釋進行手動優化。
強類型 Web 服務在 WSDL 中包含完整的架構定義。通常這將提高自動化程度、代碼生成質量、工具支持水平和改善標準化中間件的使用。這樣還能產生更爲穩定的代碼，使開發人員不必創建基礎結構級別的代碼。而且，即使採用泛型方式實現的服務也可以提供強類型接口定義。
在我所遇到的大多數實際場景中，強類型服務接口更爲適用。正如我在前面指出的，最好避免使用泛型字符串類型的接口。
不過，並沒有萬能的東西。常常需要由設計解決方案的架構師確定描述接口的最佳方法，具體取決於解決方案的具體要求、運行環境，甚至還要考慮開發團隊的首選的樣式。
|
|
| 描述 | 名字 | 大小 | 下載方法 |
|---|---|---|---|
| EAR 文件 | ws-loosevstrong.zip | 120 KB | FTP |
|
||||
 |
關於下載方法的信息 | |
 |
Get Adobe® Reader® |
|
|
學習
- 您可以參閱本文在 developerWorks 全球站點上的 英文原文。
- "Web 服務編程技巧和訣竅: 將 <xsd:any/>元素用於自定義序列化"（developerWorks，2004 年 1 月）。這篇文章演示瞭如何在 WSDL 中使用 <xsd:any/>。
- "Web 服務編程技巧與竅門: 用 SAAJ 和 JAX-RPC 構建 SOAP 響應信封"（developerWorks，2004 年 1 月）。上面文章的續篇，演示瞭如何使用 SAAJ 構建 SOAP 響應信封。
- "我應該採用哪一種 WSDL 樣式？"（developerWorks，2005 年 5 月）。一篇關於調用樣式的好文章。
- "Developer's introduction to JAX-RPC, Part 1: Learn the ins and outs of the JAX-RPC type-mapping system"（developerWorks，2002 年 11 月）。JAX-RPC 規範簡介。
- IBM developerWorks 團隊會在全球舉辦數百場可免費參加的 technical briefings。
- Standards roadmap——瞭解標準和規範對於 SOA 和 Web 服務開發工作的影響和重要性。
- SOA and Web services——有數百篇關於如何開發 Web 服務應用程序的文章以及入門級、中級和高級教程，將讓您大開眼界。
獲得產品和技術
- 瞭解 DB2®、Lotus®、Rational®、Tivoli® 和 WebSphere® 中的應用程序開發工具和中間件產品。您可以免費下載這些產品的評估版，也可以選擇 Linux™ 或 Windows® 版本的 developerWorks 的免費 Software Evaluation Kit。
討論
- developerWorks 博客：加入 developerWorks 社區。
