我們爲什麼應該使用基於Document風格的SOAP服務？<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
RPC風格的承前啓後性
在上節中，我們介紹了RPC和Document風格Web服務的差別。首先，有人可能要問，對RPC和Document wrapped風格的服務來說，我們畢竟只關心要交換消息及它們的WSDL，而不去管它是RPC還是Document風格，所以從這方面說，這兩種方法差別不大。實際上，它們之間的差別不在於實際操作中，而更在於對概念的理解上面，對我們那些熟悉了數十年”方法調用”的人來說尤其如此。我們總想指望能調用一個方法(有時稱之爲過程或函數等)，傳入幾個參數，有時還需要返回調用結果。在這種情況下，SOAP在開始設計時，其中的Web服務或多或少就是上面模型的擴展，只是讓RPC調用顯得更加標準化而已。實際上，我們前面也曾提到，初始的SOAP規範就是基於RPC風格的。
面向Document的SOAP服務
現在，我們來說明一下面向Document的服務是怎樣從原始的RPC轉移到Document模型上來的？Document是一種全新的編程模型，它會在未來的Web服務開發方面佔據主導地位，雖然，有人對此尚有爭議。
Document與消息類似，它們都可以被髮送或轉發到目的地，然後進行處理。
基於Document編程模型
自包含的Document及異步編程模型
但Document被處理時，我們不應關心這個過程何時發生，但我們必須保證消息中包含了處理過程所需要的所有信息。因此，消息應該是自包含的業務文檔，這是使用異步傳輸協議(比如SOAP支持的SMTP或JMS協議)進行消息傳輸的最基本的前提。這點雖然沒有明文規定，但它不失爲一個非常好的編程實踐。
另外，對工作流系統而言，我們也必須要自包含的業務文檔，這是因爲工作流內部的轉換天生就是異步的。因此，面向Document的編程模型非常適合這種情況。
Document模型的驗證功能
前面我們已經說明，Document風格的一個優點是，它可以使用XML模式對交換的文檔進行驗證。
Document模型的解耦功能
RPC方法的一個主要缺點是強耦合，RPC調用必須依賴於服務器端的軟件架構，一旦服務器端的方法簽名發生改變，這種改變勢必波及整個系統，其結果是客戶端受到影響，從而客戶端不得不進行相應的代碼重構。但Document風格的服務缺克服了這一缺點，因爲消息結構的更改(比如添加一個新屬性)並不影響文檔交換的機制。另外，服務器端修改方法的簽名通常對消息結構沒有影響。因此，Document風格的SOAP服務是鬆耦合的，它易於維護，也易於對軟件進行模塊化處理，因而使得軟件的架構更加健壯和可靠。
Document模型的可交互性
最後，我們需要考慮Web服務的可交互性。互操作性可以使不同的技術和系統協同工作，我們可以通過和標準交換協議兼容，及和業界保持一致就可做到這一點。Document風格的服務獲得業界一致支持，覺得大多數廠家都支持這種風格的服務。實際上，JAX-WS的Java參考實現及大多數其它的Java WS實現(將第6章)及.Net，都採用Document風格作爲其Web服務的缺省實現風格。
Web服務的幾種實現方法 – JAX-WS 2、Axis2、Spring-WS及XFire/CXF2.0
在接下來的Web服務之旅中，我們將介紹一下幾種Web服務的實現方法。因爲到某一時刻，我們總得選擇Web服務的實現方法。如何選擇Web服務的實現方法需要考慮多種因素。在本小節中，我們介紹一下幾種主要的Web服務實現方法及它們的特點。
JAX-WS2
在前面的章節中，我們對JAX-WS已經做過介紹。首先，我們應注意，它是一個JSR規範(JSR-224)而不是一個實現，JAX-WS是JAVA API for XML Web Services的縮寫，意爲XML Web服務的Java編程接口，它繼承自以前的JAX-RPC(Java API for XML-based Remote Procedure Call)規範。
選擇JAX-WS實現Web服務的主要優勢是，Java6標準版和Java5企業版都包含了該規範的參考實現。因此，我們在使用時無需另外下載相關的類庫。如果您採用JAX-WS的獨立發行版本，您可以使用其2.0版本的實現。到本書截稿時爲止，JAX-WS獨立發行版已經升級到2.1。
JAX-WS使用JAXB作爲其數據綁定模型，使用的XML解析引擎爲StAX(Steaming API for XML，基於XML流的編程接口)，StAX是一種基於數據流的拉式解析引擎。這種解析方法只有在客戶端請求時才能得到XML數據，和DOM方法相比，它提高了執行效率。因爲DOM需要解析整個XML文檔，在內存中生成這個的對象樹。StAX不僅對內存要求較低，而且它還可以使XML的解析過程開始較早。
JAX-WS既支持SOAP協議，也支持REST交換協議。雖然它不能自動生成生成REST風格服務的代碼(和SOAP/WSDL方法相比)，這是因爲REST風格的Web服務的描述標準目前尚未定義。
JAX-WS服務的實現在很大程度上依賴於Java語的註解功能，並支持SMTP、JMS及HTTP等網絡傳輸協議。而且，使用JAX-WS開發出來的Web服務具有很多特點，它可支持WS-Security(Web服務安全)、WS-Atomic Transaction(Web服務原子交易)及WS-ReliableMessaging(Web服務可靠消息傳輸)等功能。最後， JAX-WS還可支持有狀態的Web服務。
Axis2
Axis2是Apache Web服務項目中的一個工具，Apache Web項目由一套項目組成，覆蓋了從Web服務開發到使用的諸多方面，實現了相關的協議和規範。Axis2是對以前的Axis1.X版本的完全重構，它有兩套不同的實現，即Axis2/Java和Axis2/C這兩種實現方式。
在以前的版本中使用的基於事件的SAX XML解析器，已經被“拉式”的StAX XML解析器所替代，這樣就能更好地控制文檔的處理過程，其效率更高，性能更優。Axis2其實是使用AXIOM(AXIs Object Model，AXIs對象模型)來對XML進行處理，該模型是一個輕量級的對象模型，它以StAX爲基礎，並增加了許多新功能。
Axis2既可用來開發基於SOAP的Web服務，也可以用來開發REST風格的服務，同時，它還支持異步非阻塞式的Web服務調用，異步調用是通過回調機制實現的。Axis在設計過程中使用了模塊化和可擴展的架構，SOAP消息的發送和接受是通過兩個“管道”(或“流”) – 即 流入管道和流出管道 – 實現的。每個管道在處理XML消息時，可以分爲幾個階段，而每個 處理階段又可有一些可插拔的“處理器”。因此，其整體架構具有高度可擴展性，實際上，除了Axis2自帶的XML處理階段外，用戶可以選擇添加自定義的XML處理階段，並在其中加入用戶自定義的處理器。這樣，就可以執行新的處理過程，或者覆蓋原有的處理過程。
另外，處理器可以組裝在一起，形成模塊。每個模塊 定義了一套處理器及相應的處理階段規則的描述，每個處理器不僅不僅表明它所在的處理階段，而且還可通過階段規則描述表明它在整個處理過程各種的執行順序。在Axis2語言中，當一個模塊裝入系統後，該模塊雖然沒有激活，但它已經處於可訪問(available)的狀態；但該模塊激活後，它就轉變爲待命(engaged)狀態，此時，其中的處理器就可安放到某一階段並執行。因此，我們可以非常容易地出入新的模塊，來處理和Web服務相關的規範，比如Web服務安全規範(Apache Rampart模塊)或者Web服務原子交易規範(Apache Kandula2模塊)。
XML數據綁定並不是Axis2的核心部分，在Axis2中，數據綁定是通過擴展機制實現的，我們可以選擇ABD（Axis Data Biding)、XML Bens、JAX-Me和JibX等技術來實現Axis2的數據綁定。而且，Axis2可支持多種傳輸協議(如HTTP、TCP、SMTP和JMS等)。
Axis2的缺省安裝過程爲：將一個WAR文件包部署到應用服務器即可，對Axis2推薦的Tocmcat服務器而言，我們只需要把這個WAR文件拷貝到CATALINA_HOME/webapps目錄即可完成安裝。當我們把這個名叫axis2的Web應用部署到應用服務器後，它就是Axis2的管理平臺，您可以通過它增加和配置Web服務和模塊。
請您注意，Axis2中配置的服務、模塊、階段及處理器對其它的Web應用是獨立的，這也就是說，如果您有多個Web應用，每個應用都有其特定的義務邏輯，此時，您不需要把服務部署到其中的一個Web應用中，您只需要將Web服務部署到axis2這個Web應用即可。這樣，每個服務消費者(客戶端或另一個Web應用)都可以調用該服務。
但是，Axis2管理平臺上所作的配置不能被保存，因此，重啓axis2 Web應用後，您所有的配置將丟失。針對這種情況，您需要手動編輯axis2的配置文件。
另外，您可以選擇安裝Axis2的“標準二進制分發軟件包”，它不但包括Axis2必須的Jar文件，而且還包括一下命令行工具：
(1) wsdl2java工具可以從WSDL生成Java代碼，而java2wsdl工具可以根據Java代碼生成WSDL描述；
(2) axis2server工具可以啓動一個簡單的獨立運行的服務器，您可以在其中部署Web服務；
(3) axis2工具將啓動一個Java應用程序，該應用將自動加載Axis2所有必須的類庫。
Spring-WS
Spirng框架無疑是當今Java開發領域較受歡迎的產品之一，它對軟件項目的設計方法來說不啻於是一場革命，它使用面向方面的思想，引入了“控制反轉(IoC)”或者稱之爲“依賴注入”的概念，這樣，我們就更容易搭建一個J2EE應用，同時我們的應用也會更簡潔。但Spring遠不只是一個簡單的IoC容器，它提供了許多現成的模式和模板，同時，它和其它的框架和工具進行了很好的集成，在靈活性、模塊化及軟件的魯棒性方面都有所提高。
Spring社區在Web服務領域也作出了自己的貢獻，它推出了“Spring Web服務”的產品，該產品也稱作“Spring-WS”。
採用Spring框架的一個優勢是，它和Spring的概念和模式一脈相承，您馬上就可以重用以前您解決問題的那些經驗。比如，服務契約(或接口)和其實現之間的鬆耦合就是選擇Spring的第一個好處。
主流的Web服務開發方法教導我們，應先設計服務的WSDL(從契約開始設計)，而不是先從Java編碼開始。Spring對這種方法更進一步，它要求設計者先從消息的XML模式(XSD)開始，然後從XSD自動產生WSDL。
在Spring-WS中，XML的處理過程是可配置的，您既可以選擇使用基於DOM的處理類庫(比如W3C DOM、JDOM、dom4J、XOM等)，也可以使用SAX、StAX或XPath 等，而XML綁定庫，您可以在JAXB、Castor、XMLBeans、JiBX和XStream之間進行選擇。
Spring-WS提供了強大而靈活的消息分發器，它能處理XML消息的分發，在消息驗證、數字簽名、加解密等Web服務安全方面，它也非常出色。
XFire/CXF
XFire旨在提高Axis1.x的性能而設計的，Axis1.x是當時Web服務的事實標準。XFire使用了基於StAX的快速對象模型對XML進行操作。XFire簡單易用，它支持JAXB、Castor和XML Beans等XML綁定庫，其缺省的XML綁定庫爲Aegis綁定，這是一種快速XML綁定機制，對內存要求較低。
XFire和Spring、PicoContainer(另一種依賴反轉的容器)有很好的集成，而且，它還有一套易用的客戶端API，用於創建客戶端應用及開發單元測試。XFire支持的傳輸協議有：HTTP、JMS和Jabber/XMPP等。
最近，XFire和另一個Web服務框架Celtix進行了合併，形成了一個新的產品CXF2.0，它應算是對XFire1.x的延續。CXF2.0這個新產品將在性能和易用性方面有進一步的提高。
CXF支持除SOAP之外的許多協議，比如REST(通過Java註解)和CORBA。它也支持諸多標準和Web服務規範。另外，它還可以嵌入到其它程序中。但是，它強調開發Web服務先從Java代碼開始，而不是先從契約開始。
小結
在本章中，我們介紹了SOA方法學和Web服務實現的基礎知識，及它們二者之間的關係。我們看到，XML作爲一種通用語言，可以解除Web服務及服務的消費者之間的耦合。我們從基礎的XML-over-HTTP方法開始，介紹了REST和SOAP方法。針對他們的複雜度和靈活性，我們講解了Web服務的實現細節。而且，我們還針對SOAP協議，講述了RPC風格和Document實現風格之間的差別，指出了爲什麼Document風格要優於RPC風格。實際上，Document風格的SOAP服務是主流Web服務實現框架的缺省風格。