作者：Luis Felipe Cabrera、Christopher Kurt、Don Box

[摘要]

本Web服務架構入門闡述了Web服務架構的基礎設計原則和Web服務的基礎技術。此外還對其功能進行了介紹，并提供了對其進行正式定義的規範連結。本文也是該架構所有規範的參考指南。

XML和Infoset

對于所有的消息傳遞系統來說，選擇資訊傳輸機關是非常重要的——簡單地說，對消息的構成有個一般的認識是必不可少的。在Web服務中，一條消息就是一個XML文檔資訊項，它由XML資訊集（XML Information Set，即Infoset）定義。Infoset是一個抽象的資料模型，它相容基于文本的XML 1.0，也是所有最新XML規範（XML Schema、XML Query和XSLT 2.0）的基礎。由于Web服務架構是以XML Infoset，而不是某一特定的表現形式為基礎，使得該架構及其核心協定元件可與其他編碼技術相容。

Infoset根據一組‘資訊項（Information Items）’對XML文檔進行模組化。這組可能的資訊項一般會映射到XML文檔的不同功能部件上，如元素、屬性、命名空間和注解。每一資訊項都有一個關聯屬性集，用于提供該項的更完整描述。附錄B描述了XML文檔中的11類資訊項。每一個結構嚴謹的XML文檔都會包含一個文檔資訊項和至少一個元素資訊項。

除了基于純文字的Infoset編碼技術以外，Web服務架構還支援另外一種Infoset編碼技術——即允許不透明的二進制資料與傳統的基于文本的标記交織在一起。W3C XML-binary Optimized Packaging（即XOP）格式使用多部分MIME将原始二進制資料引入到XML 1.0文檔中，而不采用base64編碼。其配套規範——SOAP 消息 Transmission Optimization Method，即MTOM，則指定如何将該格式綁定到SOAP。XOP和MTOM是将原始二進制資料與基于文本的XML混合在一起的首選方法，它們取代了目前普遍遭到反對的SOAP with Attachments（SwA）和WS-Attachments/DIME。

SOAP

SOAP為在分散的分布式環境中使用XML在同等體之間交換結構化分類資訊提供了一種簡單的輕量級機制。SOAP旨在最大限度地降低對基于不同平台建構的應用程式進行內建的設計成本，并認為最低成本技術最有可能赢得普遍接受。SOAP消息是包含三個元素的XML文檔資訊項，這三個元素是：<Envelope>、<Header>和<Body>。

Envelope是SOAP消息的根元素，它包含一個可選的Header元素和一個必需的Body元素。Header元素是以分散方式增加SOAP消息功能的一種通用手法。Header的每個子元素都被稱為一個Header塊（Header Block），SOAP定義了幾個知名的屬性來訓示應該由誰來處理Header塊（role）以及這種處理是可選的還是必需的（mustUnderstand），下文中對這兩個屬性進行了介紹。目前，Header元素總是Envelope的第一個子元素；Body元素總是Envelope的最後一個子元素，也是供最終消息接收者使用的“有效負載”的容器。SOAP本身沒有定義内置的Header塊，且隻定義了一個有效負載，那就是用于報告錯誤的Fault元素。

所有的Web服務消息都是SOAP消息，它們充分利用了XML Infoset。消息有效負載和協定頭都使用同一個模型，可以確定基礎架構頭Header和應用程式體的完整性。應用程式發送消息時可能會同時考慮Header的内容和消息中的資料。為XML資料模型開發的工具可以用于檢查和建構完整的消息。過去，這些益處在某些架構中是沒有的，如DCOM、CORBA和RMI，它們之中的協定頭是一些對應用程式不透明的基礎架構細節。

SOAP消息是從發送者向接收者單向傳送的。多個單向消息的組合可以形成較為複雜的模式。例如，比較常見的模式是同步請求/響應消息對。發送或接收消息的任何一個軟體代理都被稱為一個SOAP節點（SOAP Node）。啟動消息傳輸的節點稱為原始發送節點。使用和處理消息的最後一個節點稱為最終接收節點。在原始發送節點和最終接收節點之間處理消息的任一節點都叫做中介（Intermediary）。中介用于模拟單個消息的分布式處理。消息經過的所有中介節點和最終接收節點統稱為消息路徑（Message Path.）。

為了能夠識别消息路徑的各個部分，每個節點都擔任一個或多個角色。SOAP角色是一種分類模式，它将一個基于URI的名稱與某些抽象功能（如緩存、驗證、授權）關聯在一起。基礎SOAP規範定義了2個内置角色：Next和UltimateReceiver。Next是一個通用角色，因為除了發送節點之外的每一個SOAP節點都屬于Next角色。UltimateReceiver是消息路徑中終端節點所扮演的角色。它通常就是應用程式，或在某些情況下是代表該應用程式執行任務的基礎架構。

SOAP envelope的Body總是針對最終接收節點。而SOAP header則可以針對中介，也可以針對最終接收節點。為了提供一個安全且版本可控的消息處理模型，SOAP定義了3個屬性，用于控制中介和最終接收節點處理某一指定Header塊的方式——role、relay和mustUnderstand。角色屬性用于确定Header塊所針對的節點。mustUnderstand屬性用于訓示在Header塊未被認出的情況下該節點是否可以忽略該Header塊。帶有mustUnderstand="true"标記的Header塊叫做強制Header塊（Mandatory Header Block）。标記為mustUnderstand="false"或沒有mustUnderstand屬性的Header塊叫做可選Header塊。relay屬性訓示該節點是發送還是放棄未被認出的可選header。

每一個SOAP節點都必須使用這3個屬性來實作SOAP處理模型。以下步驟詳細說明了該模型：

使用角色屬性（預設該屬性表示Header塊針對最終接收節點）确定将用于目前SOAP節點的SOAP消息的所有Header塊。
驗證目前SOAP節點是否能夠使用SOAPmustUnderstand屬性來處理步驟1中所确定的所有強制Header塊。如果有強制Header塊不能被目前SOAP節點處理，則必須丢棄該消息，并生成一條醒目的錯誤消息。
處理消息。可以忽略可選消息元素。
如果SOAP節點不是消息的最終接收節點，則步驟1中所确定的所有無法分程傳送的Header塊都會被删除，然後消息被傳送到消息路徑中的下一個SOAP節點。下一個SOAP節點可以自由地将新的Header塊插入到分程傳送的消息中。其中的某些Header塊可能是步驟1中所确定的Header塊的副本。

SOAP處理模型旨在實作可擴充性和版本控制。mustUnderstand屬性對新Header塊的引入是中斷變化還是非中斷變化進行控制。添加可選header塊（如标記為mustUnderstand="false"的header）是一種非中斷變化，因為任何SOAP節點都可自由忽略它。添加強制header塊（如标記為mustUnderstand="true"的header）是一種中斷變化，因為隻有知曉Header塊文法和語義的SOAP節點才能夠處理SOAP消息。Role、relay以及mustUnderstand屬性沿着消息路徑傳遞這種處理模型。

消息交換模式

SOAP所提供的消息傳遞靈活性使Web服務能夠以多種消息交換模式進行通信，進而滿足分布式應用的需求。我們在該架構的核心構件中充分利用了其中一些模式，有幾種模式已經被證明在分布式系統中特别有用，比如使用遠端過程調用就使同步請求/響應消息交換模式得到了普及。當消息傳送潛伏時間失控時，就需要采用異步消息傳遞。當使用同步請求/響應模式時，顯式消息相關性則成為必需。

廣播傳輸（Broadcast Transport）使一對多消息傳輸得到了普及。原始發送者将其消息強行發送給接收者的模式稱為推模式（Push Model）。盡管這種模式在區域網路裡很有效，但在廣域網中則不太适用，接收者也無法調控消息流。另一個有用的模式是以應用程式表達對某些特定消息類别的興趣的能力為基礎的，它使釋出/訂閱模式大行其道。通過顯式訂閱消息源（或主題），應用程式可以更好地控制相關資訊流。接收者從消息源顯式請求消息時使用拉模式（Pull Model）。在這種模式下，消息流是由接收者驅動的。拉模式也可以與釋出/訂閱模式結合使用。這非常适合于接收者可能要與消息源間歇地斷開連接配接的情況。

傳輸的獨立性

根據SOAP的定義，它與所使用的底層消息傳遞機制無關。它支援很多可用的消息交換傳輸機制，也支援同步和異步消息傳送與處理。既需要多種傳輸又需要異步消息傳遞的系統的一個例子是在基于陸地高速網絡幹線的Web服務與由行動電話托管的間歇連接配接的Web服務之間進行通信的系統。這樣的系統要求一條消息經哪種傳輸系統傳輸要以該消息在哪個網段内移動為依據。這樣的系統還有一個典型特點，即消息傳送潛伏時間無法精确确定。Web服務開發人員不應力圖确定或界定消息傳送潛伏時間，而應在假定異步消息傳遞已達到最大效能的前提下建構系統。與使用遠端過程調用時的情況不同，異步消息傳遞允許發送者在每一消息傳輸之後繼續進行處理，而不必被迫阻塞并等待響應。當然，同步請求--響應模式也可以建構在異步消息傳遞的基礎之上。

既然Web服務協定完全獨立于底層傳輸之外，适當機制的選擇可能就要延遲到運作時。這就為Web服務應用程式提供了在發送消息時确定相應傳輸機制的靈活性。此外，底層傳輸機制可能會随着消息在節點之間的發送而變化，相應地，針對每一網段而選擇的傳輸機制也會随需發生變化。

