安全、可靠、交易的 Web 服務：架構和組合

發行項
04/03/2007

2003 年 9 月

IBM Corporation

Donald F. Ferguson
IBM Fellow and一家
IBM Software Group Architecture Board

Tony Storey
IBM Fellow

Microsoft Corporation

Brad Lovering
辨別工程師

John Shewchuk
Web 服務架構師

1.0 簡介
   1.1 可組合服務
   1.2 實務組合範例
2.0 Web 服務：Service-Oriented架構
   2.1 服務是由架構和合約類型所描述
   2.2 服務相容性超過類型相容性
   2.3 服務方向假設有不良專案，而且會發生
   2.4 服務方向可彈性地系結服務
3.0 Web 服務規格和函式
   3.1 Web 服務的可組合方法
   3.2 基本概念 – 傳輸和傳訊
      3.2.1 傳輸 – HTTP、HTTP/S、SMTP
      3.2.2 訊息格式 – XSD
      3.2.3 WS-Addressing
   3.3 描述
      3.3.1 WSDL
      3.3.2 WS-Policy
      3.3.3 取得描述
      3.3.4 WS-MetadataExchange
      3.3.5 UDDI
   3.4 服務保證
   3.5 安全性
      3.5.1 WS-Security
      3.5.2 WS-Trust
      3.5.3 WS-SecureConversation
      3.5.4 WS-Federation
   3.6 可靠的傳訊
      3.6.1 WS-ReliableMessaging
   3.7 交易
      3.7.1 WS-Coordination
      3.7.2 WS-AtomicTransaction
      3.7.3 WS-BusinessActivity
   3.8 服務組合
      3.8.1 BPEL4WS
4.0 實務 Web 服務 – 範例
   4.1 第 1 部分：客戶體驗
   4.2 第 2 部分：供應商體驗
5.0 結論
6.0 通知

1.0 簡介

現今的 Web 服務，特別是處理 XML 編碼 SOAP 訊息、透過 HTTP 傳送，並使用 Web 服務描述語言 (WSDL) 來描述的分散式服務，正在廣泛部署。 (XML、SOAP 和 HTTP 詞彙目前經常使用，而且在許多方面，其用法已超出其原始縮寫。為了完整性，此處列出這些縮寫：XML—eXtensible 標記語言、SOAP—簡單物件存取通訊協定和 HTTP—超文字傳輸通訊協定.) Web 服務會用於各種應用程式整合案例：從簡單、臨機操作、防火牆後置、資料共用到非常大規模的網際網路零售和貨幣交易。而且，行動、裝置和方格案例中會套用愈來愈多的 Web 服務。

Web 服務提供軟體元件之間的互通性，這些元件可以在不同公司之間通訊，而且可以位於不同的基礎結構上。這可解決客戶、軟體發展人員和合作夥伴所面臨的其中一個最重要問題。 HTTP 和 SOAP 提供通訊和訊息互通性。 WSDL 提供服務的描述，以支援開發工具之間的互通性;它可補充通訊互通性，以及交換介面定義的能力。

基本 Web 服務規格集可讓客戶和軟體廠商解決重要的問題。基於其成功，許多開發人員和公司都已準備好處理 Web 服務技術更困難的問題。 Web 服務的成功讓開發人員想要更多來自 Web 服務的功能。由於有意義的工具和通訊互通性已成功，開發人員現在預期增強的函式可以交互操作。

除了基本訊息互通性和介面交換之外，開發人員還需要較高層級的應用程式服務交互操作。許多商業應用程式會在環境中執行， (「中介軟體」或「作業系統」) ，以支援安全性與交易等功能。

IBM、Microsoft 和其他產業中的其他人通常會要求讓 Web 服務更安全、更可靠且更能支援交易。此外，我們要求提供這些功能，同時保留目前在 Web 服務中找到的基本簡單性和互通性。

本檔提供一組可解決這些需求的 Web 服務規格的簡潔概觀。如需規格的詳細資料，我們會提供實際檔的參考。本檔的主要目的是簡短定義這些規格提供給客戶的價值。我們也描述這些規格如何彼此互補，以撰寫分散式應用程式的健全環境。

我們面臨重要的工程挑戰：如何為 Web 服務提供新的安全性、可靠性和交易功能，而不需要增加比所需的更複雜度？

1.1 可組合服務

如同我們已使用 SOAP 和 WSDL、IBM、Microsoft 和我們的合作夥伴一樣，遵循 Web 服務規格定義中 可組合性 的設計原則。我們遵循的方法是以 Web 服務規格定義中的 可組合性 設計準則為基礎。我們開發的每個規格都解決了立即的需求，而且在自己的許可權中具有價值。例如，開發人員可以採用可靠的傳訊來簡化其解決方案開發，或採用 BPEL4WS 來定義其服務組合。而且，雖然每個規格各自代表，但它們的設計目的是要彼此結合及使用。

我們會使用「 組合性 」一詞來描述可合併的獨立規格，以提供更強大的功能。作業系統和中介軟體提供者可以支援組成的功能，例如提供者可以整合可靠的傳訊支援來通訊 BPEL4WS 程式。此範例結合兩個獨立規格，藉由免除在程式設計期間處理訊息通訊錯誤的需求，以簡化通訊程式的開發。

可組合性可累 加耗用量 或 漸進式探索 新的概念、工具和服務。開發人員只需要瞭解並實作必要的專案，而且不再需要。解決方案的複雜度只會因為問題的需求增加而增加，而不是因為技術「繁重」。

可組合性具有並繼續成為 Web 服務的重要設計目標之一。在過去數年內，我們已定義 SOAP 和 WSDL (最基本的 Web 服務規格，) 原本就支援組合。 Web 服務的基本特性之一是一般、多部分的訊息結構。此結構可讓您組合新功能。支援新服務的新訊息專案可能會以不會改變現有功能處理的方式新增至訊息。例如，可以獨立新增交易識別碼和可靠的傳訊序號。這兩個延伸模組不會彼此衝突，而且與既有的訊息結構相容。

