2006 年將是 Web 服務（特別是 Java Web 服務）發展標志性的一年。新的第三代框架即將撩開面紗，這些框架將為 doc/lit SOAP 提供更好的支持，並能帶來潛在的性能提高。同時，第四代 WS-* 標准也最終開始形成一組可互操作的層，對 SOAP 和 WSDL 進行擴展，以支持核心企業需求。
這篇文章是我的 Java Web 系列的第 1 部分，我將討論以下 Web 服務目前的狀態和在 2006 年即將發生的主要變化，並將簡單說明新框架和技術如何相關和交互。後續文章將深入討論其中的很多框架和技術，希望能籍此讓您了解在該領域最新的發展，並關注其如何為您的編程項目提供幫助。
背景介紹
從 SOAP 1.0 規范發布到今天，已經六年多了。在 SOAP 規范發布之前，開發人員早就在通過 Internet 協議交換 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 服務的互操作性。
Indigo 的重要性
盡管本系列是關於 Java 技術的，但我要提到的第一個新框架卻是來自開發人員打心底裡認為是 Java 技術的競爭對手：Microsoft® .NET。這個新框架是 Windows Communication Foundation (WCF)，也稱為 Indigo。Indigo 最初是打算作為即將推出的 Windosw “Longhorn”版本的一部分，但 Microsoft 已宣布將以 WCF 的形式提供給較老的 Windows 版本使用。WCF 有望在推出後替代較舊的 .NET 框架。
WCF 之所以對 Web 服務重要，其原因在於 Microsoft 台式機系統占有率的絕對優勢（不是完全 占有——像很多和我一樣的人就在使用 Linux® 進行所有工作，Macs 也很受歡迎——但在 90% 以上）。台式機系統占用率的絕對優勢意味著，當 Microsoft 推出新框架時，它就會有著巨大的影響。Microsoft 所支持的技術將自動成為大部分其他框架支持的目標，那些不受 Microsoft 支持的技術可能會成為“二等公民”，只有在客戶機和服務器均不使用 Microsoft 系統的情況下才能使用。
通過 WCF，Microsoft 將向基本 .NET 平台添加主要的新技術（雖然其中一些當前已通過 WSE 3.0 加載項提供給基本 .NET）。這些技術包括 XOP/MTOM、WS-Addressing、WS-Trust、WS-SecureConversation、WS- ReliableMessaging、WS-Coordination、WS-AtomicTransaction 和 WS-Policy。XOP 和 MTOM 是支持將二進制數據作為附件包含在 SOAP 消息中傳遞的標准，這可最終實現主要 SOAP 框架上可互操作附件（以前 Microsoft 僅支持一項稱為 DIME 的附件技術，而大部分框架都支持 Microsoft 的一項稱為 SwA 的早期建議方案）。WS-Addressing 提供了消息標識符、目標地址和操作的標准格式；標識符部分是多項其他技術所要求使用的部分，因此很重要，而地址和操作部分需用於支持後備傳輸（除 HTTP 之外）和異步操作。WS-Trust 和 WS-SecureConversation 對較舊的（已有廣泛支持）WS-Security 進行補充，支持性能更高的對稱加密。WS-ReliableMessaging 支持消息交付和序列保證。WS-Coordination 管理 Web 服務的分布式網絡中的操作序列。WS-AtomicTransaction 使用兩階段提交協議支持 SOAP 上的事務處理。最後，WS-Policy 定義 WSDL 的擴展，以便服務聲明其對使用所有這些技術的要求。這些 WCF 技術代表了使用 Web 服務構建企業應用程序所必要的大部分支持服務。
如果 WCF 中包含的技術的確 得到了廣泛的支持且具有很好的互操作性，我們就將有足夠的理由以 SOAP 為核心構造企業 Web 服務。現在，這變成現實的可能性很大。Microsoft 於 2005 年 11 月舉行的 WCF Interoperability Plug 盛會上展示了大部分主要 SOAP 框架，其中包括我將要在本文其余部分集中討論的 Java 備選框架。這些早期的測試結果非常有限，實現完全互操作性仍然有一些問題（包括要支持仍在不斷變化的 WS-* 標准的特別版本），但整個行業的方向無疑是將 WCF 技術作為下一代 SOAP 框架的核心部分加以支持。
Sun 和 Java 標准
JAX-RPC 1.0 是 Java 方面的 Web 服務的原始標准。雖然 JAX-RPC 的設計思想是可以為實際 Web 服務實現使用不同的協議實現，但在實踐中，僅將其用於 SOAP 服務。已經開發了多個不同的 JAX-RPC 實現，其中使用最廣泛的可能就是 Apache 框架了，其次是 Sun Microsystems 作為 Java Web Services Developer Pack 的一部分分發的 Reference Implementation。
在開發 JAX-RPC 1.0 時，行業中的很多人認為 rpc/enc 樣式的 SOAP 將成為最方便和易用的 Web 服務。JAX-RPC 1.0 規范要求對 rpc/enc 和 doc/lit 樣式進行支持，但並不要求對很多模式特性進行支持。這樣就帶來了一個很不幸的副作用，使 doc/lit SOAP（此技術是基於模式的）事實上成了一個二流選項。
JAX-RPC 1.0 對 Web 服務功能的認識也有一定的局限。從其名稱可以看出，最初的目的是為了支持使用 XML 的遠程過程調用（Remote Procedure Call，RPC）操作。Java 當時已經有了一項面向 Java 應用程序間的 RPC 調用的現有技術，即遠程方法調用（Remote Method Invocation，RMI）。該規范團隊選擇了在現有 RMI 接口上對 JAX-RPC 進行建模。只要通過請求-響應操作使用 rpc/enc SOAP，此模型就可相當接近地進行匹配，不過映射到異步操作或其他傳輸的效果並不理想。到 2003 年底，有關人員認識到，總要對 JAX-RPC 進行大幅修訂，以處理這些問題和其他問題，因此 Sun 組成了一個專家組開始進行 JAX-RPC 2.0 規范的開發。
JAX-*
JAX-RPC 2.0 開發工作的主要目標是對各項標准進行更新，以支持 JAX-RPC 1.X 的強制要求（基於 Java 5 特性，如 Annotation 和泛型），改進消息傳遞支持（包括除 HTTP 外的異步操作和傳輸），並通過使用 JAXB 2.0 綁定替代 JAX-RPC 1.X 的簡單（但局限性很強）內置綁定來改進模式支持。出於對更改范圍的強調和其他原因，這個後續標准的名稱更改成了 JAX-WS 2.0。JAX-WS 2.0 現在已經提供了預發布版本，其生產版本預計將在 2006 中期推出。
JAX-WS 2.0 成功實現了對 JAX-RPC 1.X 的各種期望，甚至還提供一些額外的功能，如有限的 REST 支持。因為 JAX-WS 2.0 大量使用了 Annotation 和其他 Java 5 特性（這樣就不能使用較舊的 JVM），因而一些開發人員可能會在使用時遇到一些問題，但對於很多開發人員而言，依賴 Java 5 特性將是一大優勢。一個較為突出的顧慮是，JAX-WS 2.0 並不支持 Web 服務配置的 Annotation 的任何後備選項，這樣就可能限制該框架的靈活性和長期優勢。
JAX-WS 2.0 和 JAXB 2.0 都在准備綁定到 J2SE 規范的發布 Java 5 版本中。將這些組件作為標准 JVM 安裝的一部分將無疑增加對開發人員的吸引力，因為這將避免在各個應用程序中包含大量框架的需求。將大量框架包含在標准 JVM 中的缺點在於（除了會增加基本下載大小外），在需要進行錯誤修復時，可能會導致很難進行版本控制，就像已經發生在 JAXP 之類的組件身上的情況一樣（這些組件已經采用了綁定的方式）。
向互操作性進發
JAX-WS 2.0 直接支持 XOP/MTOM，而並不是其他新的 WCF 技術。不過，在 Sun 聲明的與 Microsoft 互操作性承諾中，他們宣布將開發 WCF 中包含的其他技術的 Java 開放源代碼版本。這些開放源代碼實現將作為大型項目“GlassFish”的一部分進行開發，此項目涵蓋了作為 Sun 的應用服務器（包括 JAX-WS 2.0 和 JAXB 2.0 參考實現）的一部分使用的所有技術。
在這些新的開放源代碼項目成形之前，我們需要拭目以待。在 Sun 所公布的時間表中，將在 2006 年中期提供一些可用的東西，因此在本系列的後續文章中將能夠提供更多的詳細信息。
Apache 方法
Apache 項目數年來已在 Web 服務方面進行了大量的工作，其主要精力放在 Java 平台開發上。Apache 當前的 Java SOAP Web 服務生產平台是第三代 Axis 框架。Axis 得到了廣泛的使用，這既包括開發人員下載並直接使用，也包括將其作為 SOAP 引擎嵌入到若干不同的應用服務器中。Axis 通常被認為是使用最廣泛的 Java SOAP Web 服務平台。
不過，Axis 也有一些缺點。首先，它是基於 JAX-RPC 1.0 標准設計的，而後者在很大程度上約束了 Axis 體系結構，限制了其靈活性。隨著為了以 SOAP 處理核心為基礎構建新技術而對擴展的需求的增加，這個有限的靈活性就越來越成問題了。同時，轉向 doc/lit SOAP 服務也帶來了對更好模式支持的需求，對 Axis 代碼而言，這在當時是非常不實際的。到 2004 年中期，Axis 團隊認為需要重新進行編寫工作，要在進行重新編寫工作中應用通過實現 Axis 獲得的經驗，並同時提供更好的靈活性，以便將來進行擴展。
“救世主”Axis2
Axis2 是 Axis 的後續版本。它設計為輕量 SOAP 處理引擎（盡管對於 JAX-WS 2.0，Axis2 也包含一些對 REST 的支持），可以采用很多方式進行擴展。與原來的 Axis 不同，Axis2 並不刻意對實現任何特定 API 進行約束（盡管一些 JAX-WS 2.0 支持級計劃使用 Axis2 核心代碼的包裝）。Axis2 的開發工作已經持續了一年多，不久就將投入生產。
Axis2 最好的特性之一就是為 SOAP 消息使用的 AXIOM 對象模型。XML 對象模型存在的時間幾乎和 XML 本身一樣長，最早的版本是來自 W3C 的 DOM 標准。AXIOM 和其他 XML 對象模型不同的地方在於，它利用新的 XML 解析器提供的靈活性來允許按需構造對象模型。這意味著，只有為實際需要通過模型訪問的 XML 文檔部分構建對象模型才會帶來性能損失。
另一個主要 Axis2 特性是對可插入數據綁定的支持。此特性允許您選擇最簡單的方式來處理 SOAP 文檔的 XML 有效載荷，對生成的代碼進行自定義，以使用所選擇的方法。可能的選擇包括，直接使用 AXIOM，使用與原來的 Axis 相似的簡單數據綁定方法，或使用 XMLBeans、JiBX 或 JAXB 2.0 等專用數據綁定框架。
擴展 Axis2
盡管 Axis2 仍然在開發中，不過已經有了一系列在 Axis2 基礎上實現 SOAP 擴展的項目。這些項目包括 WCF 所支持的所有主要技術以及 Microsoft 計劃在加載項（即獨立計價的）應用程序中的一些擴展。Axis2 的體系結構允許使用一個稱為模塊 的組件方便地開發此類擴展。
WS-Addressing 和 WS-Security 模塊當前包含在基礎 Axis2 分發中（在將來將可能作為獨立部分下載，或者甚至成為獨立的項目，因為這些模塊和核心 Axis2 代碼之間並沒有緊密耦合關系）。WS-ReliableMessaging 支持正在通過 Sandesha 項目開發，而 WS-Trust 和 WS-SecureConversation 正在通過 WSS4J 項目開發（已經提供了 WS-Security 實現）。WS-AtomicTransaction 和 WS-Coordination 正在通過 Kandula 項目進行實現。
小聯盟
除了 Sun 和 Apache 這些著名的組織之外，在開放源代碼開發領域外仍然有一些其他創新 Web 服務項目在進行。其中一個就是我自己的 JibxSoap 項目，該項目是以我的 JiBX XML 數據綁定框架為基礎構建的 SOAP 和 REST 引擎。JibxSoap 的主要優點在於其出眾的速度——在以前的測試中，其使用標准 SOAP 消息的性能幾乎能與 Java RMI 性能匹敵。XFire 是另一個 SOAP 引擎，該引擎允許選擇使用數據綁定框架；XFire 也具有出色的性能結果。JibxSoap 和 XFire 都有可能在下一年投入生產使用。
考慮到開發源代碼開發的速度，無疑將在 2006 年期間出現一些其他的新 Java 框架。即使這些框架不能達到 Sun 和 Apache 那樣的受歡迎程度，但能夠以更簡單（或更快）的方式實現相同的目標，所以仍然具有很大的影響力。
展望
現在，我已經在本文中對 2006 年的 Java Web 服務發展進行了介紹，在後續文章中，我將更詳細地對各個開放源代碼 Java 框架進行討論。下一篇文章中，我們將討論 Axis2，對其體系結構和基礎 AXIOM 對象模型進行分析。我還將討論 AXIOM 中包含的 XOP/MTOM 附件支持以及數據綁定框架如何訪問此附件。以後的文章將討論 Axis2 數據綁定後備選項和性能，以及其他 Java Web 服務框架的詳細信息和性能。敬請關注此系列的每篇新文章，以了解最新的詳細信息。