盡管存在着這種一般的傳輸的獨立性，大多數第一代Web服務都使用HTTP來進行通信，因為這是SOAP規範内所包含的一種主要綁定協定。HTTP以TCP作為其底層傳輸協定。但是，TCP在設計時引入了不必要的處理開銷。有些應用協定模式與使用者資料報協定（即UDP， User Datagram Protocol）的語義學比較比對，這些模式對于受裝置及其他資源限制的系統特别有用。UDP不像TCP那樣具有傳輸保證；它提供最大限度的資料報消息傳遞。與TCP相比，它需要的實施資源較少。此外，UDP還提供了多路廣播功能（Multi-cast Capabilitiy），使一個發送者可以将消息同時發送給多個接收者。

尋址

對于要在這種多傳輸情況下發送和尋址的消息來說，要讓關鍵的消息傳遞屬性為多個傳輸所攜帶，就需要一種共用機制。為此，WS-Addressing規範定義了3組SOAP Header塊：

Action Header塊用于說明消息的預期處理。該Header塊包含一個URI，最終接收者通常用它來分派要進行處理的消息。
MessageID和RelatesTo Header塊用于識别和關聯消息。MessageID和RelatesTo header使用簡單的URI來唯一地識别消息——這些URI通常都是瞬态的UUID。
To/ReplyTo/FaultTo Header塊用于識别要處理消息及其回複的代理。這些Header依賴于WS-Addressing所定義的稱為“端點引用（Endpoint Reference）”的結構，它将與對SOAP消息進行正确尋址所需的資訊捆綁在一起。

端點引用是WS-Addressing的最重要的方面，因為與僅使用URI相比，它們可為更細粒度的尋址提供支援。它們廣泛用于整個Web服務架構。端點引用包含3條關鍵的資訊：基位址、可選的引用屬性集和引用參數。基位址是一個URI，用于識别端點，出現在指向該端點的每一SOAP消息中的To Header塊中。引用屬性和引用參數是用于為該消息提供附加發送或處理資訊以補充基位址的任意XML元素的集合，它們以文字Header元素來表示。當使用端點引用來建構端點消息時，發送者負責提供作為Header塊的所有引用屬性和引用參數。

引用屬性和引用參數之間的差別在于它們如何關聯服務中繼資料。Web服務政策和契約僅基于其基位址和引用屬性。通常，基位址和引用屬性用于識别某一給定的已部署服務，引用參數用于識别該服務所管理的特定資源。

引用屬性和參數是那些預期隻被最終接收者處理的簡單的不透明XML元素。它們有助于確定可用于分派、發送、索引或其他發送端處理活動的資訊被包含在給定的消息中。盡管中介預期不會對該資訊進行處理，但某些中介（如防火牆或網關服務程式）卻有可能使用某些引用屬性或參數來進行消息發送、消息處理。引用屬性有很多用途。服務類（Classes of Service）和專用實體辨別符（Private Entity Identifier）就是兩個例子。在服務等級例子中，引用屬性可以用于區分針對标準客戶的Web服務和針對“黃金”客戶的Web服務，後者提供了更高的服務品質和增強功能——可能是通過附加的操作或附加的綁定——在邏輯上形成兩個不同的端點。這些屬性隻在一個會話中設定一次，然後便在互動的其餘所有部分重複使用。引用屬性另一個用途的例子是以一種對系統不公開發送消息的方式來識别客戶的機制。這兩種引用屬性的組合可以高效地将消息發送給一組适當的伺服器，并高效地确定與某一特定使用者有關的應用狀态。這些例子還展示了引用服務執行個體的資料和引用使用者執行個體的資料如何用引用屬性來表示。

需要特别指出的是，引用屬性還有助于對共享一個共同的URL和作用域的WSDL實體集合進行尋址。WSDL是将Web服務描述為操作消息的一組端點的XML格式，它首先抽象地指定其實體，然後将其具體地綁定到特定執行個體。具體而言，消息和操作經抽象定義之後，被綁定到帶有網絡傳輸和消息格式資訊的一個端點。是以，從WSDL的角度來看，當針對不同的具體實體（如輸入或輸出消息、portType綁定、端口或Web服務中使用一個共同URL的服務）時，對應端點引用的引用屬性應該不同。

使用引用參數的兩個例子是基礎架構和應用水準。引用參數的基礎架構例子可以是發送給某一事務處理螢幕的事務/征募ID（Enlistment ID）。在一個購書的場景中，書的ISBN号可能就是一個引用參數應用水準例子。

中繼資料（Metadata）

所有的Web服務互動都是通過交換SOAP消息來進行的。為了提供一個健壯的開發和操作環境，服務是用機器可讀的中繼資料來描述的——中繼資料支援互操作性。Web服務中繼資料可以服務于若幹個意圖。它用于描述Web服務支援的消息互換格式和某一服務有效的消息交換模式。中繼資料還用于描述服務的功能和需求。中繼資料的最後一種形式叫做“服務政策（Policy of Services.）”。消息互換格式和消息交換模式用WSDL來表示，政策使用WS-Policy來表示，契約（Contract）用上述三種中繼資料來表示。契約是将應用程式與它們所依賴的服務的内部實作細節隔離開來的抽象。

Web服務描述語言，即WSDL——Web Service Description Language，它是被廣泛用于描述Web服務基本特征的第一種手段。用WSDL描述的消息被歸并為定義基本消息模式的若幹操作。這些操作被歸并為稱作端口的若幹個接口，它們詳細說明了抽象的服務契約。端口和綁定則用于将portTypes與具體傳輸和physical 部署資訊關聯在一起。WSDL描述是自動識别目标服務的所有特征和啟用軟體開發工具的第一步。WSDL指定請求消息必須包含什麼以及響應消息在使用無歧義符号時的顯示會是怎樣。WSDL檔案用于描述消息格式的符号是基于XML模式的。這意味着它既是程式設計語言中立的又是基于标準的，這使得它很适合于描述可通過多種平台和程式設計語言來通路的服務接口。除了描述消息内容以外，WSDL還可以定義服務在何處是可用的，以及哪些通信協定被用于與該服務交談。這意味着WSDL檔案可以指定用于編寫與某一Web服務進行互動的程式的基本元素。有幾種工具可用于讀取WSDL檔案，以及為編制句法正确的Web服務消息生成所需代碼。

盡管WSDL是一個不錯的起點，但它并不足以描述Web服務的方方面面，WSDL隻能表示較少的一組屬性。Web服務所必需的更詳細資訊包括：

操作特征：支援SOAP 1.2。
使用特征：僅在早9點和下午5點之間可用。
安全特征：要通路該服務必需使用Kerberos票。

第一代Web服務必須使用專有協定來交換帶外（Out of Band）的中繼資料，這一問題可以使用WS-Policy來解決。WS-Policy提供了一種通用模型和文法來描述和傳達Web服務政策。它指定了一個概念基集，它可以被其他Web服務規範使用和擴充，以描述更為廣泛的服務需求和功能。WS-Policy引入了一個簡單的可擴充文法來表示政策斷言（Policy Assertion），以及一個處理模型來解釋它們。斷言可以合并到邏輯選項中。

政策斷言使程式設計人員要麼在開發時、要麼在運作時向服務資訊中添加适當的中繼資料。開發時政策的例子包括消息大小的最大允許值或所支援規範的确切版本，運作時政策的例子包括當機時的必備服務或某一給定的管理過程（定期的硬體維護）期間Web服務的不可用性。可以對單個的政策斷言進行分組，以形成政策選項（Policy Alternative）。政策是政策選項的集合。為了便于進行互操作，政策是根據其XML Infoset表示形式來定義的。為了在保持互操作性的同時減小政策文檔的大小，又定義了政策的緊湊形式。

政策用于傳達兩個Web服務端點之間的互動條件。滿足政策中的斷言通常會引發反映這些條件的行為。是以，政策斷言評估是識别相容行為的中心。當且僅當請求者滿足要求，即提供了這一功能、與該斷言相符時，請求者才支援政策斷言——政策的構造塊。一般而言，這種決定要使用特定領域的知識來做出。請求者支援政策選項的條件是當且僅當請求者支援選項中的所有斷言時，這種決定是使用政策斷言的結果機械性地做出的。同樣，當且僅當請求者至少支援政策中的一個選項時，請求者才支援政策。一旦政策選項經過評估，該決定也是機械性地做出的。請注意，雖然政策選項是互斥的，但一般來說要确定多個選項是否可以同時得到支援也是不太可能的。

為了以互操作的形式傳達政策，政策表達式（Policy Expression）采用政策的某種XML Infoset表示形式。普通形式的政策表達式是最簡單的Infoset；同樣，可選的Infoset允許通過大量構造來簡潔地表達政策。政策表達式是政策的基礎構造塊。有兩個運算符用于表達斷言：All和ExactlyOne。All運算符表示政策選項集中的所有斷言都必須适用于要滿足的政策斷言。ExactlyOne運算符表示政策選項集中隻有一條斷言必須适用于要滿足的政策斷言。