圖 1. 可組合性可讓您視需要使用元素。

圖 1 顯示簡單的 Web 服務訊息，其中包含WS 位址、WS-Security 和 WS-ReliableMessaging的專案。請注意，WS 定址、WS-Security和WS-ReliableMessaging元素是獨立的，而且這些元素可以獨立使用，而不需要改變其他元素的處理。

這項特性可讓安全性、可靠性和交易在 可組合 的訊息元素方面定義。

組合的概念也可讓您建立一組定義完善的可組合 Web 服務，以支援安全性、可靠性等。這些定義完善的服務會指定支援較高層級 Web 服務功能所需的服務行為。例如， WS-Trust 中定義的安全權杖服務會發出並驗證訊息中的安全性元素。

此外，服務取用者必須能夠判斷支援的和必要的服務保證。服務必須記錄其交易、安全性、可靠傳訊等需求和支援。WS-Policy可讓 Web 服務以累加方式增強其 WSDL，以記錄其支援或需要的交易、安全性和可靠性功能。 WSDL 和 WS-Policy 可針對服務的描述啟用組合。如此一來，另一方就能瞭解與服務互動時，要採用哪些訊息元素和更高層級的服務。

1.2 實務中的組合範例

圖 2 提供概觀，說明實務中的組合。客戶和供應商會使用 Web 服務來處理訂單。

圖 2. 訂單處理系統中的組合

在建置這些 Web 服務時，開發人員會使用 WSDL 和相關檔來描述其商務介面。這些 WSDL 檔案描述客戶和供應商 Web 服務將處理的訊息集，例如 SubmitPurchaseOrder (SubmitPO) 從客戶流向供應商的訊息。這會顯示在圖 2 頂端。一旦應用程式的核心部分就緒，開發人員就可以決定支援額外的功能，例如，在這裡，他們決定進行訂單處理交易。若要這樣做，它們會將下列元素組成現有的結構：

服務會關聯WS-Policy檔，說明其對交易的支援與其服務的 WSDL 描述。請注意，這些原則聲明會擴增，但基本上不會改變現有的商務功能。
為了支援交易處理，服務會新增一個額外的訊息元素，描述與現有應用程式訊息組合但基本上不會改變的交易。
當供應商服務收到包含交易專案的訊息時，它會使用這項資訊來與稱為支援交易函式之協調器之指定 Web 服務通訊。同樣地，這個額外的 Web 服務只會新增至解決方案，而且不需要修改現有商務功能的描述。
最後，服務可以實作其他作業，以支援與交易協調器服務整合。

在上圖中，這些額外的元素會反白顯示。

模型是累加且可組合的，因為：

新增函式可以獨立于新增其他函式之外完成。
新增函式不會中斷現有的訊息、訊息處理邏輯或 WSDL。

可撰寫性是一個越來越重要的設計原則，但方法不一定能充分瞭解。雖然個別 Web 服務規格會定義個別元素和服務如何互通，但本白皮書旨在提供如何撰寫規格集合的概觀，以提供更複雜的互通 Web 服務。

2.0 Web 服務：Service-Oriented架構

最近幾年，我們見證了以 Web 服務開發為中心的活動。有了所有這些活動，請務必返回並詢問「為何？」問題當然，Web 服務不會啟用新種類的計算功能，在所有 Web 服務仍然在現有的電腦上執行之後，執行相同的指令集並存取相同的資料。此外，在許多情況下，Web 服務通訊協定實際上可能會增加指定工作的通訊協定額外負荷。

我們在 Web 服務中看到這類興趣的其中一個重要原因是，Web 服務很適合啟用Service-Oriented架構 (SOA) 。使用 Web 服務建置 SOA 時，解決方案包含由 URL 識別的自發服務集合，以及使用 WSDL 記載的介面，以及處理妥善定義的 XML 訊息。 SOA 是物件導向 (OO) 、程式與資料中心解決方案實作方法的自然補充。事實上，建立 SOA 系統時，個別服務通常會使用其中一或多項技術來建構。

Service-Oriented架構與 OO 和程式系統不同，主要層面為： 系結。 服務會根據其提供 的功能 ，以及其傳遞方式來互動。 OO 和程式性系統會根據類型或名稱將元素連結在一起。下列各節提供更多詳細資料。

2.1 服務是由架構和合約類型所描述

