Web Services 快速指南

什麼是 Web Services？

不同的書籍和不同的組織對 Web Services 給出了不同的定義。這裡列出了一些。

Web 服務是指任何可透過網際網路訪問並使用標準化 XML 訊息系統的軟體。XML 用於編碼傳送到 Web 服務的所有通訊。例如，客戶端透過傳送 XML 訊息來呼叫 Web 服務，然後等待相應的 XML 響應。由於所有通訊都採用 XML 格式，因此 Web 服務不受任何特定作業系統或程式語言的限制——Java 可以與 Perl 通訊；Windows 應用程式可以與 Unix 應用程式通訊。
Web 服務是自包含的、模組化的、分散式的、動態的應用程式，可以透過網路對其進行描述、釋出、定位或呼叫，以建立產品、流程和供應鏈。這些應用程式可以是本地、分散式或基於 Web 的。Web 服務構建在 TCP/IP、HTTP、Java、HTML 和 XML 等開放標準之上。
Web 服務是基於 XML 的資訊交換系統，使用網際網路進行直接的應用程式到應用程式互動。這些系統可以包括程式、物件、訊息或文件。
Web 服務是一組用於在應用程式或系統之間交換資料的開放協議和標準的集合。用各種程式語言編寫並在各種平臺上執行的軟體應用程式可以使用 Web 服務透過計算機網路（如網際網路）交換資料，其方式類似於單個計算機上的程序間通訊。這種互操作性（例如，Java 和 Python 之間，或 Windows 和 Linux 應用程式之間）是由於使用了開放標準。

總之，完整的 Web 服務因此是任何滿足以下條件的服務：

可透過網際網路或私有（內聯網）網路訪問
使用標準化的 XML 訊息系統
不受任何特定作業系統或程式語言的限制
透過通用的 XML 語法進行自描述
可以透過簡單的查詢機制進行發現

Web Services 的元件

基本的 Web Services 平臺是 XML + HTTP。所有標準的 Web Services 都使用以下元件：

SOAP（簡單物件訪問協議）
UDDI（通用描述、發現和整合）
WSDL（Web Services 描述語言）

所有這些元件都在Web Services 架構章節中進行了討論。

Web 服務是如何工作的？

Web 服務透過使用 HTML、XML、WSDL 和 SOAP 等開放標準來實現各種應用程式之間的通訊。Web 服務藉助以下技術：

XML 對資料進行標記
SOAP 傳輸訊息
WSDL 描述服務的可用性。

您可以在 Solaris 上構建一個基於 Java 的 Web 服務，該服務可從執行在 Windows 上的 Visual Basic 程式訪問。

您還可以使用 C# 在 Windows 上構建新的 Web 服務，這些服務可以從基於 JavaServer Pages (JSP) 並執行在 Linux 上的 Web 應用程式呼叫。

示例

考慮一個簡單的賬戶管理和訂單處理系統。會計人員使用用 Visual Basic 或 JSP 構建的客戶端應用程式來建立新賬戶並輸入新的客戶訂單。

此係統的處理邏輯是用 Java 編寫的，並駐留在 Solaris 機器上，該機器還與資料庫互動以儲存資訊。

執行此操作的步驟如下：

客戶端程式將賬戶註冊資訊捆綁到 SOAP 訊息中。
此 SOAP 訊息作為 HTTP POST 請求的主體傳送到 Web 服務。
Web 服務解包 SOAP 請求並將其轉換為應用程式可以理解的命令。
應用程式根據需要處理資訊，並響應該客戶的新唯一賬戶號碼。
接下來，Web 服務將響應打包到另一個 SOAP 訊息中，並將其傳送回客戶端程式以響應其 HTTP 請求。
客戶端程式解包 SOAP 訊息以獲取賬戶註冊過程的結果。

為什麼使用 Web Services？

以下是使用 Web Services 的好處：

在網路上公開現有功能

Web 服務是可使用 HTTP 遠端呼叫的託管程式碼單元。也就是說，它可以使用 HTTP 請求啟用。Web 服務允許您在網路上公開現有程式碼的功能。一旦在網路上公開，其他應用程式就可以使用程式的功能。

互操作性

Web 服務允許各種應用程式相互通訊並在彼此之間共享資料和服務。其他應用程式也可以使用 Web 服務。例如，VB 或 .NET 應用程式可以與 Java Web 服務通訊，反之亦然。Web 服務用於使應用程式平臺和技術獨立。