政策層位于WSDL描述之上，并對它進行了擴充。政策與Web服務中繼資料（如WSDL定義或UDDI實體）的關聯是通過使用WS-PolicyAttachment來實作的。政策可以作為其定義所固有的一部分或獨立地與資源關聯在一起。機制就是針對這些不同目的而定義的。需要特别指出的是，政策也可以與單個的SOAP消息一起使用。如果為某一實體制作了多個政策附件，它們會共同确定該實體的有效政策（Effective Policy）。在WSDL層次結構的不同層次上選用政策時一定要小心，因為層次結構每一層次的最終結果就是一個有效政策。作為自我描述和人所能了解的明确性的一般規則，在政策斷言所适用的層次結構的每一層次上詳細地重複該政策斷言，比簡單地依賴于計算有效政策的機制更可取。在一個WSDL文檔中，與部署端點的消息交換可以同時包含所有4類主題的有效政策。WS-Policy和WS-PolicyAttachment相結合可以提高應用程式來發現和推出其他服務所支援的政策的能力。添加政策的靈活性是對描述消息互動的WSDL資訊的一個重要補充。

WSDL和WS-Policy都定義了中繼資料格式，但都沒指定某一給定服務獲得或通路中繼資料的機制。一般來說，服務中繼資料可以通過使用許多方法來擷取。為了支援服務的自我描述，Web服務架構在WS-MetadataExchange中定義了基于SOAP的中繼資料通路協定。GetMetadata操作用于檢索在請求的端點引用中找到的中繼資料。Get操作類似，但用于檢索不同的中繼資料：在中繼資料部分引用，并要在存儲它的端點引用中檢索的中繼資料。

使用WS-MEX來交換的中繼資料可以描述為資源。資源即可由某一端點引用尋址的任何實體，并且在該端點引用中，該實體可以提供一種其自身的XML表示形式。資源構成了建構Web服務中的狀态管理所需的基礎。

什麼是互操作性概要（Interoperability Profile）

概要（Profile）是一組指導原則，主要針對于核心協定以及Web服務規範的使用。這些指導原則對于規範的通用設計來說是必需的。在某些情況下，開發人員需要額外的幫助來确定使用哪些Web服務特性來滿足某一特定需求。互操作性概要還用于解決Web服務規範不夠明确的領域中的含糊性問題，以確定所有實施都以相同的方式來處理SOAP消息。

WS-I基本概要

第一個Web服務概要是由Web服務-互操作性組織（WS-I，Web Services-Interoperability Organization）釋出的。WS-I已經完成了其第一個概要，并簡單地稱為基本概要1.0。該概要主要基于SOAP1.1和WSDL 1.0的互操作使用來提供指導原則。

安全性

本節介紹Web服務架構中用于提供某一系統内部的消息完整性、身份驗證和機密性、安全性令牌交換、消息會話安全性、安全政策表示和服務聯盟安全性的規範。提供這些特性的規範是WS-Security、WS-Trust、WS-SecureConversation、WS-SecurityPolicy和WS-Federation。

安全性是計算機系統的一個基本方面，尤其是那些由Web服務組成的系統。安全性必須是健壯而有效的。因為系統隻對消息格式和合法的消息交換作出硬體假設，是以安全性必須基于一緻通過的明确機制和假設。安全基礎架構還應該具有足夠的靈活性，以支援不同組織所需的不同安全政策。

當安全傳輸可用于通信Web服務，如安全套接層（SSL）和傳輸層安全性（TLS）之間時，建構安全性解決方案就得到了簡化。有了安全傳輸，這些服務就不需要參與單個消息的完整性和機密性的維護；它們可以依賴于底層傳輸。不過，現有的傳輸級安全性是一個僅限于點對點消息傳遞的解決方案。如果在使用安全傳輸時存在中介，則最初發送者和最終接收者需要相信這些中介能夠幫助提供端到端的安全性，因為每個網段都是安全的。除了要明确地信任所有中介外，還必須考慮到其他風險，如消息的本地存儲和中介受到損害的可能性。

為了最大限度地擴大Web服務的作用範圍，當通信端點不相信中介時，必須提供端到端的安全性，那就需要更進階别的安全協定。作為另一種選擇，端到端消息安全性比點對點傳輸級安全性具有更豐富的内涵，因為它支援Web服務所需的基于SOAP的松耦合、聯合、多傳輸和可擴充環境。這種功能強大而又靈活的基礎架構可以通過現有技術和Web服務協定的組合來開發，同時還可以緩解與點對點消息傳遞相關聯的許多安全風險。

盡管Web服務的安全需求很複雜，但人們還沒有發明新的安全機制來滿足基于SOAP的消息傳遞的需要。現有的分布式系統安全性方法，如Kerberos票、公鑰加密技術、X.509證書等已經夠用了。隻有應用現有的SOAP安全方法時，新機制才是必需的。這些新安全協定的設計充分考慮了可擴充性，以便将來能夠加入新的方法。一個主要的設計目标是要提供自我描述安全性屬性（為包括SOAP在内的Web服務架構而設計）機制。

Web服務安全性的基礎是輸入消息要證明一組關于發送者、服務或其他資源的斷言這一需求。我們稱之為斷言或安全性斷言。典型的安全性斷言包括身份、屬性、關鍵财産、權限或功能。這些斷言是用包裹在XML中的二進制安全性令牌編碼的。在傳統的安全性術語中，這些安全性令牌表示功能和通路控制的混合。很多方法都被用于建立安全性令牌。Web服務可以從本地資訊建構定制的安全性令牌。反過來，安全性令牌也可以從X.509認證機構或Kerberos域控制器等專業服務檢索。為了實作服務之間的通信自動化，需要一個表達安全需求的方法。

服務可以使用WS-SecurityPolicy中所指定的政策斷言來表達其安全需求。通過檢索這些政策斷言，應用程式可以建構符合目标服務需求的消息。斷言、安全性令牌和政策所提供的這組特性以及從Web服務檢索它們的能力非常強大。這種普通的Web服務安全模式支援一些更具體的安全模式，如基于身份的授權、通路控制清單和基于功能的授權。它允許使用現有技術，如X.509 公鑰證書、基于XML的令牌、Kerberos共享的秘密票和密碼摘要。這種普通模型對于建構使用更複雜的方法來進行更進階别的密鑰交換、身份驗證、基于政策的通路控制、稽核和處理複雜的信任關系的系統已經足夠。也可以使用代理和中繼服務。例如，可以建構中繼服務來加強位于信任邊界的安全政策；出界的消息被加密，而界内的消息不加密。以前的解決方案沒有提供這種靈活性和完善程度。附錄C中所描述的常見安全攻擊包含了系統威脅的基本分類，而這些系統威脅是在選擇Web服務安全特性時應認真加以考慮的。

本節的餘下部分将探讨Web服務安全模式的應用。兩個重要主題是安全通信和安全應用。沒有假定安全的消息傳輸，這也不是安全的Web服務所必需的。

消息完整性和機密性

消息級安全性是端到端安全性的關鍵構造塊。使用消息級安全性時，無需傳輸級安全性。對消息級安全性的要求是消息完整性、消息身份驗證和機密性。消息完整性確定消息不能在不知不覺中被更改。使用XMLSignature可確定消息的修改能夠被察覺。消息身份驗證可識别發送消息的主體。如果使用了公鑰加密，就可以确定主體的唯一身份。将公鑰加密與經受信任源認證的密鑰一起使用可以實作這種身份驗證。不過，如果使用了對稱密鑰加密，情況就不一樣了——隻有知道共享密鑰的主體才能被識别。消息機密性可確定在傳輸期間未經授權的第三方不能閱讀消息。SOAP消息是通過使用XMLEncryption [XMLENC]和安全性令牌來保證機密性的。

完整性、身份驗證和機密性機制将初始消息（或該消息的某些部分）作為輸入，将生成的資料（如校驗和）作為輸出。例如，在某種簡單情況下，XML元素的簽名可能會作為XML元素所有字元的散列的非對稱加密來實作。然後該加密散列可以存儲在該消息中，并在該消息中傳送。可以将XML文檔看作字元串。就像XML簽名一樣，逐字元地比較也是非常重要的安全性操作。一字之差會導緻不同的結果。串行化是用于表示“線上”對象的方法。例如，串行化可用于建立SOAP消息的XML表示。不同串行化軟體所導緻的任何無關緊要的排字差異都會被消息處理軟體忽略，但會對安全性軟體産生很大影響。XML消息的Infoset表示形式改進了這一問題。要使XML簽名生效，消息必須轉換成一個對所有方都是一緻的XML表單。規範化是一個術語，來描述用于生成一緻的換行符、制表間隔、屬性排序和結束标簽樣式等非關鍵資訊視圖的方法。簽名包含了用于使消息接收者能夠完全像發送者那樣處理安全資訊的規範化方法。某一服務所使用的特定的規範化方法是要放置在一個WSDL portType綁定或WSDL端口的有用的政策斷言。

WS-Security指定了消息完整性和機密性機制以及單一的消息身份驗證。對于消息完整性，該規範較長的描述了加密簽名是如何表示并與SOAP消息的特定部分關聯的。該方法允許任意格式良好的消息片段擁有單獨的簽名。與之類似，機密性是通過結構良好的消息片段的加密來實作。身份驗證是使用數字簽名來實作的。WS-Security規範描述了目前常用的安全機制，也沒有排除将來添加新機制的可能性。因為SOAP處理模型使用Header元素來作出處理決定，是以是決定SOAP消息中的哪些元素需要加密時一定要多加小心。