不同于先前的系統，Web 服務模型不會對需要通用實作的共用類型概念運作。相反地，服務只會根據 WSDL/BPEL4WS 的 (合約進行互動，以取得訊息處理行為) ，以及訊息結構) (WSDL/XSD 的架構。這可讓服務描述它可以在這些訊息上傳送和/或接收和排序條件約束的訊息結構。結構與行為與明確、機器可驗證描述之間的分隔，可簡化異質環境中的整合。

此外，這項資訊足以描述服務介面的特性，讓應用程式整合不需要共用執行環境來建立訊息結構或行為。

服務導向模型假設完全分散式的環境，如果不可能的話，很難將架構和/或合約中的變更傳播到遇到服務的所有合作物件。服務方向表示合約和架構應該保持回溯相容，而且可能包含特定處理系統無法完全理解的資訊。

基於這個理由，設計用於服務導向設計的合約和架構技術，比傳統的物件導向介面更具彈性。特別是，服務會使用 XML 元素萬用字元等功能 (，例如 xsd：any) 、架構延伸和選擇性 SOAP 標頭區塊，以不中斷已部署應用程式的方式發展服務。這些特性是 Web 服務組合的關鍵。

2.2 服務相容性大於類型相容性

程式性與物件導向設計通常等於類型相容性與語意相容性。服務方向提供更豐富的模型來判斷相容性。結構化相容性是以合約 (WSDL 為基礎，並選擇性地使用 BPEL4WS) 和架構 (XSD) ，而且可以驗證。此外，WS-Policy提供服務之間的服務保證相容性的額外自動化分析。這會根據明確判斷提示的功能和需求，以WS-Policy 語句的形式完成。

使用 WS-Policy，服務會以包含判斷提示組合的電腦可讀取原則運算式形式描述其服務保證功能和需求。這可讓服務根據他們提供合約的「如何」或「品質」來彼此選取

不論判斷提示套用至哪個服務，原則判斷提示都是以穩定且全域唯一的名稱來識別，其意義在時間和空間中都是一致的。原則判斷提示也可能具有限定判斷提示確切解譯的參數。

2.3 服務方向假設有不良專案可能會發生，

分散式應用程式的一些先前方法明確假設一般類型空間、執行模型和程式/物件參考模型。基本上，「記憶體內部」程式設計模型定義了分散式系統模型。

服務方向只是假設服務會自發執行，而且沒有本機執行或一般作業環境的概念。因此，SOA 會明確假設通訊、可用性和類型錯誤是常見的。

為了維護系統完整性，服務導向的設計會明確依賴各種技術來處理非同步和部分失敗模式。非同步傳訊、交易、可靠傳訊和備援部署等技術是服務導向系統中的標準。

此外，不同于記憶體內部模型，服務方向不僅假設傳入訊息的格式可能不正確，也假設它可能已針對惡意或完全未預期的目的傳輸。因此，服務導向系統藉由要求應用程式證明已授與寄件者的必要許可權，藉此保護自己，讓所有訊息寄件者承擔證明責任。與服務自主性的概念一致，服務導向架構通常會依賴系統管理的信任關係，以避免傳統 Web 應用程式中常見的個別服務驗證機制。

2.4 服務方向可讓您彈性地系結服務

服務 導向架構 的核心概念之一， (SOA) 是彈性的服務系結。較傳統的程式、元件和物件模型會透過參考 (指標) 或名稱，將元件系結在一起。 SOA 支援更動態的服務實例探索，以提供要求者預期的介面、語意和服務保證。

在程式或物件導向系統中，呼叫端通常會根據伺服器匯出的類型或共用名稱稱空間來尋找伺服器。在 SOA 系統中，呼叫端可以搜尋登錄，例如 UDDI 服務。

這是與呼叫端需求相容的訊息。相容性可以透過 WSDL 或來自已知 XML 架構的相符訊息進行。
該檔支援呼叫端所需的服務保證。例如，呼叫端可能需要某些安全性或交易的方法。

與服務實作相關的鬆散系結，可用來解決各種商務需求，以替代行為實作。例如，替代實作可能會對應至供應鏈中的替代廠商，以便更快速地回應變更的市場狀況。同樣地，替代實作可能是異地分散的資料中心，以啟用災害容錯。

3.0 Web 服務規格和函式

本節提供 Web 服務規格的概觀。

3.1 Web 服務的可組合方法

本節簡短說明可用的 Web 服務規格。我們會向解決方案提供者說明其價值、其在更廣泛的架構中的角色，以及它們如何彼此相加。

下圖提供 IBM、Microsoft 和其他公司所發行之 Web 服務規格的高階群組。請注意，此圖並非表示群組之間的嚴格分層;而是要提供功能區域之間關聯性的直覺。例如，訊息安全性不需要 Description，同樣地描述是訊息的實用開發時間概念。

圖 3. 可互通的 Web 服務通訊協定架構

3.2 基本概念 - 傳輸和傳訊

如果我傳送以法文撰寫的信件，但您預期有英文電話，我們不會通訊。 Web 服務的互通性面臨相同的問題;我們藉由提供一組常見的傳輸和傳訊技術來解決此問題。

此外，為了確保這些技術在實務上有效，IBM、Microsoft 和其他人員建立了 Web 服務互通性組織 (WS-I) 。最近，WS-I 發行了一個基本設定檔，正式記載可互通的 Web 服務傳輸和傳訊機制。

3.2.1 傳輸 — HTTP、HTTP/S、SMTP

這組規格會定義在 Web 服務之間移動原始資料的核心通訊機制。

HTTP、HTTP/S 和 Simple Mail Transport Protocol (SMTP) 是此群組中的範例。 Web 服務實作可能會另外支援其他傳輸，但請務必支援標準、可互通的通訊協定。

3.2.2 訊息格式 — XSD

下一組規格會定義編碼 Web 服務訊息以進行傳輸的互通性機制。傳輸會在服務之間移動「位元組」區塊。只有在參與者可以將位元組轉換成其應用程式所處理之實用資料結構時，這才有用。

傳訊規格群組會定義如何正確格式化訊息。 XML 和 XML 架構定義提供機制，以抽象方式同意訊息 (資料) 結構。 SOAP 會定義標準編碼，以表示服務透過傳輸交換之位元組資訊中的 XML 訊息。

3.2.3 WS-Addressing

訊息和回應都會移至某處，並來自某處。 WS-Addressing 提供可互通的傳輸獨立方法來識別訊息傳送者和接收者。 WS-Addressing也提供更精細的方法，以識別傳送或應該接收訊息之服務內的特定元素。

現今大部分使用 Web 服務的系統，都會使用 HTTP 傳輸中放置的 URL 來編碼 Web 服務訊息的目的地。回應的目的地取決於傳回傳輸位址。此方法是以 HTTP 的基本瀏覽器伺服器模型為基礎。

使用現今的方法，來源和目的地資訊不是訊息本身的一部分。這可能會造成數個問題。例如，如果傳輸連線終止 (，則資訊可能會遺失，例如，如果回應需要很長的時間，且連線逾時) ，或訊息是由防火牆等媒介轉送。

WS-Addressing提供一種機制，可將目標、來源和其他重要位址資訊直接放在 Web 服務訊息中。簡單地說，WS-Addressing將位址資訊與任何特定傳輸模型分離。

在許多情況下，訊息會直接以服務為目標，而且只要使用 URL 即可描述訊息中的定址資訊。但在實務上，我們通常會發現訊息是以服務內的特定元素或資源為目標。例如，協調服務可能會協調許多不同的工作。協調器必須將大部分的傳入訊息與它所管理的特定工作實例產生關聯，而不是協調服務本身。

WS-Addressing提供簡單但功能強大的機制，稱為 端點參考 ，可定址服務所管理的實體。雖然這類資訊可以在服務的 URL 內以臨機操作方式編碼，但端點參考會提供標準 XML 元素，讓結構化方法來編碼這種精細的定址。

與訊息來源和目的地的傳輸中性編碼結合的精細控制組合，可讓 Web 服務訊息透過媒介在各種傳輸之間傳送，並同時啟用非同步和延長的持續時間通訊模式。

WS-Addressing也可讓傳送者指出回應應該以與傳輸無關的方式前往何處。訊息的回應不一定會移至寄件者。例如，在 HTTP 中，如果沒有WS-Addressing就無法指定應該在其他地方傳送回應。

這些傳訊模型的增強功能可讓 Web 服務用來支援許多商務案例。例如，某些銀行工作需要人工檢閱，以在特定步驟進行核准。工作在任何時間點通常有許多作用中的實例。 WS-Addressing提供一般機制，讓傳入或傳出訊息與特定工作產生關聯。服務使用的機制對透過端點參考使用服務的機制是透明的。

3.3 描述

傳輸和訊息規格可讓 Web 服務使用訊息進行通訊。但參與者如何知道訊息是什麼？ Web 服務檔或描述其傳送和接收的訊息的方式為何？使用 Web 服務需要瞭解 Web 服務將取用並產生之訊息，也就是 Web 服務的介面。規格的描述群組可讓 Web 服務表達其介面和功能。

除了訊息互通性之外;這些規格也會啟用 開發工具互通性。 描述規格提供標準模型，可讓來自不同廠商的不同工具共同支援開發人員。 Web 服務與實作和基礎結構選擇隔離合作夥伴的方式相同，描述規格會將合作夥伴與開發工具選項隔離。

3.3.1 WSDL

Web 服務描述語言 (WSDL) 和XML 架構 (XSD) 是此群組中的基底規格。 XML 架構可讓開發人員和服務提供者定義資料結構的 XML 類型，例如採購單和訊息，例如 CreatePO 訊息。 WSDL 可讓 Web 服務記錄接收和傳送的訊息。換句話說，服務在接收和傳送的訊息方面會執行哪些「動作」或「函式」。

WSDL 提供一系列訊息互動模式的支援。它支援沒有回應、要求/回應的單向輸入訊息，以及使用或不使用回應傳送的單向輸入訊息。最後兩種模式可讓服務指定它所需的其他服務。

建議的 WSDL 增強功能支援記錄服務的通訊協定和訊息格式，以及服務的位址。

3.3.2 WS-Policy

WSDL 和 XSD 定義通常不提供足夠的資訊來呼叫 Web 服務。 WSDL 和 XSD 會定義服務的介面語法，但不會表示服務如何傳遞其介面或服務預期呼叫者的資訊。例如，服務是否需要安全性或實作交易？

WS-Policy 可讓服務指定其預期呼叫端的內容，以及其實作其介面的方式。 WS-Policy是達到服務較高層級功能作業互通性的關鍵。安全性、交易、可靠的傳訊和其他規格需要具體WS-Policy架構。這些可讓服務描述其預期的功能保證，並提供給來電者。

WS-Policy架構提供定義原則運算式的基底模型。

WS-Policy 支援匯總原則語句的文法，並允許建構更有彈性且完整的原則集。

WS-PolicyAttachment 會指定如何將原則集與 XML 訊息和 WSDL 元素產生關聯， (作業和 portTypes) 。

WS-Policy和WS-PolicyAttachment提供架構。個別規格會定義其網域特定的原則語句和架構。

最後， @PageWS-PolicyAssertions 提供一組基本通用原則語句，可用來達成互通性。

3.3.3 取得描述

XML、XSD、WSDL 和 WS-Policy 支援，描述服務的介面和服務保證。但是，服務的潛在使用者如何找到這項資訊？

目前最常見的方法是透過電子郵件交換或口語。需要更一般用途的可調整模型。有兩個選項，服務可能會直接移至服務，以使用 WS-MetadataExchange 取得資訊，或者可以選擇使用 UDDI 服務來匯總多個目標服務的這項資訊。

開發人員在具有服務的參考時使用WS-MetadataExchange，並需要瞭解其用途。開發人員想要尋找支援一組特定函式之服務的參考時，會使用 UDDI。

3.3.4 WS-MetadataExchange

如上所述，服務通常會提供描述服務本身的資訊，例如 WSDL、WS-Policy 和 XSD。我們參考服務相關資訊作為中繼資料的收集性。 WS-MetadataExchange規格可讓服務透過 Web 服務介面提供中繼資料給其他人。假設只有 Web 服務的參考，潛在使用者可以存取一組 WSDL/SOAP 作業，以擷取描述服務的中繼資料。用戶端可以在設計階段、建置用戶端或在執行時間使用WS-MetadataExchange。

3.3.5 UDDI

通常，收集有關服務集合的中繼資料，以及讓資訊可在可搜尋的表單中提供。這類中繼資料匯總服務是實用的存放庫，組織可以在其中發佈其提供的服務、描述其服務的介面，以及啟用網域特定的服務分類法。 UDDI) 規格 (通用描述和探索介面會定義中繼資料匯總服務。

解決方案可以在設計階段查詢 UDDI，以尋找與其需求相容的服務。例如，開發人員可以在其 BPEL4WS 工作流程的定義中使用這些服務。解決方案也可以在執行時間查詢 UDDI。在此案例中，呼叫端「知道」所需的介面，並搜尋符合其功能需求的服務，或由已知的合作夥伴提供。

請注意，可用來使用中繼資料填入 UDDI 服務的機制之一，就是使用 WS-MetadataExchange 從服務取得中繼資料。

3.4 服務保證

Web 服務因為能夠橋接不同的系統而產生太多熱度。開發人員已使用傳輸、傳訊和描述的基本功能來產生許多功能完整的解決方案。不過，若要讓開發人員接受建立更強大的整合解決方案，Web 服務必須提供功能，以確保更傳統的中介軟體解決方案所提供的相同 服務保證 層級。它不足以直接交換訊息。應用程式和服務位於中介軟體和系統中，可提供寶貴的較高層級功能，例如安全性、可靠性和交易作業。 Web 服務必須提供這些函式之間互通性的機制。

3.5 安全性

此 @Page系列規格對於跨組織 Web 服務至關重要。這些規格支援驗證和訊息完整性、機密性、信任和隱私權。它們也支援不同組織之間的安全性同盟。

3.5.1 WS-Security

WS-Security 是安全 Web 服務的基本建置組塊。現今，大部分分散式 Web 服務都依賴安全性功能的傳輸層級支援。範例包括 HTTP/S 和BASIC-Auth驗證。這些安全性方法可提供安全通訊所需的最低需求。不過，它們所提供的函式層級明顯小於現有中介軟體和分散式環境所提供的函式層級。

兩個範例強調BASIC-Auth和 HTTP/S 的缺點。

會將訊息傳送至服務 B。B 會部分處理訊息並將其轉送至服務 C。HTTP/S 允許驗證、A-B 與 B-C 之間的機密性和完整性。不過，C 和 A 無法彼此驗證，或隱藏 B 的資訊。
針對 A、B 和 C，使用BASIC-Auth進行驗證。他們必須共用相同的複寫使用者和密碼資訊。在許多情況下，這是無法接受的。

WS-Security解決這些問題。它支援：

已簽署、加密的安全性權杖。可以產生權杖，C 可以驗證為來自 A。B 無法偽造權杖。
可以簽署選取的專案或整個訊息。這可讓 B 和 C 確認訊息自 A 傳送後尚未變更。
可以密封訊息或選取的專案。這可確保只有那些元素的預定服務可以使用資訊。這可防止 B 查看適用于 C 的資訊，反之亦然。

WS-Security使用 Kerberos、X509 等) 的現有安全性 (模型。規格具體定義如何以可互通的方式使用現有的模型。若沒有 WS-Security，多方 Web 服務計算就無法安全。

3.5.2 WS-Trust

安全性依賴預先定義的信任關係。 Kerberos 的運作方式是因為參與者「信任」Kerberos 金鑰發佈中心。 PKI 的運作方式是因為參與者信任根憑證授權單位。 WS-Trust 會定義可延伸的模型，以設定和驗證信任關係。

WS-Trust的主要概念是 安全性權杖服務 (STS) 。 STS 是一種區分的 Web 服務，會發出、交換及驗證安全性權杖。 WS-Trust可讓 Web 服務設定及同意其「信任」的安全性伺服器，以及依賴這些伺服器。

STS 具有廣泛的適用性，可用來發出各種判斷提示的安全性權杖。在許多情況下，它會用來發出相同的判斷提示，但格式不同。例如，STS 可能會發出 Kerberos 權杖判斷提示金鑰持有者為 Susan，而且可能會根據受信任的憑證授權單位單位所簽發的 X.509 憑證來執行此動作。這可讓組織使用不同的安全性技術來同盟。 STS 也可能發出安全性權杖判斷提示，指出金鑰持有者是以判斷提示身分識別宣告的傳入安全性權杖為基礎的群組 BankTellers 成員。

3.5.3 WS-SecureConversation

某些 Web 服務案例只牽涉到少數訊息的短暫交換。 WS-Security可立即支援此模型。其他案例牽涉到 Web 服務之間的長時間、多訊息交談。 WS-Security也支援此模型，但解決方案不是最佳的。

在下列案例中，有兩個WS-Security的次佳用法：

重複使用計算成本高昂的密碼編譯作業，例如公開金鑰驗證。
使用相同的密碼編譯金鑰傳送和接收許多訊息，提供詳細資訊，允許暴力密碼破解攻擊「中斷程式碼」。

基於這些原因，HTTP/S 等通訊協定會使用公開金鑰來執行定義 交談特定金鑰 的簡單交涉。此金鑰交換允許更有效率的安全性實作，也會減少使用一組特定金鑰加密的資訊量。

WS-SecureConversation 為 WS-Security 提供類似的支援。參與者通常會使用WS-Security搭配公開金鑰來啟動「交談」或「會話」，並使用WS-SecureConversation同意會話特定金鑰來簽署和加密資訊。

3.5.4 WS-Federation

WS-Federation 可讓一組組織建立單一虛擬安全性網域。例如，旅遊代理人、航空公司和旅館鏈結可能會設定這類同盟。「登入」任何同盟成員的使用者，已有效地登入所有成員。 WS-Federation定義數個模型，以透過WS-Trust與WS-SecureConversation拓撲之間的通訊協定來提供同盟安全性。

此外，客戶在處理企業時通常會有「屬性」。例如，視窗或雜訊基座的喜好設定，或中型汽車。 WS-Federation可讓成員設定同盟屬性空間。這可讓每個參與者能夠安全地存取每位成員有關使用者的屬性資訊。

個人的相關屬性和資訊可能會密切保存，以進行隱私權保護，或因為該資訊為特定成員提供競爭優勢。為了支援這些需求，WS-Federation支援 假名模型。 已向旅遊機構驗證的使用者在與航空公司或旅館的互動中產生「別名」。這可保護終端使用者的隱私權，以及旅遊機構可能透過瞭解使用者屬性而獲得的競爭優勢。

3.6 可靠的傳訊

在網際網路世界中，幾乎所有的通道都不可靠。訊息消失。連線中斷。

如果沒有可靠的傳訊標準，Web 服務應用程式開發人員必須將這些函式建置到其應用程式中。瞭解基本方法和技術，例如許多作業和中介軟體系統可確保訊息具有唯一識別碼、提供序號，並在訊息遺失時使用重新傳輸。如果應用程式 Web 服務開發人員在其應用程式中實作這些模型。它們可能會做出不同的假設或設計選擇，如果有任何可靠的傳訊，則很少。

3.6.1 WS-ReliableMessaging

WS-ReliableMessaging 會定義機制，讓 Web 服務能夠確保透過不可靠的通訊網路傳遞訊息。

WS-ReliableMessaging可確保服務實作可互通的方法，也可讓執行時間廠商透過提供實作通訊協定的服務來簡化應用程式開發。這可大幅簡化應用程式開發的工作。商務邏輯接著必須處理的錯誤狀況較少。

最後，產業有一組豐富的訊息導向中介軟體，可哥靠地路由和散發訊息。每個實作都會使用專屬通訊協定。 WS-Reliable傳訊通訊協定可讓不同的作業系統和中介軟體系統可靠地交換訊息。因此，它支援將兩個不同的基礎結構橋接成單一、以邏輯方式完成的端對端模型。

3.7 交易

複雜的商務案例可能需要多方交換多個訊息集。例如，一組金融機構會設定涉及保險原則、年金、檢查帳戶和帳戶的金融供應專案。參與者之間交換的多個訊息會構成邏輯「工作」或「目標」。

為了成功，合作物件必須能夠：

啟動新的協調工作。
將作業與其邏輯工作建立關聯。合作物件可能會同時為不同的客戶設定多個帳戶。
同意計算的結果。例如，每個人都同意已設定財務套件嗎？

WS-Coordination、WS-AtomicTransaction 和 WS-BusinessActivity支援這些需求。

3.7.1 WS-Coordination

WS-Coordination@Page是一般機制，可啟動及同意多部分、多訊息 Web 服務工作的結果。 WS-Coordination有三個主要元素：

稱為協調內容的訊息元素，會在計算期間 Web 服務交換的所有訊息上流動。協調內容包含協調服務的WS-Addressing端點參考，並接著包含資訊來識別正在協調的特定工作。
協調器服務。協調器服務提供使用 WSDL 描述的服務，可提供啟動協調工作、終止協調工作、允許參與者在工作中註冊，以及產生屬於群組內所有訊息的協調內容。
協調服務也包含一個介面，定義于 WSDL中，參與的服務會用來通知協調工作的結果。

接收具有新協調內容之訊息的 Web 服務會在內容中向協調器服務註冊，以接收結果資訊。其他規格可能會針對網域和保證特定需求來增強此架構。

WS-Coordination是一般架構和功能。 WS-AtomicTransaction和WS-BusinessActivity擴充此架構，讓分散式運算中的參與者能夠強固地判斷結果。

3.7.2 WS-AtomicTransaction

WS-AtomicTransaction 會定義一組特定的通訊協定，這些通訊協定會插入WS-Coordination模型，以實作傳統的雙階段不可部分完成交易通訊協定。請務必注意，不可部分完成的雙階段模型只與相關的服務有關。網站或基礎結構供應專案服務可能會公告兩階段認可，但使用一些其他企業內部模型，例如補償或版本設定。這種自由讓簡單的雙階段認可模型更適合長時間執行的網際網路計算。

3.7.3 WS-BusinessActivity

WS-BusinessActivity 會定義一組特定的通訊協定，這些通訊協定會插入WS-Coordination模型，以實作長時間執行的補償型交易通訊協定。雖然 BPEL4WS 會定義商務程式的交易模型，但WS-BusinessActivity指定對應的通訊協定轉譯。同樣地，這是 Web 服務規格的組成性範例。

3.8 服務組合

Web 服務分層中的最上層元素是 服務組合。服務組合可讓開發人員「撰寫」服務，以交換 SOAP 訊息並在 WSDL 中定義其介面，並將WS-Policy轉換成匯總解決方案。匯總是組成 Web 服務。

3.8.1 BPEL4WS

Web 服務的商務程式執行語言 (BPEL4WS) 規格支援服務組合。它可讓開發人員定義一組共同實作共用商務解決方案的 Web 服務結構和行為。服務集合的每個元素都會使用 WSDL 和 WS-Policy 來定義其介面。撰寫的解決方案本身是 Web 服務，它支援 HTTP/SOAP 訊息，並使用 WSDL 和 WS-Policy 定義其介面。

組合有三個層面：結構、資訊和行為。BPEL4WS 引進三種支援每個組合層面的建構。

partnerLink定義複合服務與參與整體解決方案的 Web 服務之間的具名關聯。複合服務和參與服務會使用 WSDL 和 WS-Policy 彼此定義其介面。範例可能是製造公司與供應商之間的關聯。

組合與合作夥伴之間的 partnerLink 概念和 WSDL/WS-Policy 介面會定義服務組合 的結構 。他們會定義共同作業以形成組合的服務類型，以及它們與哪些保證層級交換的訊息 (安全性、交易等)

BPEL4WS 也支援定義服務組合 的資訊 。 BPEL4WS 定義變數的概念。複合服務會定義一組變數，每個變數都有 XSD 定義。特定服務的目前狀態是其變數的狀態。這會定義其已接收或傳送的訊息。

最後，BPEL4WS 支援藉由活動的概念來定義複合服務的行為。 BPEL4WS 定義的服務是一組活動或「步驟」，可定義服務的行為。最基本的活動是將訊息傳送給合作夥伴，或接收來自合作夥伴的訊息。每個訊息都會對應至變數。 BPEL4WS 支援在變數之間移動資料。

BPEL4WS 活動的其中一個重要層面是 BPEL4WS 藉由允許控制使用非決定性行為，為服務定義外部可見 (公用) 行為提供特殊支援。例如，在接受 PO 的決策程式中，點數檢查是以特定方式執行，可能是供應商的私人事項。 BPEL4WS 允許從程式描述卸載信用檢查行為來隱藏決策程式，但顯示 PO 的回應可能是接受或拒絕。這種類型的抽象程式可以與 WSDL 搭配使用，以定義商務夥伴與垂直產業領域之間的互通商務通訊協定，例如供應鏈。

BPEL4WS 也支援數種方法來控制活動的執行流程。這些包括排序和圖形型流程。 BPEL4WS 支援變數上的述詞，以判斷複合服務所遵循的控制項路徑。

總而言之，BPEL4WS 會新增兩個先前定義的 Web 服務規格。

BPEL4WS 可擴充 WSDL 和WS-Policy描述服務的支援。 BPEL4WS 支援將 Web 服務結合成匯總服務，以及記錄服務之間的關聯，例如資訊流程和行為。這可支援較高層級工具之間的互通性，以支援 Web 服務的共同作業設計。
BPEL4WS 是 執行語言。 BPEL4WS 可讓開發人員完整指定複合 Web 服務的行為。 IBM、Microsoft 和其他合作夥伴會提供執行 BPEL4WS 檔的環境，並支援與合作夥伴系結的設計與執行時間系結。

實務上 4.0 Web 服務 -- 範例

下列案例示範如何使用 WS 規格一起使用，以建立可解決真實世界需求的 Web 服務。此案例提供可供開發人員使用的強大功能範例，因為不同 WS 規格的可組合性。

此案例中所述的 Web 服務是針對 2003 年 9 月 17 日所持有技術的聯合IBM-Microsoft示範所建立。他們用來建立可互通、安全、可靠且交易的應用程式;且跨越組織界限。

此示範顯示同盟訂單處理和廠商受控清查 (VMI) 系統的執行範例，而汽車轉銷商會訂購汽車製造商的元件;製造商接著會從供應商取得多個倉儲的元件。系統中所有應用程式對應用程式通訊都是使用先前所述的 Web 服務通訊協定所建置，並在具有 IBM 和 Microsoft 軟體的電腦集合上執行。

此案例會處理進行商務的一些最常見層面，也就是零售業務、其轉銷商和轉銷商供應商之間的互動。此案例顯示如何撰寫不同的 WS 規格，以自動化商務程式基本概念，例如：

強制執行安全性 (WS-Security) 的驗證
不同組織之間的信任同盟 (WS-Trust 和 WS-Federation)
交換資料以完成交易 (WS-AtomicTransaction)
保證訂單已透過可靠的傳訊提交， (WS-ReliableMessaging)

4.1 第 1 部分：客戶體驗

此範例從名為 Auto 轉銷商的公司員工 Heather 開始，登入她的轉銷商安全內部網路網站。此網站是使用標準、現成的 Web 技術所建置。 Heather 會使用她的瀏覽器進入網站。網站的存取權受到密碼保護。

圖 4. Heather 會登入公司的安全內部網路網站，並流覽至其自訂的我的頁面。

Heather 按一下 [我的頁面]。在背景中，應用程式會從自動轉銷商的庫存資料庫收集資訊。如果專案的清查層級低於定義的閾值，就會產生報告，並列在熱度頁面的 [您的警示] 顯示中。

Heather 發現她的公司在 WindshieldPro Wiper 刀鋒視窗上具有低庫存。

Heather 按一下連結，並順暢地重新導向至自動製造商外部網路上的安全網頁，其中 Heather 可以下訂單。體驗順暢，因為自動轉銷商軟體是以 Web 服務為基礎。連結自動轉銷商內部網路與自動製造商外部網路的 Web 服務是由 WS-Federation 所組成。 WS-Federation可確保第二個月臺接受一個月臺授與的安全性認證。

以下是運作方式。自動轉銷商和自動製造商已同意同盟其網站。 WS-Federation協調一系列的伺服器對伺服器通訊。一旦 Heather 按一下 WindshieldPro 連結，將她帶至自動製造商的網頁，自動製造商的網頁伺服器就會查詢其授權服務，進而查詢自動轉銷商的授權服務。自動轉銷商授權服務會確認 Heather 是已授權的使用者，傳輸認證以及 Heather 轉銷商的名稱，回到自動製造商的授權服務，以授與 Heather 存取權。這會順暢地發生，所有 Heather 附注都是她已從一個網頁到另一個網頁。

Web 服務也會查詢自動製造商客戶資料庫，以訂購連結到 Heather 帳戶的資訊。此資訊會顯示在個人化的「我的頁面」自動製造商網頁中。

圖 5：使用WS-Federated撰寫 Web 服務可讓 Heather 順暢地從自動轉銷商的個人化頁面移至自動製造商的個人化頁面。

熱度在自動製造商外部網路上的個人化網頁可讓她看到她目前沒有未完成的訂單;她有一個訂單 (50 個 SuperTires) 傳輸中;且其已完成訂單清單包含 20 個 CDPlus 單位，以及 50 個單位的清理工具。

Heather 按一下 [建立新訂單]，並開啟新的頁面，並預先填入想要的元件：WindshieldPro Wiper 刀鋒視窗和訂購日期。她只需要輸入的數量。完成訂單所需的所有其他資訊都會從自動製造商資料庫填入。

圖 6. 因為大部分的訂購資料已經從 Auto Manufacturer 客戶資料庫的 Heather 檔案匯入，所以很容易下單。

Heather 會提交訂單，並搜尋要購買的其他專案，或按一下 [登出] 結束其會話，並防止其他人從其自動電腦下訂單。

請注意，使用WS-Federation撰寫 Web 服務，同時為自動轉銷商和自動製造商提供較低的系統管理成本和端對端安全性。如果沒有這項技術，自動製造商必須維護所有授權轉銷商員工及其密碼的清單。這會耗費成本、容易發生錯誤，並減少應用程式的安全性。

例如，如果 Heather 結束其工作，則會在自動轉銷商移除她的使用者帳戶。但是，如果轉銷商的系統管理員忘記連絡汽車製造商有關其出發時間，她會繼續存取購買網站。使用 WS 同盟時，這不是問題，因為必須變更的唯一系統是自動轉銷商的識別提供者服務。應用程式與授權服務的自動製造商系統都對 Heather、她的使用者名稱或密碼沒有固有的知識。

4.2 第 2 部分：供應商體驗

雖然 Heather 從自動製造商訂購 WindshieldPro 抹除刀鋒視窗，但自公司實際建立自己的刀鋒視窗以來，已經是半年。 WindshieldPro Wiper 刀鋒視窗來自廠商供應商。

Tony 是供應商的銷售代表，他會透過登入供應商的內部網路開始，就像 Heather 登入自動轉銷商內部網路一樣。但 Tony 與具有 Web 服務內建支援的 Windows 應用程式搭配使用，而不是使用標準網頁瀏覽器。

圖 7. 供應商內部網路上的 Tony 個人頁面會提醒他檢查其中一個主要客戶 Auto Manufacturer 的訂單和庫存。

當 Tony 按一下以檢查訂單和清查時，其應用程式會使用 Web 服務來要求 Tony 允許存取的庫存資料。

此應用層級 Web 服務要求資料的其中一個重要層面，就是它是由WS-Federation所組成，可驗證其對自動製造商外部網路的存取權。

Web 服務會將結果傳回給供應商的頁面，其依產品類型和目前的庫存計數顯示。

圖 8. Web 服務會將來自自動製造商庫存資料庫的庫存資料填入 Tony 的供應商頁面。藉由使用 WS-Security 和 WS-Federation 撰寫要求，即可保護要求的安全。

供應商已與自動製造商進入 Just-In-Time 購買合約。 Tony 已獲授權，在庫存低於 20 時，提供自動重新供應訂單，作為廠商受控清查 (VMI) 的一部分。 Tony 按一下 WindshieldPro 以下訂單。 Tony 與 Auto Manufacturer 之間的所有訊息都會受到保護，因為 Web 服務支援由 WS-Security 保護所組成的 Web 服務支援。

圖 9. 與自動製造商的 Just-In-Time 合約可讓 Tony 代表公司輸入訂單。

Tony 的應用程式會提供一個畫面，以使用自動製造商採購單來建立供應商的要求。 Tony 會訂購 50 WindishieldPros 抹除器，直接運送到自動製造商。

當 Tony 按一下 [確定] 時，「倉儲服務」是使用 WS-AtomicTransactions、WS-Security 和 WS-ReliableMessaging 所組成的 Web 服務，會嘗試將訂單放在另一個 Web 服務、次級倉儲服務。當因暫時網路中斷而無法立即從倉儲服務傳迴響應 (時，) WS-ReliableMessaging會繼續重新傳送查詢，直到收到回應為止。

當倉儲服務收到訂單時，它會將其內部轉送至公司的兩個實體倉儲。由於這牽涉到這兩個倉儲之間的資料庫，因此WS-AtomicTransaction用來確保資料庫之間的交易行為。

倉儲應用程式會將訂單分成次級倉儲服務，以確保庫存涵蓋範圍，70% 的訂單會進入倉儲 1，其餘 30% 則移至倉儲 2。主要倉儲中的根協調器會將訊息傳送至 Warehouse 2 的根協調器，要求訂單的 30%。倉儲 2 的根協調器會檢查其庫存，並將訊息傳送至主要倉儲的根協調器，指出庫存不足。

主要根協調器知道沒有足夠的清查會取消整個交易，並將訊息傳送至 Tony 的 Web 服務應用程式，指出狀態、清查層級，以及交易已取消。根協調器會開始回復交易，當完成時返回倉儲，表示交易已取消。

Tony 使用目前的清查知識，將另一個要求傳送至倉儲。根協調器會協調其他交易實體 (其他交易的控制器) ，並將此要求提交至 2 個倉儲，其程式與之前相同。我們會使用WS-Security來簽署整個訊息本文，因此無論您在哪個網域中知道您是安全的網域。

現在根協調器會認可交易、鎖定資源並完成交易。訊息會傳回 Tony，指出交易已順利完成。

WS-AtomicTransaction使用這些訊息中的WS-ReliableMessaging和WS-Security撰寫，以提供完整的企業就緒分散式系統。

5.0 結論

IBM、Microsoft 和我們的合作夥伴正在開發 Web 服務規格，可作為新一代強大、安全、可靠、交易 Web 服務的建置組塊。

這些規格是以模組化且可組合的方式設計，讓開發人員只要利用所需的功能即可。這種類似元件的可組合性可讓開發人員以簡單且有彈性的方式建立強大的 Web 服務，同時只引進特定應用程式所指定的複雜度層級。

這項技術可讓組織使用Service-Oriented架構 (SOA) 輕鬆地建立應用程式。此外，IBM 和 Microsoft 已示範安全、可靠、交易的 SOA 應用程式，說明可使用此方法建立的商務程式豐富度。此外，這些示範已在由 IBM WebSphere 和 Microsoft .NET 軟體組成的異質環境上，在同盟安全性環境中運作。

我們預期這些 Web 服務技術將可在作業系統、中介軟體中使用，以及可讓開發人員更輕鬆地使用這些技術的工具。當開發人員和組織使用這些系統來建立新一代 Web 服務型解決方案時，這些應用程式會令人興奮。

6.0 通知

我們想要認可下列參與這些想法的個人： (字母順序) Tony Andrews、Bob Atkinson、 Keith Ballinger、Don Box、John Brezak、Allen Brown、Felipe Cabrera、Erik Christensen、George Copeland、Michael Coulson、Giovanni Della-Libera、Brendan Dixon、Mike Dusche、ColleenEvans、Max Feingold、Jeff Frey、Henrik Frystyk Nielsen、Praerit Garg、Proi Gazitt、Scot Gellock、 Josh Gray、Martin Gudgin、MaryAnn Hondo、Destry Hood、efim Hudis、Tomasz Janczuk、Jim Martin、Ryan Martin、 Gopal Kakivya、Chris Kaler、Johannes Klein、Scott Konersmann、Brian LaMacchia、Dave Langworthy、Andrew Layman、Paul Leach、Al Lee、Frank Leymann、Rodney Limprecht、Joe Long、Steve Lucco、John Manferdelli、Ashok Malhotra、Jonathan Marsh、Steve Millet、Andrewa Mills、Tony Nadalin、Martin Nally 在不同的時間點、Stefan Pharies、Scott Robinson、Yordan Rouskov、Sujay Sahni、Jeff Schlimmer、Oliver Sharp、Yasser Shohoud、Dan Simon、Jeff Spelman、Keith Stobie、Satish Thatte、Robert Wahbe、Elliot Waingold、Api Ward、Sanjiva Weerawarana、Hervey Wilson、Eric Zinda。

共用方式為