標準化協議

Web 服務使用標準化的行業標準協議進行通訊。所有四個層（服務傳輸、XML 訊息傳遞、服務描述和服務發現層）在 Web 服務協議棧中使用定義良好的協議。協議棧的這種標準化給企業帶來了許多優勢，例如廣泛的選擇範圍、由於競爭而降低的成本以及質量的提高。

低成本通訊

Web 服務使用 HTTP 上的 SOAP 協議，因此您可以使用現有的低成本網際網路來實現 Web 服務。與 EDI/B2B 等專有解決方案相比，此解決方案的成本要低得多。除了 HTTP 上的 SOAP 之外，Web 服務還可以實現到其他可靠的傳輸機制（如 FTP）上。

Web Services - 特性

Web Services 具有以下特殊行為特徵：

基於 XML

Web Services 在資料表示和資料傳輸層使用 XML。使用 XML 消除了任何網路、作業系統或平臺繫結。基於 Web Services 的應用程式在其核心級別具有高度的互操作性。

松耦合

Web 服務的使用者不會直接繫結到該 Web 服務。Web 服務介面可以隨著時間的推移而更改，而不會影響客戶端與服務互動的能力。緊耦合系統意味著客戶端和伺服器邏輯緊密地繫結在一起，這意味著如果一個介面發生更改，則必須更新另一個介面。採用松耦合架構往往使軟體系統更易於管理，並允許不同系統之間進行更簡單的整合。

粗粒度

Java 等面嚮物件的技術透過單獨的方法公開其服務。單個方法對於在企業級提供任何有用的功能來說粒度太細了。從頭開始構建 Java 程式需要建立幾個細粒度方法，然後將這些方法組合成粗粒度服務，供客戶端或其他服務使用。

企業及其公開的介面應該具有粗粒度。Web Services 技術提供了一種定義粗粒度服務的自然方法，這些服務可以訪問適當數量的業務邏輯。

能夠同步或非同步

同步性是指客戶端與服務執行的繫結。在同步呼叫中，客戶端會阻塞並等待服務完成其操作後再繼續。非同步操作允許客戶端呼叫服務，然後執行其他功能。

非同步客戶端在稍後的時間點檢索其結果，而同步客戶端在服務完成時接收其結果。非同步能力是實現松耦合系統的關鍵因素。

支援遠端過程呼叫 (RPC)

Web 服務允許客戶端使用基於 XML 的協議呼叫遠端物件上的過程、函式和方法。遠端過程公開 Web 服務必須支援的輸入和輸出引數。

在過去的幾年裡，透過 Enterprise JavaBeans (EJB) 和 .NET 元件進行元件開發已日益成為架構和企業部署的一部分。這兩種技術都是分散式的，並且可以透過各種 RPC 機制訪問。

Web 服務透過提供自己的服務（等效於傳統元件的服務）或將傳入呼叫轉換為對 EJB 或 .NET 元件的呼叫來支援 RPC。

支援文件交換

XML 的主要優勢之一是它以通用方式表示資料和複雜文件。這些文件可以像表示當前地址一樣簡單，也可以像表示整本書或報價請求 (RFQ) 一樣複雜。Web 服務支援文件的透明交換，以促進業務整合。

Web Services - 架構

有兩種方法可以檢視 Web 服務架構：

第一種方法是檢查每個 Web 服務參與者的個體角色。
第二種方法是檢查新興的 Web 服務協議棧。

Web 服務角色

Web 服務架構中有三個主要角色：

服務提供者

這是 Web 服務的提供者。服務提供者實現服務並在網際網路上提供服務。

服務請求者

這是任何 Web 服務的使用者。請求者透過開啟網路連線併發送 XML 請求來利用現有的 Web 服務。

服務登錄檔

這是一個邏輯上的服務集中目錄。登錄檔提供了一箇中心位置，開發人員可以在其中釋出新服務或查詢現有服務。因此，它充當公司及其服務的集中資訊交換中心。

Web 服務協議棧

檢視 Web 服務架構的第二個選擇是檢查新興的 Web 服務協議棧。該棧仍在發展，但目前有四個主要層。

服務傳輸

