什么是 Web 服務？

首先，讓我們從總體上了解一下什么是 Web 服務，以及它們為何對軟件開發重要。

究竟為什么重要呢？

如果您沒有聽說過有關面向服務的體系結構 (SOA) 和 Web 服務的大量信息，您就不會閱讀本文，那么問題就應該是，為什么此內容這樣重要？答案是，此內容之所以重要，是因為這是應用程序彼此進行通信的方式的典型變化。SOAs 已經存在很長很長時間了。SOA 最初主要由中間件應用程序組成，至少進行連接的兩端都屬于同一種類型的中間件。另一方面，Web 服務由一組標準組成，用于在不需要特定類型的中間件、編程語言甚至操作系統的前提下讓各種不同的系統進行通信。接下來，讓我們了解一下其發展的歷程。

回頁首

傳統應用程序

首先從計算機發明開始，當時給人感覺非常不錯。計算機能執行奇跡般的任務，可實現很多手動工作的自動化，包括復雜的計算、財務工作等等很多其他任務。

但傳統應用程序是“豎井”(Silo) 型的。人力資源應用程序無法與財務應用程序真正通信，而后者又無法和分布應用程序進行真正的通信。所有這些應用程序都有獨立的領域，在獨立的計算機上運行，盡管很有用，但并不能很好地在彼此間共享數據。當時可以選擇對批處理流程進行連接，以將數據從一個系統移動到另一個系統，但這并不適合進行實時集成。

回頁首

分布式計算

在我們的進化鏈中的第二步是分布式計算。分布式計算允許不同的應用程序彼此進行通信（即使位于不同的計算機上也是如此）。CORBA、MTS 和 Enterprise Java Bean (EJB) 等技術提供了包含各種類別的注冊中心的系統，因此應用程序可以找到其希望與之進行交互的組件，然后像調用本地的組件一樣調用這些組件。

這些系統由可同時滿足這兩個要求的中間件（或更具體一些，面向消息的中間件）提供支持?，F在能以特定的方式構建應用程序，即使位于不同的地理位置，也能訪問其他系統上的資源。

但仍然有一個問題。雖然系統可以自由地與系統內的任何對象進行通信，但仍然是一個封閉的系統。至少，客戶機應用程序必須與服務器應用程序使用相同的技術。另外，通常并不會將系統設計為從創建其的個體組織外進行訪問。

回頁首

Web 服務

此進化鏈中下一個幾乎不可避免的鏈接點就是 Web 服務?！癢eb 服務”基于 XML 和 HTTP（大多數情況下），對很多人具有不同的含義，但在此處，我們要將 Web 服務作為系統間基于 SOAP 的消息交換進行討論。

這些消息由 XML 組成（XML 是一個基于文本的開放標準），可由來自任何應用程序（任何設計為接收此類消息的應用程序）的任何人進行訪問。這就擴展了應用程序的范圍，從而包含任何可通過網絡對其進行訪問的任何人。（如果這讓您開始考慮安全問題，不要緊，您將在本系列的第 4 部分了解如何處理這方面的問題。）

基于 SOAP 的 Web 服務將要發送與清單 1 中所示類似的 XML 消息。

                    
<SOAPenv:Envelope 
       xmlns:SOAPenv="http://schemas.xmlSOAP.org/SOAP/envelope/" 
       xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <SOAPenv:Body>
  <req:getNumberOfArticles xmlns:req="http://daily-moon.com/CMS/">
     <req:category>classifieds</req:category>
  </req:getNumberOfArticles>
 </SOAPenv:Body>
</SOAPenv:Envelope>

這些消息將從一個系統進入另一個系統（通常通過 HTTP）。接收系統對消息進行解釋，進行應該進行從處理，然后發送另一個 SOAP 消息作為響應。

這個系統很簡單，正因為如此，有很多企業級計算方面的內容都尚未涉及。幸運的是，其中的很多方面已被納入考慮范疇，且具有自己的相關規范來確定此事務應如何進行，以包含傳統的面向消息的中間件的很多安全和其他方面的內容。

回頁首

其他類型的 Web 服務

如果我沒有說明 SOAP 并不是唯一的處理 Web 服務的方法，那就有些失職了。有很多其他基于 XML 的方法用于在系統間發送信息，其中一些適用于企業環境，而另一些則不適合此用途。例如，Amazon 是為公眾提供對其系統的 Web 服務訪問的第一批基于 Web 服務的公司之一。Amazon 包含了一個基于 SOAP 的服務，但也提供了一個基于 Representational State Transfer (REST) 的服務。

REST 是一種 Web 服務類型，其中，用戶直接訪問 URL，相應的響應是與清單 2 中所示類似的簡單 XML 文檔。

                    
<currentArticles>
   <category>classifieds</category>
   <subcategory>forsale</subcategory>
   <article id="888204">
       <articleHeadline></articleHeadline>
       <articleText>30 ft ladder, only used once.  Willing to let