在決定要對哪些元素進行加密以及要使用哪些加密算法時，Web服務設計人員一定要清楚消息是如何處理的。當某些特定的Header元素需要由第三方或中介來處理時，這些決定就更為重要了。如果這些參與者對适當的解密資料或對在加密XML元素時所使用的約定毫無所知，它們将無法實作正确操作。此外，每個處理節點對消息中包含的安全資訊都必須有個一般的了解。加密某一Header中XML元素的一個自然選擇就是對它進行完全加密，用初始元素替代加密資料類型的元素。這種簡單的方法有些缺點。例如，中介不太好确定必須處理哪些元素（帶有mustUnderstand="1"屬性的元素）。另外，當元素類型發生變化時，确定其初始類型比較困難。另一種方法是對元素進行轉換，使得進行正确的SOAP處理所需的所有關鍵屬性都保持不變，且對初始元素進行了加密，并放在一個特殊的子元素中。這種方法的優點是即使不知道如何解密元素的中介也能實作正确的處理。這種方法的一個缺點是它要求所有參與者都了解用于表示初始元素的約定。盡管WS-Security目前沒有對這種方法提供指導，但我們預期将來會提供的。相比之下這種方法更好一些，因為它可實作所有SOAP Header元素的正确處理。

WS-Security的概要規範中描述了幾種安全性令牌。針對表示使用者名的令牌、X.509證書和基于XML的安全性令牌的概要都已經開發出來。基于XML的安全性令牌包括安全性斷言标記語言（SAML，Security Assertion Markup Language）和可擴充權限标記語言/權限表達語言（REL，Rights Expression Language）。Kerberos票的使用規範還未成型。

WS-I基本安全概要

WS-I将要釋出的最新的互操作性概要之一是基本安全概要（BSP，Basic Security Profile）。該概要提供了WS-Security和各種安全性令牌，如Username和X.509證書令牌的實作指導。該概要用于補充和完善WS-I基本概要。

基于安全令牌的信任

安全性令牌是提供端到端安全解決方案所必需的。這些安全性令牌必須在消息處理的參與者之間實作直接或間接共享。各參與者還必須确定斷言的憑證是否可信。這些信任關系以安全性令牌的交換和代理為基礎，并存在于已經确定的支援信任政策中。例如，某一代理的令牌有多少可信，是由系統管理者和他們确定的信任關系決定的。提供安全性令牌的服務五花八門。這是各種底層安全技術首先為Web服務所使用的領域。為了提供一種與安全技術無關的統一标準的解決方案，新協定是為信任域之間的安全性令牌交換而設計的。

WS-Trust以用于請求、發出和代理安全性令牌的協定對WS-Security進行了補充。需要特别指出的是，其中定義了用于擷取、發行、更新和驗證安全性令牌的操作。該規範的另一個新特性是建立新信任關系的機制。IPsec或TLS/SSL之類的網絡和傳輸保護機制可以與WS-Trust結合，以适應不同的安全性需求和情況。

安全性令牌可以直接從某一适當的發行者處申請獲得，或者通過委托某一受信任的第三方來擷取。令牌還可以出乎意料地獲得。例如，令牌可以從某一安全權威機構發送到一個并未明确申請該令牌的某一方。為此，系統管理者要确定初始信任關系，如将某一給定服務指定為信任的根服務。這種方法類似于目前Web上用于自展安全性的方法。從該服務獲得的所有令牌受信任的程度與受信任的根服務本身相同。例如，如果某根服務隻有斷言A和B得到信任，且某一消息包含斷言A、B和C，則該消息中隻有斷言A和B得到信任。配置靈活性是通過信任關系授權提供的。為了處理在退回或發出安全性令牌之前需要各方之間的一個交換集的情況，定義了用于驗證、協商和交換的方法。一種稱為“challenge”的特殊形式的交換為某一方證明它擁有與某一令牌關聯的密鑰提供了一種方法。交換的其他類型包括傳統的協定隧道。WS-Trust詳細說明了如何擴充該規範，以支援更多的令牌交換協定，而不僅僅是所給出的這兩個例子。

表示安全性斷言的安全性令牌是由一個受信任根或一個通過一個授權鍊的根發行的。這些安全性斷言用于驗證消息符合正在施行的安全政策。它們還驗證斷言者的屬性是通過簽名來校驗的。在代理的信任模式中，即由受信任的中介配置設定安全性令牌的模式中，簽名可能不驗證斷言者的身份，而驗證中介的身份。該中介可能隻斷言者的身份。

安全會話

用于消息身份驗證和機密性的某些機制可能會耗用大量的資源。需要特别指出的是，許多加密技術都會顯著消耗處理能力。當消息的安全性是逐一得到保證時，這些代價通常是無法避免的。不過，當兩個Web服務進行許多消息的交換時，可以使用比WS-Security中定義的方法更為高效和健壯的消息機密性方法。這些方法是基于對稱加密的，在保證消息會話的安全時應使用它們。

WS-SecureConversation在基于共享密鑰（如對稱加密）的兩個通信方之間定義了一個安全上下文。在整個會話期内，安全上下文在各通信方之間始終是共享的。會話密鑰由共享密鑰派生而來，用于解密在會話中發送的單個消息。安全上下文線上表示為一個新的安全性令牌類型（即SCT ，Security Context Token）。

規範為建立安全會話各方之間的安全上下文定義了3種不同方法。第一種，由安全性令牌服務建立，且必須由會話發起方提取并傳送。第二種，通信一方建立安全上下文并通過消息傳遞給另一方。第三種，通過協商和交換建立安全上下文。Web服務會選擇最能滿足其需要的方法。必要時可以對安全上下文進行修正。更新安全上下文的一個典型例子是延長安全上下文的截止時間。安全上下文令牌隐含或包含了一個共享密鑰。該密鑰用于簽名、加密消息。當使用共享密鑰時，通信各方可以選用不同的密鑰派生模式。例如，可以派生出4個密鑰，這樣雙友善可以使用單獨的密鑰來簽名和加密消息。為了保證密鑰未曾用過和保持高度的安全性，應使用後續的派生密鑰。使用這種方法來保證會話的安全性是一種更好的選擇。WS-SecureConversation規範定義了一種方法來訓示給定消息正在使用哪些派生密鑰。所有派生算法都是通過URI來識别的。

安全政策

WS-SecurityPolicy通過用一種符合WS-Policy的語言指定安全政策斷言來完善WS-Security，其6種斷言涉及安全性令牌、消息完整性、消息機密性、消息對SOAP中介的可見性、對安全Header的限制和消息壽命。例如，某一政策斷言可能要求所有消息都使用某一權威機構提供的公鑰來簽名，或該身份驗證要基于Kerberos票。

系統聯盟

除了我們已經介紹的方法以外，應用程式安全性還需要更多的方法。例如，在某一信任域中有效的身份在其他信任域中很可能沒有意義。要讓不同信任域中的服務能夠驗證身份的有效性，就需要适當的機制。WS-Federation定義了一些機制，以支援身份、帳戶、屬性、身份驗證和身份驗證資訊跨信任域的共享。利用這些機制，多個安全域可以通過在由多方參與的Web服務之間支援和代理身份、屬性和身份驗證的信任而結成聯盟。該規範擴充了WS-Trust模型，使屬性和筆名可以被整合到令牌發行機制中，進而形成一種多域身份映射機制。這些機制都支援單點登入、退出和筆名，并描述了專業服務對于屬性和筆名的作用。

通過身份聯盟，很多要求都可以得到滿足。就拿将一名員工與其雇主關聯起來的例子來說，公司A的Jane從OfficeSupplyStore.com進行采購，公司A和OfficeSupplyStore.com之間有一個采購合同。因為Jane的身份是與公司A關聯的，是以可以讓她來依據該合同來進行采購。第二個例子是将一個人映射到多個筆名。大家可能隻知道Joe使用[email protected]工作。他還可能有其他身份，如joe_b[email protected]和[email protected]。通過身份聯盟，系統可以确定這些身份都是同一個Joe。

Web服務聯合安全架構中定義了兩個一般的請求者（消息發送者）類：被動和智能（活動）。被動請求者是隻使用HTTP且從來不發出安全性令牌的服務。智能請求者是能夠發出包含諸如WS-Security和WS-Trust中所描述的那些安全性令牌的消息的服務。傳統的基于HTTP的Web浏覽器就是被動請求者的一個例子。定義這兩種請求者的行為的概要規範現已開發出來。對于智能請求者，active請求者概要詳細說明了單點登入、退出和筆名是如何通過使用SOAP消息而整合到Web服務安全模型中的。實際上，該概要描述了在智能請求者上下文中實作WS-聯盟中所描述的模式的方法。它詳細說明了各種安全性令牌的要求。作為這些安全性令牌要求中之一的一個例子，當不使用安全通道時，X.509證書的整個令牌必須包含權威機構的名稱和簽名。該概要還要求X.509令牌包含主題辨別符，以唯一地識别授之以該令牌的主題。

發現（Discovery）

本節介紹Web服務架構中用于定位網絡上Web服務和确定該服務可用性的功能元件：UDDI和WS-Discovery。Web服務發現是在沒有人工幹預的情況下實作服務連接配接自動化的關鍵。Web服務發現方法反映了計算機系統中查找資訊的兩個最常見方法：檢視一個衆所周知的目錄，或将一個請求廣播給所有可用的監聽器。UDDI系統資料庫就相當于該目錄，發現協定用于廣播請求。

目錄（Directory）

通用描述發現和內建協定，即UDDI——Universal Description Discovery and Integration Protocol，指定了一個用于查詢和更新Web服務資訊通用目錄協定。該目錄包含關于服務提供商、它們所托管的服務以及這些服務所實施的協定的資訊。該目錄還提供了用于向任何注冊資訊添加中繼資料的方法。如果Web服務資訊存儲在衆所周知的位置時，則可以使用UDDI目錄方法。一旦找到目錄，就可以發送一系列查詢請求以擷取想要的資訊。UDDI目錄位置通常是通過系統配置資料從帶外（Out of Band）獲得的。