此層負責在應用程式之間傳輸訊息。目前，此層包括超文字傳輸協議 (HTTP)、簡單郵件傳輸協議 (SMTP)、檔案傳輸協議 (FTP) 以及更新的協議，如塊可擴充套件交換協議 (BEEP)。

XML 訊息傳遞

此層負責以通用的 XML 格式編碼訊息，以便雙方都能理解訊息。目前，此層包括 XML-RPC 和 SOAP。

服務描述

此層負責描述特定 Web 服務的公共介面。目前，服務描述透過 Web 服務描述語言 (WSDL) 處理。

服務發現

此層負責將服務集中到一個公共登錄檔中，並提供簡單的釋出/查詢功能。目前，服務發現透過通用描述、發現和整合 (UDDI) 處理。

隨著 Web 服務的發展，可能會新增其他層，並且可能會向每個層新增其他技術。

下一章解釋 Web Services 的元件。

關於服務傳輸的一些話

Web 服務協議棧的底部是服務傳輸。此層負責在兩臺計算機之間實際傳輸 XML 訊息。

超文字傳輸協議 (HTTP)

目前，HTTP 是最流行的服務傳輸選項。HTTP 簡單、穩定且部署廣泛。此外，大多數防火牆都允許 HTTP 流量。這使得 XMLRPC 或 SOAP 訊息能夠偽裝成 HTTP 訊息。如果您想整合遠端應用程式，這很好，但它確實引發了一些安全問題。

塊可擴充套件交換協議 (BEEP)

這是 HTTP 的一個很有希望的替代方案。BEEP 是一個用於構建新協議的新型網際網路工程任務組 (IETF) 框架。BEEP 直接構建在 TCP 之上，幷包含許多內建功能，包括初始握手協議、身份驗證、安全性和錯誤處理。使用 BEEP，可以為各種應用程式建立新的協議，包括即時訊息、檔案傳輸、內容聯合和網路管理。

SOAP 不與任何特定的傳輸協議繫結。事實上，您可以透過 HTTP、SMTP 或 FTP 使用 SOAP。因此，一個有希望的想法是透過 BEEP 使用 SOAP。

Web Services - 元件

在過去的幾年裡，三種主要技術已成為全球標準，構成了當今 Web 服務技術的核心。下面將討論這些技術。

XML-RPC

這是用於在計算機之間交換資訊的、最簡單的基於 XML 的協議。

XML-RPC 是一種簡單的協議，它使用 XML 訊息執行 RPC。
請求以 XML 編碼並透過 HTTP POST 傳送。
XML 響應嵌入在 HTTP 響應的主體中。
XML-RPC 是平臺無關的。
XML-RPC 允許各種應用程式進行通訊。
Java 客戶端可以與 Perl 伺服器進行 XML-RPC 通訊。
XML-RPC 是開始使用 Web 服務的最簡單方法。

要了解有關 XML-RPC 的更多資訊，請訪問我們的 XML-RPC 教程。

SOAP

SOAP 是一種用於在計算機之間交換資訊的、基於 XML 的協議。

SOAP 是一種通訊協議。
SOAP 用於應用程式之間的通訊。
SOAP 是一種傳送訊息的格式。
SOAP 旨在透過網際網路進行通訊。
SOAP 是平臺無關的。
SOAP 是語言無關的。
SOAP 簡單且可擴充套件。
SOAP 允許您繞過防火牆。
SOAP 將作為 W3C 標準開發。

要了解有關 SOAP 的更多資訊，請訪問我們的 SOAP 教程。

WSDL

WSDL 是一種基於 XML 的語言，用於描述 Web 服務以及如何訪問它們。

WSDL 代表 Web 服務描述語言。
WSDL 由微軟和 IBM 聯合開發。
WSDL 是一種基於 XML 的協議，用於在分散和分散式環境中交換資訊。
WSDL 是描述 Web 服務的標準格式。
WSDL 定義描述瞭如何訪問 Web 服務以及它將執行哪些操作。
WSDL 是一種用於描述如何與基於 XML 的服務互動的語言。
WSDL 是 UDDI（一種基於 XML 的全球業務登錄檔）的組成部分。
WSDL 是 UDDI 使用的語言。
WSDL 發音為“wiz-dull”，拼寫為“W-S-D-L”。

要了解有關 WSDL 的更多資訊，請訪問我們的 WSDL 教程。

UDDI