go for half it's worth. Has slight dent near the middle.  
Harder than a human head. $150 OBO.</articleText>
    </article>
   <article id="888242">
       <articleHeadline></articleHeadline>
       <articleText>Vintage 1963 T-Bird.  Less than 300 miles.  
Driven by my daughter until I took it away.  Serious inquires only.
555-3264 after 7 PM.</articleText>
    </article>
</currentArticles>

這些消息并沒有特定的格式?？梢詾槿魏螖祿?/p>

另一種 Web 服務類型要使用 XML-RPC 之類的標準。在這種情況下，命令將通過與清單 3 中所示類似的 XML 發送到系統。

                    
<?xml version="1.0"?>
<methodCall>
   <methodName>CMS.getNumberOfArticles</methodName>
   <params>
      <param>
         <value><string>classifieds</string></value>
      </param>
      <param>
         <value><string>forsale</string></value>
      </param>
   </params>
</methodCall>

其響應將采用類似的格式。

在學習使用 SOAP 的過程中，您可以會打心底里認為 REST 和 XML-RPC 比基于 SOAP 的系統要簡單得多。的確如此。在某些情況下 REST 和 XML-RPC 比 SOAP 系統簡單。不過，我們討論的不是在網站上顯示天氣的簡單應用程序。我們此處討論的是企業級應用程序，而企業級的應用程序需要企業級的屬性，如安全、互操作性等等。這些功能在有關基于 SOAP 的 Web 服務的其他規范中進行了定義，因而，從長期來看，SOAP 更適合用于企業級應用程序。

讓我們了解一下這些規范。

回頁首

基本 Web 服務規范

Web 服務規范通常歸為兩類：基本 Web 服務規范和擴展 Web 服務規范。基本規范有：

• SOAP：SOAP 規范是所有基于 SOAP 的 Web 服務的基礎，詳細說明了實際消息的格式。其中還詳細說明了應用程序應如何對待消息的特定方面（如“Header”中的元素），從而可以創建特定類型的應用程序，使其中的消息在達到最終的目的地前在多個中間層之間進行傳遞。本教程將涵蓋 SOAP 規范的內容。
• WDSL：Web 服務描述語言是詳細說明描述基于 SOAP 的 Web 服務的標準方式的規范，包括消息應采用的形式以及應將其發送到何處。其中還詳細說明了此類消息的響應。當與相應的工具結合使用時，WSDL 允許以編程方式創建對 Web 服務的調用，甚至不用知道所查找的 Web 服務是什么；應用程序可以從 WSDL 文件中提取這些詳細信息，并提供要使用的編程接口。我們將在本系列的第 2 部分討論 WSDL。
• UDDI：統一描述、發現和集成 (Universal Description, Discovery and Integration) 是一項從最初提出后發生了一系列變化的標準。其最初的目的是為了給各個公司提供在全球注冊中心中注冊服務并在此注冊中心中搜索可能想使用的服務的機制。不過，由于很多公司對于將其系統對外開放的問題上都相當保守，這個目標并沒有完全實現。但是，很多公司已將 UDDI 作為內部的服務及服務信息注冊中心使用，本系列第 3 部分將對其使用進行詳細論述。

以上是一些基礎知識。另外差不多還有數十種擴展標準，可進一步擴展基于 SOAP 的服務的用途。

回頁首

擴展 Web 服務規范

總共有數十種 WS-* 規范，其中幾種對企業尤為有用。即：

• WS-Security：此規范處理加密和數字簽名，允許創建特定類型的應用程序，以防止竊聽消息，且能實現不可否認功能。本系列的第 4 部分將討論 WS-Security。
• WS-Policy：此規范對 WS-Security 進行了擴展，允許更具體地說明誰可以采用何種方式使用服務。本系列的第 5 部分將討論 WS-Policy。
• WS-I：盡管 Web 服務應設計成具有互操作性，但在實際中，各個規范對不同實現的解釋的靈活性常常足以導致出現問題。WS-I 提供了一組可用于防止出現各種問題的標準和實踐，并提供了標準化測試來檢查問題。WS-I 是本系列的第 6 部分將要討論的主題。
• WS-BPEL：單個服務很好處理，但應用程序在大多數情況下則較難處理。企業級計算要求至少將多個服務組合為一個完整的系統，而 WS-BPEL 提供了用于指定創建此類系統所必需的交互（如分支和并發處理）。本系列的第 7 部分將討論 WS-BPEL。

在 Web 服務中扮演重要角色的其他規范將不在本系列中討論，其中包括 WS-ReliableMessaging（允許確定檢索一個且僅一個消息副本）、Web 服務資源框架 (WSRF)（允許使用在無狀態環境中非常重要的狀態）和 Web 服務分布式管理 (WSDM)（討論 Web 服務的管理和使用問題）?？梢栽诒窘坛痰?a >參考資料中獲得有關這些規范及其他規范的更多信息。

回頁首