對于如何部署UDDI系統資料庫，Web服務提供商有很多不同的選擇。部署方案不外乎3個類别：公共、企業外和企業内。為了支援公共部署，以Microsoft、IBM和SAP為首的一組供應商主持推出了UDDI企業系統資料庫[UBR，UDDI Business Registry]。UBR是一個可跨多個主持企業複制的公共UDDI系統資料庫，它既是基于Internet的Web服務資源，又是Web服務開發者的一個試驗台。盡管目前公共UDDI實施已經受到了最大關注，但UDDI的早期采用者仍更傾向于使用企業外和企業内方法。在這兩種部署情況下，企業要部署一個專用系統資料庫，而且更嚴密地控制注冊資訊類型也是可能的。這些專用系統資料庫可能隻供一個企業使用，也可能供若幹組業務合作夥伴使用。UDDI還為系統資料庫間的複制和跨部署的信任聯盟定義了協定。使用這些協定進一步增加了可用于實施者的部署方案數量。對于所有的部署方案，UDDI目錄都包含了Web服務及其托管地的詳細資訊。UDDI目錄項有3個主要部分——服務提供商、所提供的Web服務和實施綁定。其中的每一部分都逐漸提供有關Web服務的更詳細資訊。

大部分的一般資訊都描述服務提供商。該資訊不針對Web服務軟體，而是針對直接負責該服務的開發者或實施者。服務提供商資訊包括名稱、位址、聯系人及其他管理細節。所有的UDDI項都有多個元素來支援多語言描述。可用的Web服務清單存儲在服務提供商項中。這些服務可能是根據它們的預定用途來組織的：它們可能被分成不同的應用領域、地區或任何其他适用的模式。存儲在UDDI系統資料庫中的服務資訊隻包含服務描述和一個指向它所包含的Web服務實施的指針。由其他提供商托管的服務連結稱為‘服務映射（Service Projection）’，也可能被注冊。

UDDI服務提供商實體的最後部分是實施綁定。該綁定将Web服務項與确切的URI關聯起來，以确定在何處部署服務，它還指定了通路協定，并包含所實施的确切協定的參考資料。這些細節對于開發人員編寫調用Web服務的應用程式已經足夠。詳細的協定定義的是通過一個稱為“類型模型（即tModel，Type Model）”的UDDI 實體提供的。在許多情況下，tModel都會引用一個描述SOAP Web服務接口的WSDL檔案描述，但tModel的靈活性也幾乎可以描述任何種類的資源。對于在UDDI中注冊的每一個提供商或服務來說，來自标準分類學（如NAICS和較古老的美國标準行業代碼）或其他身份識别方案（如Edgar Central Index Key）的中繼資料都可用于分類資訊和提高搜尋準确性。可用的分類學和辨別符方案集作為任何實施的一部分，是可輕松擴充的，是以可以對其進行定制以支援任何特定的地域、行業或企業需求。

動态發現（Dynamic Discovery）

動态Web服務發現是以不同方式提供的。作為在已知系統資料庫中存儲資訊的另一種方案，動态發現的Web服務會明确地聲明它們的到達、離開網絡。WS-Discovery為通過多路廣播消息來聲明和發現Web服務定義了協定。當Web服務連接配接到網絡時，它通過發送一條Hello消息來聲明它的到達。在最簡單的情況下，這些聲明的跨網發送使用多路廣播協定——我們稱之為自組織網絡。該方法還最大限度地減少了網絡上的輪詢需要。為了限制網絡資訊流通量和優化發現過程，系統可能會包含一個發現代理。發現代理用一個衆所周知的服務位置取代了發送多路廣播消息的需要，進而将自組織網絡轉變成托管網絡。利用配置資訊，代理服務集合可以連接配接在一起，進而将發現服務擴充到多組伺服器，從一台機器擴充到多台機器。

因為發現代理自身也是Web服務，它們可能會用自己專用的Hello消息來聲明它們的到場。接收該消息的Web服務然後可以利用該代理的服務，而無需再使用幹擾較多的一對多發現協定。當服務離開網絡時，WS-Discovery會指定一個Bye消息以發送給網絡或發現代理。該消息通知網絡上的其他服務離開的Web服務不再可用。

為了完善這種服務聲明和離開的基本方法的不足，WS-Discovery定義了兩個操作——Probe和Resolve，以定位網絡上的Web服務。對于自組織網絡，Probe消息被發送給多路廣播組，并且與該請求比對的目标服務會将響應直接回報給請求者。對于利用發現代理的托管網絡，Probe消息則以單路廣播方式發送給發現代理。如果按名稱定位Web服務，則使用Resolve消息。Resolve消息隻以多路廣播模式發送。Resolve 類似于位址解析協定，即ARP，它将IP位址轉換成其對應的實體網絡位址。WS-Discovery規範還支援這樣的系統配置：将Probe消息發送給一個已經通過其他管理方法建立起來的發現代理，如通過使用衆所周知的DHCP記錄。

動态發現服務的能力實作了Web服務管理的自舉。與WS-Eventing及其他協定相結合，更複雜的管理服務也可以通過使用這種動态發現基礎架構來建構。動态發現還将Web服務架構擴充到裝置，如那些目前可能實施通用即插即用（UPnP）協定的系統——這是使該架構真正實作通用的重要一步。例如，借助WS-Discovery和WS-Eventing，列印機或存儲媒體等裝置可以作為Web服務納入到系統中，而且無需專門的工具或協定。

Web服務裝置概要規範

Web服務裝置概要規範對在資源受限的裝置上應該實施Web服務架構規範家族的哪個子集提供了指導。該概要力圖在由于資源限制而作出折衷時，在可用的豐富功能和最重要的功能之間找到平衡。

一緻性協定——可靠的消息傳遞和事務

本節介紹可以提供可靠的消息傳送、事務行為和能夠在一組Web服務之間進行顯式協調的Web服務架構元件。定義這些功能的規範是WS-ReliableMessaging、WS-Coordination、WS-AtomicTransaction和WS-BusinessActivity。

當多個Web服務必須完成工作的某一共同單元或依照某種共同的行為進行操作時，對于使用哪個協定必須達成共識。Web服務之間這種最低限度的協調是不可避免的。協調協定還必須能夠确定并同意已達成一個共同目标。Web服務之間的每一個互動都可以看作一種協調。一緻性協定為該架構提供了一個改進的機會，即參與者服務在它們準備共同完成的任務方面将獲得成功。在傳輸丢失了消息和服務失常時，Web服務架構仍然能夠正常工作。

任何多方協調都可以通過接連地随需加入更多參與者從兩方協調逐漸發展而成。兩方協調可能是自發的，也可能需要一個指定的協調者。廣泛使用的自發協調協定的一個例子是同步請求—響應消息傳遞模式。這是一緻性協調的最簡單形式之一；對于每個工作請求，接收方Web服務必須完成所有預期工作之後才能向請求者傳回資料。雙方都遵循這種嚴格的模式，無需顯式協調服務。

可靠的消息傳遞

很多情形都可能中斷兩個服務之間的消息交換。當使用不可靠的傳輸協定（如HTTP 1.0和SMTP）來進行傳輸或當消息交換跨多個傳輸層連接配接時，這更會成為一個問題。消息可能會丢失、被複制或重新排序，Web服務可能會失敗并失去易變狀态。WS-ReliableMessaging是一個基于特定的傳送保證特征實作可靠消息傳送的協定。該規範定義了3個可結合使用的不同斷言：

At-Least-Once Delivery（至少一次傳送）：每條消息至少傳送一次。
At-Most-Once Delivery（至多一次傳送）：不傳送重複的消息。
In-Order Delivery（依次傳送）：按消息的發送順序傳送消息。

至少一次和至多一次保證相結合的結果是恰好進行一次傳送。由于Web服務架構的設計與傳輸無關，是以所有傳送都與所用的通信傳輸工具或其組合無關。由于開發人員必須預測的潛在傳送失敗模式數量減少，故使用WS-ReliableMessaging可以簡化系統開發。

可靠的消息傳送不需要顯式協調者。當使用WS-ReliableMessaging時，參與者必須根據SOAP消息Header中所發送的資訊識别協定。作為一個組傳輸的消息集合稱為消息序列（Message Sequence）。消息序列可以由發起者/發送者或Web服務建立，當建立一種雙向關聯時通常由它們共同建立。序列是使用CreateSequence和CreateSequenceResponse消息顯式建立的。當想要的最終結果是用兩個單向序列來充當一個雙向序列時，發起者将提供Web服務所要使用的序列。該序列的ID由發起者包含在CreateSequence消息中。

WS-ReliableMessaging中定義了幾個政策斷言。這些政策斷言用WS-Policy中定義的方法來表示。