UDDI 是一種基於 XML 的標準，用於描述、釋出和查詢 Web 服務。

UDDI 代表通用描述、發現和整合。
UDDI 是 Web 服務分散式登錄檔的規範。
UDDI 是平臺無關的開放框架。
UDDI 可以透過 SOAP、CORBA 和 Java RMI 協議進行通訊。
UDDI 使用 WSDL 來描述 Web 服務的介面。
UDDI 與 SOAP 和 WSDL 一起被視為 Web 服務的三大基礎標準之一。
UDDI 是一項開放的行業計劃，使企業能夠彼此發現並定義如何在網際網路上進行互動。

要了解有關 UDDI 的更多資訊，請訪問我們的 UDDI 教程。

Web Services - 示例

基於 Web 服務架構，我們建立以下兩個元件作為 Web 服務實現的一部分：

服務提供者或釋出者

這是 Web 服務的提供者。服務提供者實現服務並使其在 Internet 或 Intranet 上可用。

我們將使用 .NET SDK 編寫和釋出一個簡單的 Web 服務。

服務請求者或消費者

這是任何 Web 服務的使用者。請求者透過開啟網路連線併發送 XML 請求來利用現有的 Web 服務。

我們還將編寫兩個 Web 服務請求者：一個基於 Web 的消費者（ASP.NET 應用程式）和另一個基於 Windows 應用程式的消費者。

下面是我們的第一個 Web 服務示例，它充當服務提供者並公開兩個方法（add 和 SayHello）作為 Web 服務供應用程式使用。這是 Web 服務的標準模板。.NET Web 服務使用 .asmx 副檔名。請注意，公開為 Web 服務的方法具有 WebMethod 屬性。將此檔案儲存為 IIS 虛擬目錄中的 FirstService.asmx（如配置 IIS 中所述；例如，c:\MyWebSerces）。

FirstService.asmx
<%@ WebService language = "C#" class = "FirstService" %>

using System;
using System.Web.Services;
using System.Xml.Serialization;

[WebService(Namespace = "https:///MyWebServices/")]
public class FirstService : WebService{
   [WebMethod]
   public int Add(int a, int b) {
      return a + b;
   }

   [WebMethod]
   public String SayHello() {
      return "Hello World";
   }
}

要測試 Web 服務，必須釋出它。Web 服務可以釋出在 Intranet 或 Internet 上。我們將在此本地計算機上執行的 IIS 上釋出此 Web 服務。讓我們從配置 IIS 開始。

開啟“開始”→“設定”→“控制面板”→“管理工具”→“Internet 資訊服務管理器”。
展開並右鍵單擊預設網站；選擇“新建”→“虛擬目錄”。將開啟“虛擬目錄建立嚮導”。單擊“下一步”。
將開啟“虛擬目錄別名”螢幕。鍵入虛擬目錄名稱。例如，MyWebServices。單擊“下一步”。
將開啟“網站內容目錄”螢幕。
輸入虛擬目錄的目錄路徑名稱。例如，c:\MyWebServices。單擊“下一步”。
將開啟“訪問許可權”螢幕。根據您的需要更改設定。對於此練習，讓我們保留預設設定。
單擊“下一步”按鈕。它將完成 IIS 配置。
單擊“完成”以完成配置。

要測試 IIS 是否已正確配置，請將 HTML 檔案（例如，x.html）複製到上面建立的虛擬目錄 (C:\MyWebServices) 中。現在，開啟 Internet Explorer 並鍵入https:///MyWebServices/x.html。它應該開啟 x.html 檔案。

注意 - 如果不起作用，請嘗試將 localhost 替換為您機器的 IP 地址。如果仍然不起作用，請檢查 IIS 是否正在執行；您可能需要重新配置 IIS 和虛擬目錄。