將要完成的工作

在本教程中，您將了解 Daily Moon 報社的 Classifieds Department 如何將其自己的系統與內容管理系統使用的基于 Web 服務的接口進行集成。將創建一個應用程序，以創建基于 SOAP 的消息，將其發送到服務，然后檢索響應。完成了此工作后，您將了解如何創建服務來響應請求并發送自己的響應。將通過創建 Java 應用程序（使用或不使用應用服務器）來完成此工作。

回頁首

設置

現在已經了解了所涉及的基本原理，接下來讓我們看看如何實際創建應用程序。首先要使所需軟件就緒。

設置 Apache Geronimo

將需要的第一個軟件是 Web 應用服務器。為什么需要 Web 應用服務器呢？因為您會發現，沒有 Web 應用服務器很難提供 Web 服務。Web 應用服務器將偵聽請求，將這些請求轉換為實際服務可以理解的內容，然后進行任何必要的處理。

此過程中幾乎可以使用任何 Web 服務器，但在大多數情況下都將使用能簡化此過程的軟件（通常要求使用某種類型的實際應用服務器）。具體來說，本教程假定您將使用 Java 應用服務器。（實際上，將使用 J2EE 應用服務器。）

對于 J2EE 服務器，有很多選擇；在本例中將使用 Apache Geronimo。Geronimo 是作為 IBM WebSphere Application Server Community Edition 基礎的開放源代碼應用服務器。Geronimo 很小，非常易于安裝和管理。它還能與其他 Apache 項目（如稍后將安裝的 Axis2）一起良好地工作。

請下載相關軟件（請參閱先決條件）并將文件提取到目標目錄中。您會發現所提取的文件中包含自身的目錄，因此可以直接對其進行解包，并可將其移動到任何位置。任何目錄都是可接受的，但要避免名稱中包含空格的目錄，如“Program Files”、“Documents and Settings”或其子目錄。例如，本教程的測試安裝使用的是 e:\geronimo-1.0。

就是這里。已經在其中安裝了 Geronimo。這不是很簡單么？

要啟動此服務器，請打開命令提示符窗口，并執行以下命令：

要確保服務器正在運行，請打開瀏覽器，并指向清單 4 中所示的 URL：

                    
http://localhost:8080  

應該看到與圖 1 中所示類似的頁面。

現在讓我們開始安裝 Web 服務軟件。

回頁首

安裝 Apache Axis2

完全可能從普通 HTTP 服務器提供 Web 服務。不過，這樣并不明智。處理 SOAP 消息需要進行很多工作，但沒有必要完全從頭進行所有工作。Apache Axis 項目幾年前就對此任務進行了簡化，創建了可方便地創建和處理 Web 服務的環境。該軟件包含了多個應用程序，可幫助從普通項目創建 Web 服務，從 Web 服務創建 Java 對象，并對二者進行處理。Apache 小組已推出了 Axis 的新版本 Axis2，該版本繼承了 Axis 上的所有已有功能，并通過更改體系結構實現了更大的靈活性，從而將其推向了一個新的高度。這很重要，因為 Web 服務規范隨時都在增加。Axis2 的構造允許它更方便與 WSS4J、Apache 的 WS-Security 實現等項目集成。由于我們將在以后使用這些項目，因此請現在安裝 Axis2（有關下載信息，請參閱先決條件）。

請確保同時下載 Binary Distribution 和 War Distribution。前者將幫助構建客戶機，而后者用于幫助構建服務。

要將 Axis2 安裝到 Web 服務器中，請將 axis2.war 文件復制到 Geronimo 的 deploy 目錄。（您將需要確保已經至少啟動過 Geronimo 一次，才能保證存在此目錄。）Geronimo 將自動檢測其是否存在，因此不必手動部署任何內容。

回頁首

驗證 Axis 的安裝

要確保已經恰當安裝了所有內容，請將瀏覽器指向 http://localhost:8080/axis2/index.jsp 并單擊 Validate。

應該看到與圖 2 中所示類似的頁面。

在繼續本教程的其他內容前，請確保成功安裝了 Axis。

回頁首

安裝示例服務

將要編寫的第一個應用程序是客戶機，因此將需要其可訪問的服務。幸運的是，Axis2 分發版提供了若干此類服務。首先，將按照以下所示安裝 MyService 服務：

1. 通過將瀏覽器指向 http://localhost:8080/axis2/Login.jsp 并登錄，從而通過身份驗證。缺省用戶名和密碼分別為 admin 和 Axis2。
2. 單擊 Upload service>Browse。
3. 導航到 MyService.aar 文件。可以在標準 Axis2 分發版的 samples\userguide 目錄下找到該文件。單擊 OK。
4. 單擊 Upload。

應該看到一個通知，指示服務已添加（請參閱圖 3）。在缺省情況下，Axis2 包含“熱部署”功能，因此不必進行任何操作來激活。

現在，讓我們了解一下將要構建的內容。

回頁首