Java Web服務，第1部分: Java Web服務在未來一年內的發展

2006 年將是 Web 服務（特別是 Java Web 服務）發展標誌性的一年。新的第三代架構即將撩開面紗，這些架構將為 doc/lit SOAP 提供更好的支援，並能帶來潛在的效能提高。同時，第四代 WS-* 標準也最終開始形成一組可互操作的層，對 SOAP 和 WSDL 進行擴充，以支援核心企業需求。

這篇文章是我的 Java Web 系列的第 1 部分，我將討論以下 Web 服務目前的狀態和在 2006 年即將發生的主要變化，並將簡單說明新架構和技術如何相關和互動。後續文章將深入討論其中的很多架構和技術，希望能籍此讓您瞭解在該領域最新的發展，並關注其如何為您的編程項目提供協助。

背景介紹

從 SOAP 1.0 規範發布到今天，已經六年多了。在 SOAP 規範發布之前，開發人員早就在通過 網際網路通訊協定 (IP)交換 XML 訊息了，但 SOAP 的推出承諾對此技術進行正常化，並實現更好的互通性。SOAP 還提供了各種掛鈎 (hook) 機制，以方便擴充，從而可以添加進階基礎結構功能，以增強未來的 XML 訊息交換。WSDL 規範在 SOAP 推出後不久發布，添加了 Web 服務中繼資料的標準表示方法。主要軟體供應商很快看到了將 SOAP 和 WSDL 結合使用的潛力，在接下來的幾年裡，SOAP Web 服務似乎成了不可阻擋的發展潮流。

SOAP 和 WSDL 挑戰

儘管在整個行業中 SOAP+WSDL 快速崛起，但仍然在很多方面存在問題，會妨礙 SOAP 達到很多人所期望的完全成功。第一個方面就是互通性。儘管 SOAP 最誘人的一個重要方面就是它的互通性承諾，但實際進展卻並不明顯。這最初是由於對 rpc/encoded 樣式的 Web 服務（也稱為 rpc/enc）的強調所造成的，在此情況下，物件模型將序列化為 XML 然後再在接收端重新構造。此自動序列化/還原序列化功能使得 rpc/enc 非常易用（只要使用其支援的相對簡單的資料結構），但卻會導致產生無法用於任何目的的 XML。更糟糕的是，語言和平台支援的差異導致了實現之間大量的不相容現象。

被廣泛接受的 Web 服務最佳實務現在正傾向於使用 document/literal 樣式 (doc/lit) 替代 rpc/enc 樣式。在 doc/lit 中，XML 訊息格式是由 W3C XML Schema 定義所定義的。就理論上來說，這應當能消除互通性方面的任何問題，因為模式執行個體定義 XML 的實際結構，而每個平台負責恰當地處理該 XML。在實際中，對極為複雜的 W3C Schema 標準的支援程度參差不齊，且又帶來另外一些互通性問題。

較早的 rpc/enc 互通性問題和最近的 doc/lit 互通性問題都會因缺乏認識而進一步加重。對於 doc/lit，各種架構支援不同的模式標準子集，卻沒有列出缺少的特性，從而使得這種情況尤為尖銳。即使不同的架構聲稱支援特定的模式特性，實現也經常不完整，從而導致使用這些特性時出現互通性問題。轉向 doc/lit 的部分原因是希望能利用企業或行業標準模式。此類標準模式的設計通常沒有考慮會在 Web 服務中使用，因此它們常常使用 SOAP 架構不能提供良好支援的特性。

SOAP Web 服務的另一個問題是基礎結構擴充和基本 SOAP 處理——添加的可在一系列 Web 服務上應用的處理層——之間不斷的混淆不清。SOAP 的設計運行方便地添加此類擴充，但這些擴充通常僅在其為受多個架構支援的標準時才有用。這要求整個行業進行協作，但通常很難辦到。即使最基礎的擴充（如附件和安全性），也需要若干年進行開發，但仍然不受所有架構支援。

SOAP 的阻力

前一部分中詳細討論的互通性和標準化問題限制了 SOAP Web 服務的適用性，同時，SOAP 架構本身也通常很複雜，難於使用。優勢有限以及潛在的複雜性讓很多開發人員轉而採用比 SOAP 更簡單的替代方法。SOAP 的大部分阻力都來自與一項稱為 REST 的技術相關的方面。嚴格來說，REST 是可應用到 Web 服務的 HTTP 協議的基本規則的正常化技術。在實際中，REST 活動經常將正常化擱置在一邊，而在其中包含所有在不使用 SOAP 封裝的情況下在 HTTP 上傳輸 XML 文檔的所有東西，基本上與出現 SOAP 之前進行的直接 XML 文檔方式一樣。

REST 遠不如 SOAP 雄心勃勃。REST 自然被限制為使用 HTTP 作為傳輸層（儘管可以使用類似的方法進行其他傳輸），而 SOAP 從理論上來說是獨立於傳輸層的（儘管到目前為止只廣泛使用 HTTP 傳輸進行部署）。REST 並不包含任何直接添加基礎結構擴充的方法——但在 SOAP 真正開始提供此類擴充前，此限制都可以被視為無足輕重的方面。

由於 REST 的功能承諾並比不上 SOAP，因此通常不需要使用任何架構代碼來實現客戶機或伺服器，因此開發人員無需處理架構的複雜性。不太方便的一面是，此技術的確 需要直接實現 HTTP 和 XML 處理，不過很多開發人員都已經習慣處理這些技術了。直接處理 XML 甚至可以算得上是一個優勢，因為與 SOAP 架構提供的選擇相比，開發人員在這種情況下的選擇空間更大。

那麼，是不是應該丟掉 SOAP 而開始採用更簡單的 REST 呢？對很多 Web 服務應用程式的表單而言，這可能都是一個很實際的選擇，因此我並不反對這樣的想法。不過，有很多其他應用程式（特別在企業級）需要 SOAP 所承諾的基礎結構擴充和傳輸獨立性。轉向 REST 則意味著這些應用程式將需要直接實現安全、交易處理和協作等功能，而不是通過架構提供這些功能。大多數公司專屬應用程式程式將可能選擇完全避免使用 Web 服務，而不去花這份心思。

但就像電影中一樣，即使 SOAP 的前途看起來真的很灰暗，但仍然會有新的希望。這個希望來自即將推出的新一代架構。這些架構的目標是最終發掘 SOAP 的全部潛能，使實現全新的 SOAP Web 服務應用程式變成現實，同時大幅度提高 doc/lit Web 服務的互通性。