可靠的消息傳遞協定簡化了開發人員為在傳輸不斷變化的情況下傳輸消息而必須編寫的代碼。也就是說，底層基礎架構可以對消息在端點之間的正常傳輸進行驗證，必要時還會轉發消息并檢測重複。應用程式不需要任何附加邏輯來處理提供傳送可能需要的消息轉發、重複消息的消除、消息重新排序或消息确認。WS-ReliableMessaging的實施是跨發起者和服務分布的。那些非‘線上’可見的特征，如消息傳送順序，是通過實施WS-ReliableMessaging規範來提供的。雖然由傳輸損失導緻的消息重發等特征是通過不為應用程式所知的消息傳遞層來處理的，其他端到端特征（如依次傳送）都要求消息傳遞基礎架構和接收應用程式互相協作。當發送者希望按發送順序提供消息排序時，在接收者一方卻按接收順序提供消息排序的情況是依次傳送的一種不正确實施——注意到這一點是很有趣的。當發送者希望按接收順序提供消息順序時，在接收者一方按發送順序提供消息順序的情況，是依次傳送的一種正确實施。

指定的協調者

N路協調協定的某些族需要一個指定的協調者來引導一個工作單元通過一系列合作服務，一個例子是活動必須在不希望被同時連接配接的服務之間協調。隻要每個參與者和協調者在某一時刻通信，協調就可能發生，結果就可能達成一緻。Web服務架構為指定的協調者定義了某些簡單操作。

WS-Coordination規範定義了一個可擴充的協調架構來支援需要顯式協調者的情況。該協定引入了一個稱為協調上下文（Coordination Context）的SOAP頭塊，用以唯一地識别聯合工作中将要着手進行的部分。為了啟動工作的接合部分，Web服務會向一個或多個目标服務發送協調上下文。收到協調上下文後，接收方服務會得到提示，說有聯合協作請求提出。協調上下文中包含了足夠的資訊，請求接收者可以利用這些資訊來确定是否參與該工作。協調上下文中包含的确切資訊根據被請求工作的種類的不同而變化。

協調類型集是可擴充的。隻要參與該聯合工作的每個服務對所需行為都有個一般的了解，新類型就可以通過實施來定義。例如，原子事務是Web服務架構中已經定義了的幾個初始基礎協調類型之一。如果被請求的協調類型被了解并被接受，Web服務就會使用WS-Coordination注冊協定來通知協調者并參與該聯合工作。協調上下文中包含了協調者的一個端點引用和可能行為的可選辨別符。注冊操作指定該多方參與的Web服務所支援的行為。一旦注冊消息發送到協調者，Web服務就會依照它們所預訂的協定參與該工作。注冊是協調架構中的關鍵操作，它允許意欲協同配合以完成工作的共同單元的不同Web服務互相連接配接在一起。

WS-AtomicTransaction為Web服務指定了傳統的ACID事務，并為原子事務協調類型定義了3個協定：完成協定（Completion Protocol）和兩階段送出協定（Two-Phase Commit Protocol）的兩個變體。完成協定用于啟動送出處理。為完成而注冊的Web服務能夠通知指定的協調者何時開始送出處理。該協定還詳細說明了用于通知啟動者事務最終結果的消息。不過，該協定不要求協調者確定啟動者對結果進行處理。相反，WS-AtomicTransaction中的其他行為則要求協調者確定參與者對協調消息進行處理。

兩階段送出（2PC）協定為所有已注冊的參與者提供了一個公共的送出或中止決定，確定了所有參與者都能得到最終結果通知。顧名思義，它使用兩輪通知來完成該事務。該協定的兩個變體是：易失2PC（Volatile 2PC）和持久2PC（Durable 2PC）。這兩個協定線上上使用相同的消息（對應于Prepare、Commit和Abort操作），但易失2PC沒有持久性要求。易失2PC協定供管理易失資源的參與者使用，如緩存管理器或視窗管理器。這些參與者在第一輪通知中不與協調者發生聯系，且不需要第二輪的通知。持久2PC協定供管理資料庫和檔案等持久資源的參與者使用。當某一送出處理已經啟動時，在所有易失2PC參與者被聯系過之後這些參與者會第一次被聯系。這使緩存能夠被重新整理。持久2PC參與者需要完整的兩輪通知來實作協調者所要求的全有或全無行為以及完成該事務。這些行為最适合于可以在整個事務期内持有資源，且該事務通常為非常短暫的事務的情況。該協定保證在正常處理的情況下，協調者提供第一階段結果的同時将聯系所有參與者。對于完成時間預計将比較長的事務，或當資源（如鎖）無法持有時，其他協調協定就會定義替換行為。

WS-AtomicTransaction中定義了若幹政策斷言，這些政策斷言使用WS-Policy中定義的方法來表示。

排隊系統（Queued System）

建構分布式系統時被證明非常有用的一種模式是使用事務持久隊列來提供存儲轉發異步消息傳送。在這種模式下，原子事務被用于每一個傳輸端點。在發送端，發送應用程式以原子事務方式将消息發送給一個持久隊列，此時應用程式和隊列管理器都使用WS-AtomicTransaction來進行協調。隻有在處理消息時不發生錯誤，消息才被認為成功發送至該隊列。接下來，發送隊列和接收隊列之間消息的傳送由隊列子系統來接管。該傳輸步驟可以在消息置入發送隊列之後的某一時刻完成。此外，發送隊列的位置無需與發出消息的應用程式的位置一緻。與此類似，從接收隊列檢索消息的應用程式也使用原子事務來執行類似操作。也就是說，隻有不出現處理錯誤時消息才能從隊列中移除。

持續時間長的活動（Long Duration Activities）

WS-BusinessActivity為運作時間長的事務指定了兩個協定。WS-BusinessActivity規範在事務送出之前并不鎖定資源，而是基于補償操作。底層事務模型是所謂的開放嵌套事務。這些協定系統化地說明了松耦合服務如何對已經完成某一聯合任務達成一緻意見。在其中的一個協定中，協調者顯式地通知參與者沒有更多的工作正在以聯合任務的名義被請求。在另一個協定中，該參與者就是通知協調者以聯合任務名義出現的工作已經完成的參與者。使用補償操作可以在不鎖定這些操作的情況下完成試驗性操作。不管出于何故，隻要系統想要撤消已完成的試驗性操作結果，就要啟動補償操作。WS-AtomicTransaction和WS-BusinessActivity都利用WS-Coordination來管理Web服務之間的協作。

三方握手

三方握手連接配接的建立和解除協定是不需要指定協調者服務的協調協定的一個例子。為了建立連接配接，發送者要向接收者發送一個請求。該請求建立一個會話。如果該請求被接受，接收者就會發出一條确認消息，對該請求作出積極響應。發送者然後再發送一條消息，作為對該确認消息的确認，進而證明雙方都知道對方已經建立了一個會話。

解除協定類似。一方向另一方發送一個會話解除請求。接收者以對解除消息的确認消息作為響應。接收到該确認消息之後，發出解除消息的一方通過再對該确認消息發送一條确認消息結束消息交換。

枚舉、傳輸和事件

本節介紹提供Web服務架構中的服務資源枚舉、其狀态管理和事件通知的規範。這些規範基于WS-Enumeration、WS-Transfer和WS-Eventing。

枚舉（Enumeration）

很多情況所要求的資料交換都使用不隻一對的請求/響應消息。需要這些更長時間資料交換的應用類型包括資料庫查詢、資料流、命名空間等資訊的周遊和枚舉清單。特别是枚舉，它是通過建立資料源和請求者之間的會話來實作的。會話中接連不斷的消息用于傳送正在被檢索的元素的集合。對于該服務用于組織将要生成的項的方法不作假設。在正常處理的情況下，枚舉應在會話結束前生成所有底層資料。

WS-Enumeration指定了用于建立枚舉會話和檢索資料序列的協定。枚舉協定允許資料源向正在使用的服務提供一個叫做枚舉上下文的會話抽象。該上下文通過一個資料項序列來表示邏輯光标。然後，請求者将該枚舉上下文用于一個或多個SOAP消息的某一區間以請求資料。枚舉資料表示為XML Infoset。該規範還允許資料源提供一種自定義機制來開始新的枚舉。既然枚舉會話可能需要若幹個消息交換，那麼會話狀态必須保持穩定。

關于疊代進度的狀态資訊可以由資料源或正在使用的服務在請求間維護。WS-Enumeration允許資料源一個請求一個請求地決定哪一方将負責維護下一個請求的狀态。這種靈活性實作了若幹種優化。例如，使伺服器能夠避免對調用之間的任何光标狀态進行儲存。由于消息潛伏時間對于支援若幹個同時枚舉的服務來說可能會很長，不儲存狀态可能會使必須維護的資訊總量大大減少。資源受限裝置（如行動電話）上的服務實作可能根本無法維護任何狀态資訊。

傳輸（Transfer）

WS-Transfer詳細說明了對通過Web服務進行通路的資料實體進行管理所需的基本操作。要了解WS-Transfer需要介紹兩個新術語：工廠（Factory）和資源（Resource）。工廠是能夠從其XML表示形式建立資源的Web服務。WS-Transfer引入了用于建立、更新、檢索和删除資源的操作。應當注意，對于資源狀态維護，宿主伺服器最多也隻能做到盡力而為。當用戶端獲知伺服器接受了建立或更新某一資源的請求時，它可以适當地預期資源目前在的确定位置，并具有确定了的表示形式，但這并不是一個保證——即使是在沒有任何第三方的情況下。伺服器可能會更改某一資源的表示形式，可能會徹底删除某一資源，也可能會恢複已經删除的某一資源。這種保證的缺乏與Web提供的松耦合模型一緻。如果需要，服務可以提供非Web服務架構所必需的附加保證。