要測試此 Web 服務，請將 FirstService.asmx 複製到上面建立的 IIS 虛擬目錄 (C:\MyWebServices) 中。在 Internet Explorer 中開啟 Web 服務 (https:///MyWebServices/FirstService.asmx)。它應該開啟您的 Web 服務頁面。該頁面應包含指向我們的應用程式公開為 Web 服務的兩個方法的連結。恭喜！您已經編寫了您的第一個 Web 服務！

測試 Web 服務

正如我們剛剛看到的，在 .NET Framework 中編寫 Web 服務很容易。在 .NET 框架中編寫 Web 服務使用者也很容易；但是，它涉及的內容更多一些。如前所述，我們將編寫兩種型別的服務使用者，一種是基於 Web 的，另一種是基於 Windows 應用程式的使用者。讓我們編寫我們的第一個 Web 服務使用者。

基於 Web 的服務使用者

如下所示編寫基於 Web 的使用者。將其命名為 WebApp.aspx。請注意，它是一個 ASP.NET 應用程式。將其儲存在 Web 服務的虛擬目錄中 (c:\MyWebServices\WebApp.axpx)。

此應用程式有兩個文字欄位，用於獲取使用者要新增的數字。它有一個按鈕“執行”，單擊該按鈕後將獲取 Add 和 SayHello Web 服務。

WebApp.aspx
<%@ Page Language = "C#" %>
<script runat = "server">
   void runSrvice_Click(Object sender, EventArgs e) {
      FirstService mySvc = new FirstService();
      Label1.Text = mySvc.SayHello();
      Label2.Text = mySvc.Add(Int32.Parse(txtNum1.Text),  Int32.Parse(txtNum2.Text)).ToString();
   }
</script>

<html>
   <head> </head>
   
   <body>
      <form runat = "server">
         <p>
            <em>First Number to Add </em>:
            <asp:TextBox id = "txtNum1" runat = "server" Width = "43px">4<  /asp:TextBox>
         </p>
			
         <p>
            <em>Second Number To Add </em>:
            <asp:TextBox id = "txtNum2" runat = "server" Width = "44px">5</asp:TextBox>
         </p>
			
         <p>
            <strong><u>Web Service Result -</u></strong>
         </p>
			
         <p>
            <em>Hello world Service</em> :
            <asp:Label id = "Label1" runat = "server" Font-Underline = "True">Label< /asp:Label>
         </p>

         <p>
            <em>Add Service</em> :
            & <asp:Label id = "Label2" runat = "server" Font-Underline = "True">Label</asp:Label>
         </p>
			
         <p align = "left">
            <asp:Button id = "runSrvice" onclick = "runSrvice_Click" runat = "server" Text = "Execute"></asp:Button>
         </p>
      </form>
   </body>
</html>

建立使用者後，我們需要為要使用的 Web 服務建立代理。當引用已新增的 Web 服務時，Visual Studio .NET 會自動為我們完成這項工作。以下是需要遵循的步驟：

為要使用的 Web 服務建立代理。使用 .NET SDK 提供的 WSDL 實用程式建立代理。此實用程式從 Web 服務中提取資訊並建立代理。代理僅對特定 Web 服務有效。如果您需要使用其他 Web 服務，則也需要為此服務建立代理。當新增 Web 服務引用時，Visual Studio .NET 會自動為您建立代理。使用 .NET SDK 提供的 WSDL 實用程式為 Web 服務建立代理。它將在當前目錄中建立 FirstSevice.cs 檔案。我們需要編譯它以建立 Web 服務的 FirstService.dll（代理）。

c:> WSDL https:///MyWebServices/FirstService.asmx?WSDL
c:> csc /t:library FirstService.cs

將已編譯的代理放在 Web 服務虛擬目錄的 bin 目錄中 (c:\MyWebServices\bin)。Internet 資訊服務 (IIS) 在此目錄中查詢代理。
建立服務使用者，就像我們已經做的那樣。請注意，在使用者中例項化了 Web 服務代理的物件。此代理負責與服務互動。
在 IE 中鍵入使用者的 URL 以測試它（例如，https:///MyWebServices/WebApp.aspx）。

基於 Windows 應用程式的 Web 服務使用者

編寫基於 Windows 應用程式的 Web 服務使用者與編寫任何其他 Windows 應用程式相同。您只需要建立代理（我們已經完成了）並在編譯應用程式時引用此代理。以下是我們使用 Web 服務的 Windows 應用程式。此應用程式建立一個 Web 服務物件（當然，是代理）並在其上呼叫 SayHello 和 Add 方法。

WinApp.cs

using System;
using System.IO;

namespace SvcConsumer {
   class SvcEater {
      public static void Main(String[] args) {
         FirstService mySvc = new FirstService();
         Console.WriteLine("Calling Hello World Service: " + mySvc.SayHello());
         Console.WriteLine("Calling Add(2, 3) Service: " + mySvc.Add(2, 3).ToString());
      }
   }
}

使用c:\>csc /r:FirstService.dll WinApp.cs進行編譯。它將建立 WinApp.exe。執行它以測試應用程式和 Web 服務。

現在，問題出現了：您如何確定此應用程式實際上是在呼叫 Web 服務？

測試很簡單。停止 Web 伺服器，以便無法聯絡 Web 服務。現在，執行 WinApp 應用程式。它將引發執行時異常。現在，再次啟動 Web 伺服器。它應該可以工作。

Web Services - 安全性

安全對於 Web 服務至關重要。但是，XML-RPC 和 SOAP 規範都沒有提出任何明確的安全或身份驗證要求。

Web 服務存在三個特定的安全問題：

機密性
身份驗證
網路安全

機密性

如果客戶端向伺服器傳送 XML 請求，我們能否確保通訊保持機密？

答案在這裡：

XML-RPC 和 SOAP 主要在 HTTP 之上執行。
HTTP 支援安全套接字層 (SSL)。
可以透過 SSL 對通訊進行加密。
SSL 是一種經過驗證的技術，並且已廣泛部署。

單個 Web 服務可能包含一系列應用程式。例如，一項大型服務可能會將三個其他應用程式的服務捆綁在一起。在這種情況下，SSL 不夠；需要在服務路徑上的每個節點對訊息進行加密，並且每個節點都代表鏈中一個潛在的薄弱環節。目前，還沒有針對此問題的商定解決方案，但一種有希望的解決方案是 W3C XML 加密標準。此標準為加密和解密整個 XML 文件或 XML 文件的某些部分提供了一個框架。您可以在 www.w3.org/Encryption 中檢視它。

身份驗證

如果客戶端連線到 Web 服務，我們如何識別使用者？使用者是否有權使用該服務？

可以考慮以下選項，但對於強大的身份驗證方案尚無明確的共識。

HTTP 包含對基本身份驗證和摘要身份驗證的內建支援，因此可以像當前保護 HTML 文件一樣保護服務。
SOAP 數字簽名 (SOAP-DSIG) 利用公鑰加密對 SOAP 訊息進行數字簽名。它使客戶端或伺服器能夠驗證另一方的身份。請在 www.w3.org/TR/SOAP-dsig 中檢視它。
結構化資訊標準促進組織 (OASIS) 正在開發安全斷言標記語言 (SAML)。

網路安全

目前還沒有簡單易行的解決方法，這個問題一直備受爭議。目前，如果您確實想要過濾掉 SOAP 或 XML-RPC 訊息，一種方法是過濾掉所有將內容型別設定為 text/xml 的 HTTP POST 請求。

另一種方法是過濾 SOAPAction HTTP 頭屬性。防火牆供應商目前也在開發專門用於過濾 Web 服務流量的工具。

Web Services - 標準

本章將為您介紹所有與 Web 服務相關的最新標準。

傳輸

BEEP（Blocks Extensible Exchange Protocol，以前稱為 BXXP）是一個用於構建應用協議的框架。它已由 IETF 標準化，它對網際網路協議的作用如同 XML 對資料的作用。

塊可擴充套件交換協議 (BEEP)

訊息傳遞

這些訊息傳遞標準和規範旨在為在分散的分散式環境中交換資訊提供一個框架。

描述和發現

只有潛在使用者能夠找到足夠的資訊以允許他們執行 Web 服務，Web 服務才有意義。這些規範和標準的重點是定義一組服務，這些服務支援對企業、組織和其他 Web 服務提供商的描述和發現；他們提供的 Web 服務；以及可用於訪問這些服務的技術介面。

安全

使用這些安全規範，應用程式可以進行安全通訊，旨在與通用的 Web 服務框架一起工作。

管理

Web 服務的可管理性定義為一組功能，用於在 Web 服務架構中發現 Web 服務的存在、可用性、健康狀況、效能、使用情況以及控制和配置。隨著 Web 服務變得越來越普遍並對業務運營至關重要，管理和實施 Web 服務的任務對於業務運營的成功至關重要。

Web 服務分散式管理

Web Services - 總結

在本教程中，您學習瞭如何使用 Web 服務。但是，Web 服務還包括 WSDL、UDDI 和 SOAP 等元件，這些元件有助於使其活躍起來。下一步是學習 WSDL、UDDI 和 SOAP。