??? [摘要]本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使用joe@companya.com工作。他還可能有其他身份，如joe_bloggs@hotmail.com和josephb@cornell.edu。通過身份聯盟，系統可以確定這些身份都是同一個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對底層網絡層或頂層應用層的攻擊很難預防，特別是在攻擊者控制著大量資源且通信量處于正常通信量難以覺察的情況下。要實現網絡基礎架構的部署，通常必須通過漏斗方式將通信量降至一個可管理水平。
??? 這些攻擊可能會利用主機軟件中的薄弱點來獲得對主機的控制。適當的安全性管理，如安裝補丁、配置防火墻以及削減暴露應用程序的特權，是比較常用的對策。另一類攻擊利用系統或應用程序中的弱點，如設置不正確的策略或應用程序邏輯錯誤，除了一般的主機泄密以外，它們還會考慮機密性或授權泄密。恰當的安全性策略管理和周密的應用程序設計是對付這類攻擊的唯一防御措施。在“電子欺騙”攻擊中，攻擊者企圖通過冒用某一經過授權的其他方的身份并做出相應的行為來獲得對各種操作的授權。只要主機和經授權方切實保護好身份驗證密碼，并正確使用安全的身份驗證協議，就可以預防電子欺騙。
對通信網路的攻擊
??? 和對主機網絡層的攻擊一樣，這些攻擊確實也只能使用網絡基礎架構方法來應對。
??? 明文通信的直接監聽可以通過加密來阻止。通過足夠強大的加密算法和足夠長的密鑰，密碼分析攻擊也可以被扼制。
??? 攻擊者企圖將消息插入會話的“消息偽造攻擊”和攻擊者修改會話中發送的消息的消息，變更攻擊都可以通過包含消息身份驗證的消息安全性協議來阻止。攻擊者將以前發送的（因而通過了正確的身份驗證）消息插入會話的消息重放，攻擊可以通過序號或時間戳和消息緩存的組合來檢測和阻止。