WS-Transfer的建立、更新和删除操作擴充了WS-MetadataExchange中的隻讀操作功能。檢索操作與WS-MetadataExchange中的Get操作完全相同。Create請求發送給工廠。然後，工廠建立被請求的資源并确定其初始表示形式。工廠被假定與所建立的資源不同。新資源被配置設定給一個在響應消息中傳回的，由服務決定的端點引用。Put操作通過提供一種替換表示形式來更新資源。資源表示形式的一次性快照與WS-MetadataExchange中的Get操作一樣，也可以通過WS-Transfer中的Get操作來檢索。Delete操作成功後，資源将無法再通過端點引用來使用。這4個中繼資料管理操作構成了Web服務中狀态管理的建構基礎。

事件（Eventing）

在由需要互相通信的服務構成的系統中，可能會使用異步消息傳遞。在很多情況下，由一個服務生成的資訊也是其他服務所需要的。由于伸縮性差，輪詢往往不是獲得這種資訊的有效方法；通過網絡發送的不必要的消息太多了。相反，該架構需要一種當事件發生時發出顯式通知的機制。更重要的要求是源服務和使用者服務的綁定必須在運作時動态完成。為此，Web服務架構提供了一個輕量級事件協定。

WS-Eventing詳細說明了實作下面4個實體互動的機制：訂戶、訂閱管理器、事件源和事件接收。這使某一Web服務在作為一個訂戶時能夠登記它對另一個Web服務（事件源）所提供的特定事件的興趣。這種注冊叫做訂閱。WS-Eventing定義了某一服務可以提供的支援訂閱建立和管理的操作。當事件源判定有事件發生時，它就會将此資訊提供給訂閱管理器。訂閱管理器然後可以将該事件傳送給所有比對的訂閱，這類似于傳統的釋出/訂閱事件通知系統中的釋出主題。Web服務架構提供了主題定義、組織和發現方式的全面靈活性；它為在很多不同的應用場合中可能會用到的訂閱提供了一個通用的管理基礎架構。也可以訂閱出租的資源，但最終都必須收回。用于收回資源的主要機制是各個訂閱的到期時間。查詢訂閱狀态同樣也有一種機制，幫助訂戶管理其若幹訂閱事項（包括續訂、通知和取消訂閱的請求）的附加操作規範中也有詳細說明。當然，任何服務都可以随時自由地終止訂閱，這與所有Web服務的自主原則一緻。訂閱終止消息可供事件源通知訂戶訂閱終止過早。

雖然基于事件的異步消息的一般模式很常見，但不同的應用通常都要求使用不同的事件傳送機制。例如，在某些情況下簡單異步消息可能是最佳選擇，但如果事件接收能夠通過輪詢控制消息流和消息到達時間，則其他情況可能會更适用。當接收無法從源頭到達目的地時，如接收有防火牆阻攔的情況下，輪詢也是必要的。WS-Eventing中所引入的傳送模式概念就是用來支援這些要求的。傳送模式被用作一個擴充點，以便為訂戶、事件接收和事件源建立定制的傳送機制提供一種手段。下述管理規範利用了這種機制。

事件代理可用于聚合或重新配置設定來自不同來源的通知，代理還可以用作獨立的訂閱管理器。這兩個方法都得到了WS-Eventing的支援。代理在系統中可以扮演若幹個重要角色。主題可以按特定的應用類來組織使用。代理可以充當通知聚集器，用于整合來自多個來源的事件資訊。它們也可以充當過濾器，這比用于其自己通知的過濾器所接收的消息要多。這種靈活性是部署健壯而可伸縮的通知系統所必需的。

管理（Management）

管理功能是要讨論的Web服務架構的最後一個方面。這些功能在WS-Management規範中有詳細的說明。WS-Management建構于該架構的若幹元件之上，提供了所有系統管了解決方案都必需的一個公共操作集。其中包括發現管理資源存在及其互相導航的能力。個别管理資源（如設定和動态值）可以被檢索、設定、建立和删除。容器和集合的内容，如大表和日志，可以被枚舉。規範最後定義了事件訂閱和特定的管理操作。在這些方面，WS-Management隻詳細說明了最低的實作要求。規範還使符合WS-Management的實作可以部署到小型裝置。同時，它還支援向大型資料中心和分布式安裝的擴充。此外，各種機制的定義都不依賴于任何暗示的資料模型或系統健康模型。這種獨立性使它可以應用到各種各樣的Web服務。

WS-Management要求托管資源的引用使用帶有特定附加資訊的端點引用。該資訊包含了對該資源提供通路的代理的URL、該資源所屬資源類型的唯一辨別符URI以及識别該資源的零個或更多個密鑰。這些密鑰被假設為名稱/值對。該資訊是這樣映射到WS-Addressing端點引用的：資源的URL映射到位址屬性，資源類型辨別符映射到一個名為ResourceURI（在适當的XML命名空間中）的特定引用屬性，各密鑰分别映射到一個名為Key、屬性為Name的引用參數。為了滿足管理服務的消息傳遞需要，規範為操作定義了3個限定符。這些限定符的SOAP表示位于header元素中。operation timeout指定了一個截止時間，之後操作将不需要接受服務；locale元素在需要或期望轉換底層資訊時使用；freshness限定符用于請求最新的值并避免傳回陳舊資料。對于使用WS-Transfer操作的資料通路，WS-Management指定了另外3個限定符。Get操作可用于SummaryPermitted header和NoCache header。如果可用，SummaryPermitted限定符允許傳輸簡略表示形式。NoCache限定符要求傳輸最新資料，禁止資訊緩存。對于Put和Create操作，ReturnResource限定符要求服務傳回資源的新表示形式。ReturnResource使資源受限的Web服務能夠在更新資源時不保留狀态。

WS-Management為事件通知定義了3個自定義的傳送模式：批、拉和捕獲。這些模式都由URI來識别，這些URI在建立訂閱時使用。批傳送模式使訂戶能夠接收捆綁在一個SOAP消息中的多個事件消息。訂戶可能還會要求捆綁某一最大數目的事件、服務收集事件可耗用的最長時間，以及應傳回資料的最大量。拉傳送模式使生成服務的資料能夠維護事件的邏輯隊列，以便訂戶能夠按需輪詢通知。該輪詢是通過使用WS-Enumeration和傳回時附帶訂閱響應消息的枚舉上下文來完成的。最後，如果UDP多路廣播是一種合适的消息傳遞方式，捕獲傳送模式便允許事件源使用它。在捕獲模式下，事件源可以将其通知發送給某一預定義的UDP多路廣播位址。

結束語

本文介紹了Web服務架構的功能構造塊及其底層原理。每個構造塊都是依據協定規範來闡述的。我們希望本文所述的功能範圍和指導原則保持不變。不過我們也希望架構能夠得到擴充，以支援更多情況。能夠支援創新是該架構的基本特征。

已經進行的大量細緻入微的工作可以確定各種Web服務協定能夠不加變動地互相組合；盡管是一起設計的，它們仍可以以非常多的組合方式來使用。和功能構造塊一樣，它們的使用方式與傳統開發架構類似。必要時，如對于SOAP附件，我們已經開發了新的解決方案，而且不加變動它們就可以很好地用于該架構内。關注組合不是對豐富功能的威懾。

該架構的SOAP消息傳遞基礎保證了 foundation assures wide reach。SOAP消息傳遞以一種傳輸獨立的方式支援異步和同步模式。具有更高靈活性的基礎架構不存在。為了加快Web服務架構的廣泛采用，很多技術合作夥伴都參與了這些規範的制定。與這些重要技術提供程式的合作加快了裝置和支援這些線上協定的程式設計環境的部署。實作廣泛覆寫、廣泛采用和與規模無關的構造是我們的3個核心目标。我們力争確定該架構能夠在任何平台上用任何程式設計語言來實作。該架構基于消息的和基于協定的特性為此提供了便利。必要時，如隻使用WS-Security來支援消息完整性、機密性和身份驗證，以及隻使用WS-Policy來表示中繼資料時，我們已經限定了用于提高互操作水準的技術方法的使用領域。理論上講，隻要實作切實遵守該架構的協定規範，它們就能與其他任何Web服務通信。

附錄A：術語表

活動請求者（Active Requestor）——活動請求者是能夠發出如WS-Security和WS-Trust中所述的Web服務消息的應用程式（可能是Web浏覽器）。

身份驗證（Authentication）——驗證安全憑證的過程。

授權（Authorization）——根據提供的安全憑證授權通路安全資源的過程。

規範化（Canonicalization）——将XML文檔轉換成符合每一方要求的格式的過程。在簽名文檔和解譯簽名時使用。

斷言（Claim）——斷言是對發送者、服務或其他資源（如名稱、身份、密鑰、組、特權、功能等）所作的陳述。

協調上下文（Coordination Context）——一組協調服務要完成的一組工作的唯一辨別符。

反序列化（Deserialization）——從一個八位位元組流建構XML Infoset的過程。它是用于從消息的有線格式建立消息的Infoset 表示形式的方法。

摘要（Digest）——摘要是八位位元組流的加密校驗和。

域（Domain）——安全域代表安全管理或信任的一個單元。

持久的兩階段送出（Durable Two Phase Commit）——用于檔案或資料庫等持久資源事務的協定。

有效政策（Effective Policy）——有效政策，針對某一給定的政策主題，是附加在包含該政策主題的政策範圍上的政策組合。

交換模式（Exchange Pattern）——用于服務之間消息交換的模式。

工廠（Factory）——工廠是可以從XML表示形式建立資源的Web服務。

聯盟（Federation）——聯盟是已經建立互相信任的信任域的集合。信任級别可能變化，但通常都包括身份驗證，并可能包括授權。

身份映射（Identity Mapping）——身份映射是建立身份屬性之間關系的一種方法。某些身份提供程式可能會利用身份映射。

身份提供程式（IP，Identity Provider）——身份提供程式是為最終請求者提供身份驗證服務的實體。身份提供程式還為服務提供程式提供資料源驗證服務（這通常是安全性令牌服務的一種擴充）。

消息（Message）——消息是可由服務發送或接收的完整資料單元。它是資訊交換的獨立單元。無論何時消息都會包含SOAP信封，并有可能包含附加MTOM中指定的MIME部件、傳輸協定header。

消息路徑（Message Path）——遍布在初始源和最終接收者之間的SOAP節點集。

被動請求者（Passive Requestor）——被動請求者是一個使用得到普遍支援的HTTP（如HTTP/1.1）的HTTP浏覽器。

政策（Policy）——政策就是政策選項集。

政策選項（Policy Alternative）——政策選項就是政策斷言集。

政策斷言（Policy Assertion）——政策斷言表示特定于域的單個要求、功能、其他屬性或行為。

政策表達式（Policy Expression）——政策表達式是政策的XML Infoset表示形式，可以是正規形式，也可以是等同的壓縮形式。

主體（Principal）——可以被授予安全權限或可以給出安全性或身份斷言的任何系統實體。

協定組合（Protocol Composition）——協定組合是在保持技術連貫性的同時組合協定并避免任何非指定功能副作用的能力。

資源（Resource）——資源是可由端點引用尋址的任何實體，在該端點引用中，該實體可以提供其自身的XML表示形式。

安全上下文（Security Context）——安全上下文是一個抽象概念，指的是已建立的身份驗證狀态和可能具有與安全有關的附加屬性的協商密鑰。

安全上下文令牌（Security Context Token）——安全上下文令牌（SCT）是安全上下文抽象概念的有線表示形式，它使上下文能夠被URI命名并和一起使用。

安全性令牌（Security Token）——安全性令牌用于表示一組斷言的集合。

安全性令牌服務（Security Token Service）——安全性令牌服務（STS）發行安全性令牌的Web服務。更确切地說，它根據它所信任的證據來作出斷言，并發送給信任它的任何一方（或特定接收者）。為了表明信任，服務需要證據（如簽名），以證明安全性令牌或安全性令牌集提供的資訊。服務本身可以生成令牌，也可以通過它自己的信任陳述依靠某一獨立的STS發行安全性令牌（注意，對于某些安全性令牌格式，這隻能是重新發行或聯合簽名）。這構成了信任代理的基礎。

序列化（Serialization）——将XML Infoset表示為八位位元組流的過程。它是用于建立消息的有線格式的方法。

服務（Service）——通過消息來與其他實體進行互動的軟體實體。注意，服務不需要連接配接到網絡。

簽名（Signature）——簽名是通過加密算法計算出來，并綁定到資料的一個值。而且經過綁定，資料的指定接收者可以使用該簽名來驗證資料沒有改變并發自消息的簽名者，進而提供了消息完整性和身份驗證。簽名的計算和驗證可以通過對稱或非對稱密鑰算法來進行。

退出（Sign-Out）——退出是這樣一個過程：某主體表明它們将不再使用其令牌且該域中的服務可能會破壞該主體令牌緩存。

單點登入（SSO，Single Sign On）——單點登入是對身份驗證序列的一種優化，旨在消除在請求者身上進行的反複操作負擔。為了便于進行SSO，稱為身份提供程式（Identity Provider）的元素能夠以請求者的名義充當代理，将身份驗證事件的證據提供給請求該請求者資訊的第三方。這些身份提供程式（IP）是受信任的第三方，既需要得到請求者的信任（以維護請求者的身份資訊，因為該資訊的丢失可能會洩露請求者身份），又需要得到Web服務的信任，Web服務可能會根據該IP提供的身份資訊的完整性提供對重要資源和資訊的通路權。

SOAP中介（SOAP Intermediary）——SOAP中介是一個SOAP處理節點，它既不是原始消息發送者，也不是最終接收者。

對稱密鑰算法（Symmetric Key Algorithm）——一種加密算法，其中的消息加密和解密都使用相同的密鑰。

系統（System）——實作某一特定功能的服務的集合。與分布式應用程式意思相同。

信任（Trust）——信任表示一個實體願意依靠另一個實體來執行一組操作，對一組主題、範圍作出一組斷言。

信任域（Trust Domain）——信任域是一個得到有效管理的安全空間，在其中，請求的來源和目标可以确定來自某一來源的特定憑證集是否符合該目标的相關安全政策，并對此達成一緻。目标可以将信任決定延期至第三方的加入（如果這已被确立為一緻意見的一部分），進而将受信任的第三方包括在信任域中。

易失的兩階段送出（Volatile Two Phase Commit）——用于緩存或視窗管理器等易失資源事務的協定。

Web服務（Web Service）——Web服務是一種可重複使用的軟體元件，它依據XML、SOAP和其他業界公認的标準通過網絡實作互動式的消息交換。

附錄B：XML Infoset資訊項

XML文檔可以包含11類資訊項。下面，我們列出并詳細說明了SOAP所支援的資訊項，并簡要介紹了其他的資訊項。SOAP支援6類資訊項：

文檔（Document）：每個資訊集裡都有一個文檔資訊項。它用于引用所有的其他資訊項。
元素（Element:）：文檔中每個XML元素的資訊集中都包含一個元素資訊項。對所有元素的通路是通過對Child屬性的遞歸跟蹤提供的。
屬性(Attribute)：文檔中每個屬性的資訊集中都包含一個屬性資訊項。附加屬性資訊項用于命名空間。
命名空間(Namespace)：每個在其父元素範圍内的名稱空間資訊集中都包含一個名稱空間資訊項。
字元(Character)：文檔中每個資料字元的資訊集中都包含一個字元資訊項。
注釋(Comment)：除了出現在DTD中的以外，文檔中每個注釋的資訊集中都包含一個注釋資訊項。

SOAP不支援但出現在XML Infoset初始定義中的5類資訊項是：處理指令(Processing Instruction)、文檔類型聲明(Document Type Declaration)、未擴充的實體引用(Unexpanded Entity Reference)、未解析實體(Unparsed Entity)和表示法(Notation)。

附錄C：常見的安全攻擊

對分布式系統的攻擊可以分為若幹個方面。它們可以指向系統中的一個或多個主機，或指向它們之間的通信網路。攻擊的目的可能是中斷操作、獲得機密資訊或在系統内部執行未授權的操作。它們可能會攻擊系統中所使用的加密技術或以安全性為中心的其他技術，也可能企圖通過攻擊下面的系統和網絡層或上面的應用層來旁路它們。以下是一個簡短的不全面的安全性攻擊類及針對每類攻擊的标準對策的清單，它們是按上述的幾個方面組織編排的：

對主機的攻擊

拒絕服務（DoS，Denial-of-Service）攻擊通過擊垮主機的響應能力來中斷其操作

當指向加密層時，DoS通常會盡力迫使主機反複執行特定身份驗證或密鑰交換協定所需的計算代價高昂的公鑰操作。對抗這類攻擊的典型防禦措施是延遲公鑰操作，直到對話者的合法性能夠通過花費較少的方法（如對稱加密或“謎語”）來驗證時為止。DoS對底層網絡層或頂層應用層的攻擊很難預防，特别是在攻擊者控制着大量資源且通信量處于正常通信量難以覺察的情況下。要實作網絡基礎架構的部署，通常必須通過漏鬥方式将通信量降至一個可管理水準。

主機機密性或授權攻擊企圖洩露隐私或身份

這些攻擊可能會利用主機軟體中的薄弱點來獲得對主機的控制。适當的安全性管理，如安裝更新檔、配置防火牆以及削減暴露應用程式的特權，是比較常用的對策。另一類攻擊利用系統或應用程式中的弱點，如設定不正确的政策或應用程式邏輯錯誤，除了一般的主機洩密以外，它們還會考慮機密性或授權洩密。恰當的安全性政策管理和周密的應用程式設計是對付這類攻擊的唯一防禦措施。在“電子欺騙”攻擊中，攻擊者企圖通過冒用某一經過授權的其他方的身份并做出相應的行為來獲得對各種操作的授權。隻要主機和經授權方切實保護好身份驗證密碼，并正确使用安全的身份驗證協定，就可以預防電子欺騙。

對通信網路的攻擊

DoS對網絡的攻擊試圖中斷與服務的通信

和對主機網絡層的攻擊一樣，這些攻擊确實也隻能使用網絡基礎架構方法來應對。

對網絡通信機密性的攻擊企圖線上洩露隐私

明文通信的直接監聽可以通過加密來阻止。通過足夠強大的加密算法和足夠長的密鑰，密碼分析攻擊也可以被扼制。

對網絡通信授權的攻擊企圖洩露身份

攻擊者企圖将消息插入會話的“消息僞造攻擊”和攻擊者修改會話中發送的消息的消息，變更攻擊都可以通過包含消息身份驗證的消息安全性協定來阻止。攻擊者将以前發送的（因而通過了正确的身份驗證）消息插入會話的消息重放，攻擊可以通過序号或時間戳和消息緩存的組合來檢測和阻止。

Web服務架構及其規範入門XML和InfosetSOAP安全性發現（Discovery）一緻性協定——可靠的消息傳遞和事務枚舉、傳輸和事件結束語附錄A：術語表附錄B：XML Infoset資訊項附錄C：常見的安全攻擊