http://www.54bk.com/blog.asp?subjectid=1715&name=yuexb
作者：Luis Felipe Cabrera、Christopher Kurt、Don Box
[摘要]本W(wǎng)eb服務(wù)架構(gòu)入門闡述了Web服務(wù)架構(gòu)的基礎(chǔ)設(shè)計原則和Web服務(wù)的基礎(chǔ)技術(shù)。此外還對其功能進行了介紹，并提供了對其進行正式定義的規(guī)范鏈接。本文也是該架構(gòu)所有規(guī)范的參考指南。
XML和Infoset
對于所有的消息傳遞系統(tǒng)來說，選擇信息傳輸單位是非常重要的——簡單地說，對消息的構(gòu)成有個一般的認識是必不可少的。在Web服務(wù)中，一條消息就是一個XML文檔信息項，它由XML信息集（XML Information Set，即Infoset）定義。Infoset是一個抽象的數(shù)據(jù)模型，它兼容基于文本的XML 1.0，也是所有最新XML規(guī)范（XML Schema、XML Query和XSLT 2.0）的基礎(chǔ)。由于Web服務(wù)架構(gòu)是以XML Infoset，而不是某一特定的表現(xiàn)形式為基礎(chǔ)，使得該架構(gòu)及其核心協(xié)議組件可與其他編碼技術(shù)兼容。
Infoset根據(jù)一組‘信息項（Information Items）’對XML文檔進行建模。這組可能的信息項一般會映射到XML文檔的不同功能部件上，如元素、屬性、命名空間和注解。每一信息項都有一個關(guān)聯(lián)屬性集，用于提供該項的更完整描述。附錄B描述了XML文檔中的11類信息項。每一個結(jié)構(gòu)嚴謹?shù)腦ML文檔都會包含一個文檔信息項和至少一個元素信息項。
除了基于純文本的Infoset編碼技術(shù)以外，Web服務(wù)架構(gòu)還支持另外一種Infoset編碼技術(shù)——即允許不透明的二進制數(shù)據(jù)與傳統(tǒng)的基于文本的標記交織在一起。W3C XML-binary Optimized Packaging（即XOP）格式使用多部分MIME將原始二進制數(shù)據(jù)引入到XML 1.0文檔中，而不采用base64編碼。其配套規(guī)范——SOAP 消息 Transmission Optimization Method，即MTOM，則指定如何將該格式綁定到SOAP。XOP和MTOM是將原始二進制數(shù)據(jù)與基于文本的XML混合在一起的首選方法，它們?nèi)〈四壳捌毡樵獾椒磳Φ腟OAP with Attachments（SwA）和WS-Attachments/DIME。
SOAP
SOAP為在分散的分布式環(huán)境中使用XML在同等體之間交換結(jié)構(gòu)化分類信息提供了一種簡單的輕量級機制。SOAP旨在最大限度地降低對基于不同平臺構(gòu)建的應(yīng)用程序進行集成的設(shè)計成本，并認為最低成本技術(shù)最有可能贏得普遍接受。SOAP消息是包含三個元素的XML文檔信息項，這三個元素是：<Envelope>、<Header>和<Body>。
Envelope是SOAP消息的根元素，它包含一個可選的Header元素和一個必需的Body元素。Header元素是以分散方式增加SOAP消息功能的一種通用手法。Header的每個子元素都被稱為一個Header塊（Header Block），SOAP定義了幾個知名的屬性來指示應(yīng)該由誰來處理Header塊（role）以及這種處理是可選的還是必需的（mustUnderstand），下文中對這兩個屬性進行了介紹。目前，Header元素總是Envelope的第一個子元素；Body元素總是Envelope的最后一個子元素，也是供最終消息接收者使用的“有效負載”的容器。SOAP本身沒有定義內(nèi)置的Header塊，且只定義了一個有效負載，那就是用于報告錯誤的Fault元素。
所有的Web服務(wù)消息都是SOAP消息，它們充分利用了XML Infoset。消息有效負載和協(xié)議頭都使用同一個模型，可以確保基礎(chǔ)架構(gòu)頭Header和應(yīng)用程序體的完整性。應(yīng)用程序發(fā)送消息時可能會同時考慮Header的內(nèi)容和消息中的數(shù)據(jù)。為XML數(shù)據(jù)模型開發(fā)的工具可以用于檢查和構(gòu)建完整的消息。過去，這些益處在某些架構(gòu)中是沒有的，如DCOM、CORBA和RMI，它們之中的協(xié)議頭是一些對應(yīng)用程序不透明的基礎(chǔ)架構(gòu)細節(jié)。
SOAP消息是從發(fā)送者向接收者單向傳送的。多個單向消息的組合可以形成較為復(fù)雜的模式。例如，比較常見的模式是同步請求/響應(yīng)消息對。發(fā)送或接收消息的任何一個軟件代理都被稱為一個SOAP節(jié)點（SOAP Node）。啟動消息傳輸?shù)墓?jié)點稱為原始發(fā)送節(jié)點。使用和處理消息的最后一個節(jié)點稱為最終接收節(jié)點。在原始發(fā)送節(jié)點和最終接收節(jié)點之間處理消息的任一節(jié)點都叫做中介（Intermediary）。中介用于模擬單個消息的分布式處理。消息經(jīng)過的所有中介節(jié)點和最終接收節(jié)點統(tǒng)稱為消息路徑（Message Path.）。
為了能夠識別消息路徑的各個部分，每個節(jié)點都擔(dān)任一個或多個角色。SOAP角色是一種分類模式，它將一個基于URI的名稱與某些抽象功能（如緩存、驗證、授權(quán)）關(guān)聯(lián)在一起。基礎(chǔ)SOAP規(guī)范定義了2個內(nèi)置角色：Next和UltimateReceiver。Next是一個通用角色，因為除了發(fā)送節(jié)點之外的每一個SOAP節(jié)點都屬于Next角色。UltimateReceiver是消息路徑中終端節(jié)點所扮演的角色。它通常就是應(yīng)用程序，或在某些情況下是代表該應(yīng)用程序執(zhí)行任務(wù)的基礎(chǔ)架構(gòu)。
SOAP envelope的Body總是針對最終接收節(jié)點。而SOAP header則可以針對中介，也可以針對最終接收節(jié)點。為了提供一個安全且版本可控的消息處理模型，SOAP定義了3個屬性，用于控制中介和最終接收節(jié)點處理某一指定Header塊的方式——role、relay和mustUnderstand。角色屬性用于確定Header塊所針對的節(jié)點。mustUnderstand屬性用于指示在Header塊未被認出的情況下該節(jié)點是否可以忽略該Header塊。帶有mustUnderstand="true"標記的Header塊叫做強制Header塊（Mandatory Header Block）。標記為mustUnderstand="false"或沒有mustUnderstand屬性的Header塊叫做可選Header塊。relay屬性指示該節(jié)點是發(fā)送還是放棄未被認出的可選header。
每一個SOAP節(jié)點都必須使用這3個屬性來實現(xiàn)SOAP處理模型。以下步驟詳細說明了該模型：
- 使用角色屬性（缺省該屬性表示Header塊針對最終接收節(jié)點）確定將用于當(dāng)前SOAP節(jié)點的SOAP消息的所有Header塊。
- 驗證當(dāng)前SOAP節(jié)點是否能夠使用SOAPmustUnderstand屬性來處理步驟1中所確定的所有強制Header塊。如果有強制Header塊不能被當(dāng)前SOAP節(jié)點處理，則必須丟棄該消息，并生成一條醒目的錯誤消息。
- 處理消息。可以忽略可選消息元素。
- 如果SOAP節(jié)點不是消息的最終接收節(jié)點，則步驟1中所確定的所有無法分程傳送的Header塊都會被刪除，然后消息被傳送到消息路徑中的下一個SOAP節(jié)點。下一個SOAP節(jié)點可以自由地將新的Header塊插入到分程傳送的消息中。其中的某些Header塊可能是步驟1中所確定的Header塊的副本。
SOAP處理模型旨在實現(xiàn)可擴展性和版本控制。mustUnderstand屬性對新Header塊的引入是中斷變化還是非中斷變化進行控制。添加可選header塊（如標記為mustUnderstand="false"的header）是一種非中斷變化，因為任何SOAP節(jié)點都可自由忽略它。添加強制header塊（如標記為mustUnderstand="true"的header）是一種中斷變化，因為只有知曉Header塊語法和語義的SOAP節(jié)點才能夠處理SOAP消息。Role、relay以及mustUnderstand屬性沿著消息路徑傳遞這種處理模型。
消息交換模式
SOAP所提供的消息傳遞靈活性使Web服務(wù)能夠以多種消息交換模式進行通信，從而滿足分布式應(yīng)用的需求。我們在該架構(gòu)的核心構(gòu)件中充分利用了其中一些模式，有幾種模式已經(jīng)被證明在分布式系統(tǒng)中特別有用，比如使用遠程過程調(diào)用就使同步請求/響應(yīng)消息交換模式得到了普及。當(dāng)消息傳送潛伏時間失控時，就需要采用異步消息傳遞。當(dāng)使用同步請求/響應(yīng)模式時，顯式消息相關(guān)性則成為必需。
廣播傳輸（Broadcast Transport）使一對多消息傳輸?shù)玫搅似占啊Ｔ及l(fā)送者將其消息強行發(fā)送給接收者的模式稱為推模式（Push Model）。盡管這種模式在局域網(wǎng)里很有效，但在廣域網(wǎng)中則不太適用，接收者也無法調(diào)控消息流。另一個有用的模式是以應(yīng)用程序表達對某些特定消息類別的興趣的能力為基礎(chǔ)的，它使發(fā)布/訂閱模式大行其道。通過顯式訂閱消息源（或主題），應(yīng)用程序可以更好地控制相關(guān)信息流。接收者從消息源顯式請求消息時使用拉模式（Pull Model）。在這種模式下，消息流是由接收者驅(qū)動的。拉模式也可以與發(fā)布/訂閱模式結(jié)合使用。這非常適合于接收者可能要與消息源間歇地斷開連接的情況。
傳輸?shù)莫毩⑿?/H2>
根據(jù)SOAP的定義，它與所使用的底層消息傳遞機制無關(guān)。它支持很多可用的消息交換傳輸機制，也支持同步和異步消息傳送與處理。既需要多種傳輸又需要異步消息傳遞的系統(tǒng)的一個例子是在基于陸地高速網(wǎng)絡(luò)干線的Web服務(wù)與由移動電話托管的間歇連接的Web服務(wù)之間進行通信的系統(tǒng)。這樣的系統(tǒng)要求一條消息經(jīng)哪種傳輸系統(tǒng)傳輸要以該消息在哪個網(wǎng)段內(nèi)移動為依據(jù)。這樣的系統(tǒng)還有一個典型特點，即消息傳送潛伏時間無法精確確定。Web服務(wù)開發(fā)人員不應(yīng)力圖確定或界定消息傳送潛伏時間，而應(yīng)在假定異步消息傳遞已達到最大效能的前提下構(gòu)建系統(tǒng)。與使用遠程過程調(diào)用時的情況不同，異步消息傳遞允許發(fā)送者在每一消息傳輸之后繼續(xù)進行處理，而不必被迫阻塞并等待響應(yīng)。當(dāng)然，同步請求--響應(yīng)模式也可以構(gòu)建在異步消息傳遞的基礎(chǔ)之上。
既然Web服務(wù)協(xié)議完全獨立于底層傳輸之外，適當(dāng)機制的選擇可能就要延遲到運行時。這就為Web服務(wù)應(yīng)用程序提供了在發(fā)送消息時確定相應(yīng)傳輸機制的靈活性。此外，底層傳輸機制可能會隨著消息在節(jié)點之間的發(fā)送而變化，相應(yīng)地，針對每一網(wǎng)段而選擇的傳輸機制也會隨需發(fā)生變化。
盡管存在著這種一般的傳輸?shù)莫毩⑿裕蠖鄶?shù)第一代Web服務(wù)都使用HTTP來進行通信，因為這是SOAP規(guī)范內(nèi)所包含的一種主要綁定協(xié)議。HTTP以TCP作為其底層傳輸協(xié)議。但是，TCP在設(shè)計時引入了不必要的處理開銷。有些應(yīng)用協(xié)議模式與用戶數(shù)據(jù)報協(xié)議（即UDP， User Datagram Protocol）的語義學(xué)比較匹配，這些模式對于受設(shè)備及其他資源約束的系統(tǒng)特別有用。UDP不像TCP那樣具有傳輸保證；它提供最大限度的數(shù)據(jù)報消息傳遞。與TCP相比，它需要的實施資源較少。此外，UDP還提供了多路廣播功能（Multi-cast Capabilitiy），使一個發(fā)送者可以將消息同時發(fā)送給多個接收者。
尋址
對于要在這種多傳輸情況下發(fā)送和尋址的消息來說，要讓關(guān)鍵的消息傳遞屬性為多個傳輸所攜帶，就需要一種共用機制。為此，WS-Addressing規(guī)范定義了3組SOAP Header塊：
- Action Header塊用于說明消息的預(yù)期處理。該Header塊包含一個URI，最終接收者通常用它來分派要進行處理的消息。
- MessageID和RelatesTo Header塊用于識別和關(guān)聯(lián)消息。MessageID和RelatesTo header使用簡單的URI來唯一地識別消息——這些URI通常都是瞬態(tài)的UUID。
- To/ReplyTo/FaultTo Header塊用于識別要處理消息及其回復(fù)的代理。這些Header依賴于WS-Addressing所定義的稱為“端點引用（Endpoint Reference）”的結(jié)構(gòu)，它將與對SOAP消息進行正確尋址所需的信息捆綁在一起。
端點引用是WS-Addressing的最重要的方面，因為與僅使用URI相比，它們可為更細粒度的尋址提供支持。它們廣泛用于整個Web服務(wù)架構(gòu)。端點引用包含3條關(guān)鍵的信息：基地址、可選的引用屬性集和引用參數(shù)。基地址是一個URI，用于識別端點，出現(xiàn)在指向該端點的每一SOAP消息中的To Header塊中。引用屬性和引用參數(shù)是用于為該消息提供附加發(fā)送或處理信息以補充基地址的任意XML元素的集合，它們以文字Header元素來表示。當(dāng)使用端點引用來構(gòu)建端點消息時，發(fā)送者負責(zé)提供作為Header塊的所有引用屬性和引用參數(shù)。
引用屬性和引用參數(shù)之間的區(qū)別在于它們?nèi)绾侮P(guān)聯(lián)服務(wù)元數(shù)據(jù)。Web服務(wù)策略和契約僅基于其基地址和引用屬性。通常，基地址和引用屬性用于識別某一給定的已部署服務(wù)，引用參數(shù)用于識別該服務(wù)所管理的特定資源。
引用屬性和參數(shù)是那些預(yù)期只被最終接收者處理的簡單的不透明XML元素。它們有助于確保可用于分派、發(fā)送、索引或其他發(fā)送端處理活動的信息被包含在給定的消息中。盡管中介預(yù)期不會對該信息進行處理，但某些中介（如防火墻或網(wǎng)關(guān)服務(wù)程序）卻有可能使用某些引用屬性或參數(shù)來進行消息發(fā)送、消息處理。引用屬性有很多用途。服務(wù)類（Classes of Service）和專用實體標識符（Private Entity Identifier）就是兩個例子。在服務(wù)等級例子中，引用屬性可以用于區(qū)分針對標準客戶的Web服務(wù)和針對“黃金”客戶的Web服務(wù)，后者提供了更高的服務(wù)質(zhì)量和增強功能——可能是通過附加的操作或附加的綁定——在邏輯上形成兩個不同的端點。這些屬性只在一個會話中設(shè)置一次，然后便在交互的其余所有部分重復(fù)使用。引用屬性另一個用途的例子是以一種對系統(tǒng)不公開發(fā)送消息的方式來識別客戶的機制。這兩種引用屬性的組合可以高效地將消息發(fā)送給一組適當(dāng)?shù)姆?wù)器，并高效地確定與某一特定用戶有關(guān)的應(yīng)用狀態(tài)。這些例子還展示了引用服務(wù)實例的數(shù)據(jù)和引用用戶實例的數(shù)據(jù)如何用引用屬性來表示。
需要特別指出的是，引用屬性還有助于對共享一個共同的URL和作用域的WSDL實體集合進行尋址。WSDL是將Web服務(wù)描述為操作消息的一組端點的XML格式，它首先抽象地指定其實體，然后將其具體地綁定到特定實例。具體而言，消息和操作經(jīng)抽象定義之后，被綁定到帶有網(wǎng)絡(luò)傳輸和消息格式信息的一個端點。因此，從WSDL的角度來看，當(dāng)針對不同的具體實體（如輸入或輸出消息、portType綁定、端口或Web服務(wù)中使用一個共同URL的服務(wù)）時，對應(yīng)端點引用的引用屬性應(yīng)該不同。
使用引用參數(shù)的兩個例子是基礎(chǔ)架構(gòu)和應(yīng)用水平。引用參數(shù)的基礎(chǔ)架構(gòu)例子可以是發(fā)送給某一事務(wù)處理監(jiān)視器的事務(wù)/征募ID（Enlistment ID）。在一個購書的場景中，書的ISBN號可能就是一個引用參數(shù)應(yīng)用水平例子。
元數(shù)據(jù)（Metadata）
所有的Web服務(wù)交互都是通過交換SOAP消息來進行的。為了提供一個健壯的開發(fā)和操作環(huán)境，服務(wù)是用機器可讀的元數(shù)據(jù)來描述的——元數(shù)據(jù)支持互操作性。Web服務(wù)元數(shù)據(jù)可以服務(wù)于若干個意圖。它用于描述Web服務(wù)支持的消息互換格式和某一服務(wù)有效的消息交換模式。元數(shù)據(jù)還用于描述服務(wù)的功能和需求。元數(shù)據(jù)的最后一種形式叫做“服務(wù)策略（Policy of Services.）”。消息互換格式和消息交換模式用WSDL來表示，策略使用WS-Policy來表示，契約（Contract）用上述三種元數(shù)據(jù)來表示。契約是將應(yīng)用程序與它們所依賴的服務(wù)的內(nèi)部實現(xiàn)細節(jié)隔離開來的抽象。
Web服務(wù)描述語言，即WSDL——Web Service Description Language，它是被廣泛用于描述Web服務(wù)基本特征的第一種手段。用WSDL描述的消息被歸并為定義基本消息模式的若干操作。這些操作被歸并為稱作端口的若干個接口，它們詳細說明了抽象的服務(wù)契約。端口和綁定則用于將portTypes與具體傳輸和physical 部署信息關(guān)聯(lián)在一起。WSDL描述是自動識別目標服務(wù)的所有特征和啟用軟件開發(fā)工具的第一步。WSDL指定請求消息必須包含什么以及響應(yīng)消息在使用無歧義符號時的顯示會是怎樣。WSDL文件用于描述消息格式的符號是基于XML模式的。這意味著它既是編程語言中立的又是基于標準的，這使得它很適合于描述可通過多種平臺和編程語言來訪問的服務(wù)接口。除了描述消息內(nèi)容以外，WSDL還可以定義服務(wù)在何處是可用的，以及哪些通信協(xié)議被用于與該服務(wù)交談。這意味著WSDL文件可以指定用于編寫與某一Web服務(wù)進行交互的程序的基本元素。有幾種工具可用于讀取WSDL文件，以及為編制句法正確的Web服務(wù)消息生成所需代碼。
盡管WSDL是一個不錯的起點，但它并不足以描述Web服務(wù)的方方面面，WSDL只能表示較少的一組屬性。Web服務(wù)所必需的更詳細信息包括：
- 操作特征：支持SOAP 1.2。
- 使用特征：僅在早9點和下午5點之間可用。
- 安全特征：要訪問該服務(wù)必需使用Kerberos票。
第一代Web服務(wù)必須使用專有協(xié)議來交換帶外（Out of Band）的元數(shù)據(jù)，這一問題可以使用WS-Policy來解決。WS-Policy提供了一種通用模型和語法來描述和傳達Web服務(wù)策略。它指定了一個概念基集，它可以被其他Web服務(wù)規(guī)范使用和擴展，以描述更為廣泛的服務(wù)需求和功能。WS-Policy引入了一個簡單的可擴展語法來表示策略斷言（Policy Assertion），以及一個處理模型來解釋它們。斷言可以合并到邏輯選項中。
策略斷言使編程人員要么在開發(fā)時、要么在運行時向服務(wù)信息中添加適當(dāng)?shù)脑獢?shù)據(jù)。開發(fā)時策略的例子包括消息大小的最大允許值或所支持規(guī)范的確切版本，運行時策略的例子包括宕機時的必備服務(wù)或某一給定的管理過程（定期的硬件維護）期間Web服務(wù)的不可用性。可以對單個的策略斷言進行分組，以形成策略選項（Policy Alternative）。策略是策略選項的集合。為了便于進行互操作，策略是根據(jù)其XML Infoset表示形式來定義的。為了在保持互操作性的同時減小策略文檔的大小，又定義了策略的緊湊形式。
策略用于傳達兩個Web服務(wù)端點之間的交互條件。滿足策略中的斷言通常會引發(fā)反映這些條件的行為。因此，策略斷言評估是識別兼容行為的中心。當(dāng)且僅當(dāng)請求者滿足要求，即提供了這一功能、與該斷言相符時，請求者才支持策略斷言——策略的構(gòu)造塊。一般而言，這種決定要使用特定領(lǐng)域的知識來做出。請求者支持策略選項的條件是當(dāng)且僅當(dāng)請求者支持選項中的所有斷言時，這種決定是使用策略斷言的結(jié)果機械性地做出的。同樣，當(dāng)且僅當(dāng)請求者至少支持策略中的一個選項時，請求者才支持策略。一旦策略選項經(jīng)過評估，該決定也是機械性地做出的。請注意，雖然策略選項是互斥的，但一般來說要確定多個選項是否可以同時得到支持也是不太可能的。
為了以互操作的形式傳達策略，策略表達式（Policy Expression）采用策略的某種XML Infoset表示形式。普通形式的策略表達式是最簡單的Infoset；同樣，可選的Infoset允許通過大量構(gòu)造來簡潔地表達策略。策略表達式是策略的基礎(chǔ)構(gòu)造塊。有兩個運算符用于表達斷言：All和ExactlyOne。All運算符表示策略選項集中的所有斷言都必須適用于要滿足的策略斷言。ExactlyOne運算符表示策略選項集中只有一條斷言必須適用于要滿足的策略斷言。
策略層位于WSDL描述之上，并對它進行了擴充。策略與Web服務(wù)元數(shù)據(jù)（如WSDL定義或UDDI實體）的關(guān)聯(lián)是通過使用WS-PolicyAttachment來實現(xiàn)的。策略可以作為其定義所固有的一部分或獨立地與資源關(guān)聯(lián)在一起。機制就是針對這些不同目的而定義的。需要特別指出的是，策略也可以與單個的SOAP消息一起使用。如果為某一實體制作了多個策略附件，它們會共同確定該實體的有效策略（Effective Policy）。在WSDL層次結(jié)構(gòu)的不同層次上選用策略時一定要小心，因為層次結(jié)構(gòu)每一層次的最終結(jié)果就是一個有效策略。作為自我描述和人所能理解的明確性的一般規(guī)則，在策略斷言所適用的層次結(jié)構(gòu)的每一層次上詳細地重復(fù)該策略斷言，比簡單地依賴于計算有效策略的機制更可取。在一個WSDL文檔中，與部署端點的消息交換可以同時包含所有4類主題的有效策略。WS-Policy和WS-PolicyAttachment相結(jié)合可以提高應(yīng)用程序來發(fā)現(xiàn)和推出其他服務(wù)所支持的策略的能力。添加策略的靈活性是對描述消息交互的WSDL信息的一個重要補充。
WSDL和WS-Policy都定義了元數(shù)據(jù)格式，但都沒指定某一給定服務(wù)獲得或訪問元數(shù)據(jù)的機制。一般來說，服務(wù)元數(shù)據(jù)可以通過使用許多方法來獲取。為了支持服務(wù)的自我描述，Web服務(wù)架構(gòu)在WS-MetadataExchange中定義了基于SOAP的元數(shù)據(jù)訪問協(xié)議。GetMetadata操作用于檢索在請求的端點引用中找到的元數(shù)據(jù)。Get操作類似，但用于檢索不同的元數(shù)據(jù)：在元數(shù)據(jù)部分引用，并要在存儲它的端點引用中檢索的元數(shù)據(jù)。
使用WS-MEX來交換的元數(shù)據(jù)可以描述為資源。資源即可由某一端點引用尋址的任何實體，并且在該端點引用中，該實體可以提供一種其自身的XML表示形式。資源構(gòu)成了構(gòu)建Web服務(wù)中的狀態(tài)管理所需的基礎(chǔ)。
什么是互操作性概要（Interoperability Profile）
概要（Profile）是一組指導(dǎo)原則，主要針對于核心協(xié)議以及Web服務(wù)規(guī)范的使用。這些指導(dǎo)原則對于規(guī)范的通用設(shè)計來說是必需的。在某些情況下，開發(fā)人員需要額外的幫助來確定使用哪些Web服務(wù)特性來滿足某一特定需求。互操作性概要還用于解決Web服務(wù)規(guī)范不夠明確的領(lǐng)域中的含糊性問題，以確保所有實施都以相同的方式來處理SOAP消息。
WS-I基本概要
第一個Web服務(wù)概要是由Web服務(wù)-互操作性組織（WS-I，Web Services-Interoperability Organization）發(fā)布的。WS-I已經(jīng)完成了其第一個概要，并簡單地稱為基本概要1.0。該概要主要基于SOAP1.1和WSDL 1.0的互操作使用來提供指導(dǎo)原則。
安全性
本節(jié)介紹Web服務(wù)架構(gòu)中用于提供某一系統(tǒng)內(nèi)部的消息完整性、身份驗證和機密性、安全性令牌交換、消息會話安全性、安全策略表示和服務(wù)聯(lián)盟安全性的規(guī)范。提供這些特性的規(guī)范是WS-Security、WS-Trust、WS-SecureConversation、WS-SecurityPolicy和WS-Federation。
安全性是計算機系統(tǒng)的一個基本方面，尤其是那些由Web服務(wù)組成的系統(tǒng)。安全性必須是健壯而有效的。因為系統(tǒng)只對消息格式和合法的消息交換作出硬件假設(shè)，因此安全性必須基于一致通過的明確機制和假設(shè)。安全基礎(chǔ)架構(gòu)還應(yīng)該具有足夠的靈活性，以支持不同組織所需的不同安全策略。
當(dāng)安全傳輸可用于通信Web服務(wù)，如安全套接層（SSL）和傳輸層安全性（TLS）之間時，構(gòu)建安全性解決方案就得到了簡化。有了安全傳輸，這些服務(wù)就不需要參與單個消息的完整性和機密性的維護；它們可以依賴于底層傳輸。不過，現(xiàn)有的傳輸級安全性是一個僅限于點對點消息傳遞的解決方案。如果在使用安全傳輸時存在中介，則最初發(fā)送者和最終接收者需要相信這些中介能夠幫助提供端到端的安全性，因為每個網(wǎng)段都是安全的。除了要明確地信任所有中介外，還必須考慮到其他風(fēng)險，如消息的本地存儲和中介受到損害的可能性。
為了最大限度地擴大Web服務(wù)的作用范圍，當(dāng)通信端點不相信中介時，必須提供端到端的安全性，那就需要更高級別的安全協(xié)議。作為另一種選擇，端到端消息安全性比點對點傳輸級安全性具有更豐富的內(nèi)涵，因為它支持Web服務(wù)所需的基于SOAP的松耦合、聯(lián)合、多傳輸和可擴展環(huán)境。這種功能強大而又靈活的基礎(chǔ)架構(gòu)可以通過現(xiàn)有技術(shù)和Web服務(wù)協(xié)議的組合來開發(fā)，同時還可以緩解與點對點消息傳遞相關(guān)聯(lián)的許多安全風(fēng)險。
盡管Web服務(wù)的安全需求很復(fù)雜，但人們還沒有發(fā)明新的安全機制來滿足基于SOAP的消息傳遞的需要。現(xiàn)有的分布式系統(tǒng)安全性方法，如Kerberos票、公鑰加密技術(shù)、X.509證書等已經(jīng)夠用了。只有應(yīng)用現(xiàn)有的SOAP安全方法時，新機制才是必需的。這些新安全協(xié)議的設(shè)計充分考慮了可擴展性，以便將來能夠加入新的方法。一個主要的設(shè)計目標是要提供自我描述安全性屬性（為包括SOAP在內(nèi)的Web服務(wù)架構(gòu)而設(shè)計）機制。
Web服務(wù)安全性的基礎(chǔ)是輸入消息要證實一組關(guān)于發(fā)送者、服務(wù)或其他資源的斷言這一需求。我們稱之為斷言或安全性斷言。典型的安全性斷言包括身份、屬性、關(guān)鍵財產(chǎn)、權(quán)限或功能。這些斷言是用包裹在XML中的二進制安全性令牌編碼的。在傳統(tǒng)的安全性術(shù)語中，這些安全性令牌表示功能和訪問控制的混合。很多方法都被用于創(chuàng)建安全性令牌。Web服務(wù)可以從本地信息構(gòu)建定制的安全性令牌。反過來，安全性令牌也可以從X.509認證機構(gòu)或Kerberos域控制器等專業(yè)服務(wù)檢索。為了實現(xiàn)服務(wù)之間的通信自動化，需要一個表達安全需求的方法。
服務(wù)可以使用WS-SecurityPolicy中所指定的策略斷言來表達其安全需求。通過檢索這些策略斷言，應(yīng)用程序可以構(gòu)建符合目標服務(wù)需求的消息。斷言、安全性令牌和策略所提供的這組特性以及從Web服務(wù)檢索它們的能力非常強大。這種普通的Web服務(wù)安全模式支持一些更具體的安全模式，如基于身份的授權(quán)、訪問控制列表和基于功能的授權(quán)。它允許使用現(xiàn)有技術(shù)，如X.509 公鑰證書、基于XML的令牌、Kerberos共享的秘密票和密碼摘要。這種普通模型對于構(gòu)建使用更復(fù)雜的方法來進行更高級別的密鑰交換、身份驗證、基于策略的訪問控制、審核和處理復(fù)雜的信任關(guān)系的系統(tǒng)已經(jīng)足夠。也可以使用代理和中繼服務(wù)。例如，可以構(gòu)建中繼服務(wù)來加強位于信任邊界的安全策略；出界的消息被加密，而界內(nèi)的消息不加密。以前的解決方案沒有提供這種靈活性和完善程度。附錄C中所描述的常見安全攻擊包含了系統(tǒng)威脅的基本分類，而這些系統(tǒng)威脅是在選擇Web服務(wù)安全特性時應(yīng)認真加以考慮的。
本節(jié)的余下部分將探討Web服務(wù)安全模式的應(yīng)用。兩個重要主題是安全通信和安全應(yīng)用。沒有假定安全的消息傳輸，這也不是安全的Web服務(wù)所必需的。
消息完整性和機密性
消息級安全性是端到端安全性的關(guān)鍵構(gòu)造塊。使用消息級安全性時，無需傳輸級安全性。對消息級安全性的要求是消息完整性、消息身份驗證和機密性。消息完整性確保消息不能在不知不覺中被更改。使用XMLSignature可確保消息的修改能夠被察覺。消息身份驗證可識別發(fā)送消息的主體。如果使用了公鑰加密，就可以確定主體的唯一身份。將公鑰加密與經(jīng)受信任源認證的密鑰一起使用可以實現(xiàn)這種身份驗證。不過，如果使用了對稱密鑰加密，情況就不一樣了——只有知道共享密鑰的主體才能被識別。消息機密性可確保在傳輸期間未經(jīng)授權(quán)的第三方不能閱讀消息。SOAP消息是通過使用XMLEncryption [XMLENC]和安全性令牌來保證機密性的。
完整性、身份驗證和機密性機制將初始消息（或該消息的某些部分）作為輸入，將生成的數(shù)據(jù)（如校驗和）作為輸出。例如，在某種簡單情況下，XML元素的簽名可能會作為XML元素所有字符的散列的非對稱加密來實現(xiàn)。然后該加密散列可以存儲在該消息中，并在該消息中傳送。可以將XML文檔看作字符串。就像XML簽名一樣，逐字符地比較也是非常重要的安全性操作。一字之差會導(dǎo)致不同的結(jié)果。串行化是用于表示“在線”對象的方法。例如，串行化可用于創(chuàng)建SOAP消息的XML表示。不同串行化軟件所導(dǎo)致的任何無關(guān)緊要的排字差異都會被消息處理軟件忽略，但會對安全性軟件產(chǎn)生很大影響。XML消息的Infoset表示形式改進了這一問題。要使XML簽名生效，消息必須轉(zhuǎn)換成一個對所有方都是一致的XML表單。規(guī)范化是一個術(shù)語，來描述用于生成一致的換行符、制表間隔、屬性排序和結(jié)束標簽樣式等非關(guān)鍵信息視圖的方法。簽名包含了用于使消息接收者能夠完全像發(fā)送者那樣處理安全信息的規(guī)范化方法。某一服務(wù)所使用的特定的規(guī)范化方法是要放置在一個WSDL portType綁定或WSDL端口的有用的策略斷言。
WS-Security指定了消息完整性和機密性機制以及單一的消息身份驗證。對于消息完整性，該規(guī)范詳細描述了加密簽名是如何表示并與SOAP消息的特定部分關(guān)聯(lián)的。該方法允許任意格式良好的消息片段擁有單獨的簽名。與之類似，機密性是通過結(jié)構(gòu)良好的消息片段的加密來實現(xiàn)。身份驗證是使用數(shù)字簽名來實現(xiàn)的。WS-Security規(guī)范描述了當(dāng)前常用的安全機制，也沒有排除將來添加新機制的可能性。因為SOAP處理模型使用Header元素來作出處理決定，所以是決定SOAP消息中的哪些元素需要加密時一定要多加小心。
在決定要對哪些元素進行加密以及要使用哪些加密算法時，Web服務(wù)設(shè)計人員一定要清楚消息是如何處理的。當(dāng)某些特定的Header元素需要由第三方或中介來處理時，這些決定就更為重要了。如果這些參與者對適當(dāng)?shù)慕饷軘?shù)據(jù)或?qū)υ诩用躕ML元素時所使用的約定毫無所知，它們將無法實現(xiàn)正確操作。此外，每個處理節(jié)點對消息中包含的安全信息都必須有個一般的了解。加密某一Header中XML元素的一個自然選擇就是對它進行完全加密，用初始元素替代加密數(shù)據(jù)類型的元素。這種簡單的方法有些缺點。例如，中介不太好確定必須處理哪些元素（帶有mustUnderstand="1"屬性的元素）。另外，當(dāng)元素類型發(fā)生變化時，確定其初始類型比較困難。另一種方法是對元素進行轉(zhuǎn)換，使得進行正確的SOAP處理所需的所有關(guān)鍵屬性都保持不變，且對初始元素進行了加密，并放在一個特殊的子元素中。這種方法的優(yōu)點是即使不知道如何解密元素的中介也能實現(xiàn)正確的處理。這種方法的一個缺點是它要求所有參與者都了解用于表示初始元素的約定。盡管WS-Security目前沒有對這種方法提供指導(dǎo)，但我們預(yù)期將來會提供的。相比之下這種方法更好一些，因為它可實現(xiàn)所有SOAP Header元素的正確處理。
WS-Security的概要規(guī)范中描述了幾種安全性令牌。針對表示用戶名的令牌、X.509證書和基于XML的安全性令牌的概要都已經(jīng)開發(fā)出來。基于XML的安全性令牌包括安全性斷言標記語言（SAML，Security Assertion Markup Language）和可擴展權(quán)限標記語言/權(quán)限表達語言（REL，Rights Expression Language）。Kerberos票的使用規(guī)范還未成型。
WS-I基本安全概要
WS-I將要發(fā)布的最新的互操作性概要之一是基本安全概要（BSP，Basic Security Profile）。該概要提供了WS-Security和各種安全性令牌，如Username和X.509證書令牌的實現(xiàn)指導(dǎo)。該概要用于補充和完善WS-I基本概要。
基于安全令牌的信任
安全性令牌是提供端到端安全解決方案所必需的。這些安全性令牌必須在消息處理的參與者之間實現(xiàn)直接或間接共享。各參與者還必須確定斷言的憑證是否可信。這些信任關(guān)系以安全性令牌的交換和代理為基礎(chǔ)，并存在于已經(jīng)確定的支持信任策略中。例如，某一代理的令牌有多少可信，是由系統(tǒng)管理員和他們確定的信任關(guān)系決定的。提供安全性令牌的服務(wù)五花八門。這是各種底層安全技術(shù)首先為Web服務(wù)所使用的領(lǐng)域。為了提供一種與安全技術(shù)無關(guān)的統(tǒng)一標準的解決方案，新協(xié)議是為信任域之間的安全性令牌交換而設(shè)計的。
WS-Trust以用于請求、發(fā)出和代理安全性令牌的協(xié)議對WS-Security進行了補充。需要特別指出的是，其中定義了用于獲取、發(fā)行、更新和驗證安全性令牌的操作。該規(guī)范的另一個新特性是建立新信任關(guān)系的機制。IPsec或TLS/SSL之類的網(wǎng)絡(luò)和傳輸保護機制可以與WS-Trust結(jié)合，以適應(yīng)不同的安全性需求和情況。
安全性令牌可以直接從某一適當(dāng)?shù)陌l(fā)行者處申請獲得，或者通過委托某一受信任的第三方來獲取。令牌還可以出乎意料地獲得。例如，令牌可以從某一安全權(quán)威機構(gòu)發(fā)送到一個并未明確申請該令牌的某一方。為此，系統(tǒng)管理員要確定初始信任關(guān)系，如將某一給定服務(wù)指定為信任的根服務(wù)。這種方法類似于目前Web上用于自展安全性的方法。從該服務(wù)獲得的所有令牌受信任的程度與受信任的根服務(wù)本身相同。例如，如果某根服務(wù)只有斷言A和B得到信任，且某一消息包含斷言A、B和C，則該消息中只有斷言A和B得到信任。配置靈活性是通過信任關(guān)系授權(quán)提供的。為了處理在退回或發(fā)出安全性令牌之前需要各方之間的一個交換集的情況，定義了用于驗證、協(xié)商和交換的方法。一種稱為“challenge”的特殊形式的交換為某一方證明它擁有與某一令牌關(guān)聯(lián)的密鑰提供了一種方法。交換的其他類型包括傳統(tǒng)的協(xié)議隧道。WS-Trust詳細說明了如何擴展該規(guī)范，以支持更多的令牌交換協(xié)議，而不僅僅是所給出的這兩個例子。
表示安全性斷言的安全性令牌是由一個受信任根或一個通過一個授權(quán)鏈的根發(fā)行的。這些安全性斷言用于驗證消息符合正在施行的安全策略。它們還驗證斷言者的屬性是通過簽名來校驗的。在代理的信任模式中，即由受信任的中介分配安全性令牌的模式中，簽名可能不驗證斷言者的身份，而驗證中介的身份。該中介可能只斷言者的身份。
安全會話
用于消息身份驗證和機密性的某些機制可能會耗用大量的資源。需要特別指出的是，許多加密技術(shù)都會顯著消耗處理能力。當(dāng)消息的安全性是逐一得到保證時，這些代價通常是無法避免的。不過，當(dāng)兩個Web服務(wù)進行許多消息的交換時，可以使用比WS-Security中定義的方法更為高效和健壯的消息機密性方法。這些方法是基于對稱加密的，在保證消息會話的安全時應(yīng)使用它們。
WS-SecureConversation在基于共享密鑰（如對稱加密）的兩個通信方之間定義了一個安全上下文。在整個會話期內(nèi)，安全上下文在各通信方之間始終是共享的。會話密鑰由共享密鑰派生而來，用于解密在會話中發(fā)送的單個消息。安全上下文在線表示為一個新的安全性令牌類型（即SCT ，Security Context Token）。
規(guī)范為建立安全會話各方之間的安全上下文定義了3種不同方法。第一種，由安全性令牌服務(wù)創(chuàng)建，且必須由會話發(fā)起方提取并傳送。第二種，通信一方創(chuàng)建安全上下文并通過消息傳遞給另一方。第三種，通過協(xié)商和交換創(chuàng)建安全上下文。Web服務(wù)會選擇最能滿足其需要的方法。必要時可以對安全上下文進行修正。更新安全上下文的一個典型例子是延長安全上下文的截止時間。安全上下文令牌隱含或包含了一個共享密鑰。該密鑰用于簽名、加密消息。當(dāng)使用共享密鑰時，通信各方可以選用不同的密鑰派生模式。例如，可以派生出4個密鑰，這樣雙方便可以使用單獨的密鑰來簽名和加密消息。為了保證密鑰未曾用過和保持高度的安全性，應(yīng)使用后續(xù)的派生密鑰。使用這種方法來保證會話的安全性是一種更好的選擇。WS-SecureConversation規(guī)范定義了一種方法來指示給定消息正在使用哪些派生密鑰。所有派生算法都是通過URI來識別的。
安全策略
WS-SecurityPolicy通過用一種符合WS-Policy的語言指定安全策略斷言來完善WS-Security，其6種斷言涉及安全性令牌、消息完整性、消息機密性、消息對SOAP中介的可見性、對安全Header的約束和消息壽命。例如，某一策略斷言可能要求所有消息都使用某一權(quán)威機構(gòu)提供的公鑰來簽名，或該身份驗證要基于Kerberos票。
系統(tǒng)聯(lián)盟
除了我們已經(jīng)介紹的方法以外，應(yīng)用程序安全性還需要更多的方法。例如，在某一信任域中有效的身份在其他信任域中很可能沒有意義。要讓不同信任域中的服務(wù)能夠驗證身份的有效性，就需要適當(dāng)?shù)臋C制。WS-Federation定義了一些機制，以支持身份、帳戶、屬性、身份驗證和身份驗證信息跨信任域的共享。利用這些機制，多個安全域可以通過在由多方參與的Web服務(wù)之間支持和代理身份、屬性和身份驗證的信任而結(jié)成聯(lián)盟。該規(guī)范擴展了WS-Trust模型，使屬性和筆名可以被整合到令牌發(fā)行機制中，從而形成一種多域身份映射機制。這些機制都支持單點登錄、退出和筆名，并描述了專業(yè)服務(wù)對于屬性和筆名的作用。
通過身份聯(lián)盟，很多要求都可以得到滿足。就拿將一名員工與其雇主關(guān)聯(lián)起來的例子來說，公司A的Jane從OfficeSupplyStore.com進行采購，公司A和OfficeSupplyStore.com之間有一個采購合同。因為Jane的身份是與公司A關(guān)聯(lián)的，所以可以讓她來依據(jù)該合同來進行采購。第二個例子是將一個人映射到多個筆名。大家可能只知道Joe使用joe@companya.com工作。他還可能有其他身份，如joe_bloggs@hotmail.com和josephb@cornell.edu。通過身份聯(lián)盟，系統(tǒng)可以確定這些身份都是同一個Joe。
Web服務(wù)聯(lián)合安全架構(gòu)中定義了兩個一般的請求者（消息發(fā)送者）類：被動和智能（活動）。被動請求者是只使用HTTP且從來不發(fā)出安全性令牌的服務(wù)。智能請求者是能夠發(fā)出包含諸如WS-Security和WS-Trust中所描述的那些安全性令牌的消息的服務(wù)。傳統(tǒng)的基于HTTP的Web瀏覽器就是被動請求者的一個例子。定義這兩種請求者的行為的概要規(guī)范現(xiàn)已開發(fā)出來。對于智能請求者，active請求者概要詳細說明了單點登錄、退出和筆名是如何通過使用SOAP消息而整合到Web服務(wù)安全模型中的。實際上，該概要描述了在智能請求者上下文中實現(xiàn)WS-聯(lián)盟中所描述的模式的方法。它詳細說明了各種安全性令牌的要求。作為這些安全性令牌要求中之一的一個例子，當(dāng)不使用安全通道時，X.509證書的整個令牌必須包含權(quán)威機構(gòu)的名稱和簽名。該概要還要求X.509令牌包含主題標識符，以唯一地識別授之以該令牌的主題。
發(fā)現(xiàn)（Discovery）
本節(jié)介紹Web服務(wù)架構(gòu)中用于定位網(wǎng)絡(luò)上Web服務(wù)和確定該服務(wù)可用性的功能組件：UDDI和WS-Discovery。Web服務(wù)發(fā)現(xiàn)是在沒有人工干預(yù)的情況下實現(xiàn)服務(wù)連接自動化的關(guān)鍵。Web服務(wù)發(fā)現(xiàn)方法反映了計算機系統(tǒng)中查找信息的兩個最常見方法：查看一個眾所周知的目錄，或?qū)⒁粋€請求廣播給所有可用的監(jiān)聽器。UDDI注冊表就相當(dāng)于該目錄，發(fā)現(xiàn)協(xié)議用于廣播請求。
目錄（Directory）
通用描述發(fā)現(xiàn)和集成協(xié)議，即UDDI——Universal Description Discovery and Integration Protocol，指定了一個用于查詢和更新Web服務(wù)信息通用目錄協(xié)議。該目錄包含關(guān)于服務(wù)提供商、它們所托管的服務(wù)以及這些服務(wù)所實施的協(xié)議的信息。該目錄還提供了用于向任何注冊信息添加元數(shù)據(jù)的方法。如果Web服務(wù)信息存儲在眾所周知的位置時，則可以使用UDDI目錄方法。一旦找到目錄，就可以發(fā)送一系列查詢請求以獲取想要的信息。UDDI目錄位置通常是通過系統(tǒng)配置數(shù)據(jù)從帶外（Out of Band）獲得的。
對于如何部署UDDI注冊表，Web服務(wù)提供商有很多不同的選擇。部署方案不外乎3個類別：公共、企業(yè)外和企業(yè)內(nèi)。為了支持公共部署，以Microsoft、IBM和SAP為首的一組供應(yīng)商主持推出了UDDI企業(yè)注冊表[UBR，UDDI Business Registry]。UBR是一個可跨多個主持企業(yè)復(fù)制的公共UDDI注冊表，它既是基于Internet的Web服務(wù)資源，又是Web服務(wù)開發(fā)者的一個試驗臺。盡管目前公共UDDI實施已經(jīng)受到了最大關(guān)注，但UDDI的早期采用者仍更傾向于使用企業(yè)外和企業(yè)內(nèi)方法。在這兩種部署情況下，企業(yè)要部署一個專用注冊表，而且更嚴密地控制注冊信息類型也是可能的。這些專用注冊表可能只供一個企業(yè)使用，也可能供若干組業(yè)務(wù)合作伙伴使用。UDDI還為注冊表間的復(fù)制和跨部署的信任聯(lián)盟定義了協(xié)議。使用這些協(xié)議進一步增加了可用于實施者的部署方案數(shù)量。對于所有的部署方案，UDDI目錄都包含了Web服務(wù)及其托管地的詳細信息。UDDI目錄項有3個主要部分——服務(wù)提供商、所提供的Web服務(wù)和實施綁定。其中的每一部分都逐漸提供有關(guān)Web服務(wù)的更詳細信息。
大部分的一般信息都描述服務(wù)提供商。該信息不針對Web服務(wù)軟件，而是針對直接負責(zé)該服務(wù)的開發(fā)者或?qū)嵤┱摺７?wù)提供商信息包括名稱、地址、聯(lián)系人及其他管理細節(jié)。所有的UDDI項都有多個元素來支持多語言描述。可用的Web服務(wù)列表存儲在服務(wù)提供商項中。這些服務(wù)可能是根據(jù)它們的預(yù)定用途來組織的：它們可能被分成不同的應(yīng)用領(lǐng)域、地區(qū)或任何其他適用的模式。存儲在UDDI注冊表中的服務(wù)信息只包含服務(wù)描述和一個指向它所包含的Web服務(wù)實施的指針。由其他提供商托管的服務(wù)鏈接稱為‘服務(wù)映射（Service Projection）’，也可能被注冊。
UDDI服務(wù)提供商實體的最后部分是實施綁定。該綁定將Web服務(wù)項與確切的URI關(guān)聯(lián)起來，以確定在何處部署服務(wù)，它還指定了訪問協(xié)議，并包含所實施的確切協(xié)議的參考資料。這些細節(jié)對于開發(fā)人員編寫調(diào)用Web服務(wù)的應(yīng)用程序已經(jīng)足夠。詳細的協(xié)議定義的是通過一個稱為“類型模型（即tModel，Type Model）”的UDDI 實體提供的。在許多情況下，tModel都會引用一個描述SOAP Web服務(wù)接口的WSDL文件描述，但tModel的靈活性也幾乎可以描述任何種類的資源。對于在UDDI中注冊的每一個提供商或服務(wù)來說，來自標準分類學(xué)（如NAICS和較古老的美國標準行業(yè)代碼）或其他身份識別方案（如Edgar Central Index Key）的元數(shù)據(jù)都可用于分類信息和提高搜索準確性。可用的分類學(xué)和標識符方案集作為任何實施的一部分，是可輕松擴展的，因此可以對其進行定制以支持任何特定的地域、行業(yè)或企業(yè)需求。
動態(tài)發(fā)現(xiàn)（Dynamic Discovery）
動態(tài)Web服務(wù)發(fā)現(xiàn)是以不同方式提供的。作為在已知注冊表中存儲信息的另一種方案，動態(tài)發(fā)現(xiàn)的Web服務(wù)會明確地聲明它們的到達、離開網(wǎng)絡(luò)。WS-Discovery為通過多路廣播消息來聲明和發(fā)現(xiàn)Web服務(wù)定義了協(xié)議。當(dāng)Web服務(wù)連接到網(wǎng)絡(luò)時，它通過發(fā)送一條Hello消息來聲明它的到達。在最簡單的情況下，這些聲明的跨網(wǎng)發(fā)送使用多路廣播協(xié)議——我們稱之為自組織網(wǎng)絡(luò)。該方法還最大限度地減少了網(wǎng)絡(luò)上的輪詢需要。為了限制網(wǎng)絡(luò)信息流通量和優(yōu)化發(fā)現(xiàn)過程，系統(tǒng)可能會包含一個發(fā)現(xiàn)代理。發(fā)現(xiàn)代理用一個眾所周知的服務(wù)位置取代了發(fā)送多路廣播消息的需要，從而將自組織網(wǎng)絡(luò)轉(zhuǎn)變成托管網(wǎng)絡(luò)。利用配置信息，代理服務(wù)集合可以連接在一起，從而將發(fā)現(xiàn)服務(wù)擴展到多組服務(wù)器，從一臺機器擴展到多臺機器。
因為發(fā)現(xiàn)代理自身也是Web服務(wù)，它們可能會用自己專用的Hello消息來聲明它們的到場。接收該消息的Web服務(wù)然后可以利用該代理的服務(wù)，而無需再使用干擾較多的一對多發(fā)現(xiàn)協(xié)議。當(dāng)服務(wù)離開網(wǎng)絡(luò)時，WS-Discovery會指定一個Bye消息以發(fā)送給網(wǎng)絡(luò)或發(fā)現(xiàn)代理。該消息通知網(wǎng)絡(luò)上的其他服務(wù)離開的Web服務(wù)不再可用。
為了完善這種服務(wù)聲明和離開的基本方法的不足，WS-Discovery定義了兩個操作——Probe和Resolve，以定位網(wǎng)絡(luò)上的Web服務(wù)。對于自組織網(wǎng)絡(luò)，Probe消息被發(fā)送給多路廣播組，并且與該請求匹配的目標服務(wù)會將響應(yīng)直接反饋給請求者。對于利用發(fā)現(xiàn)代理的托管網(wǎng)絡(luò)，Probe消息則以單路廣播方式發(fā)送給發(fā)現(xiàn)代理。如果按名稱定位Web服務(wù)，則使用Resolve消息。Resolve消息只以多路廣播模式發(fā)送。Resolve 類似于地址解析協(xié)議，即ARP，它將IP地址轉(zhuǎn)換成其對應(yīng)的物理網(wǎng)絡(luò)地址。WS-Discovery規(guī)范還支持這樣的系統(tǒng)配置：將Probe消息發(fā)送給一個已經(jīng)通過其他管理方法建立起來的發(fā)現(xiàn)代理，如通過使用眾所周知的DHCP記錄。
動態(tài)發(fā)現(xiàn)服務(wù)的能力實現(xiàn)了Web服務(wù)管理的自舉。與WS-Eventing及其他協(xié)議相結(jié)合，更復(fù)雜的管理服務(wù)也可以通過使用這種動態(tài)發(fā)現(xiàn)基礎(chǔ)架構(gòu)來構(gòu)建。動態(tài)發(fā)現(xiàn)還將Web服務(wù)架構(gòu)擴展到設(shè)備，如那些目前可能實施通用即插即用（UPnP）協(xié)議的系統(tǒng)——這是使該架構(gòu)真正實現(xiàn)通用的重要一步。例如，借助WS-Discovery和WS-Eventing，打印機或存儲介質(zhì)等設(shè)備可以作為Web服務(wù)納入到系統(tǒng)中，而且無需專門的工具或協(xié)議。
Web服務(wù)設(shè)備概要規(guī)范
Web服務(wù)設(shè)備概要規(guī)范對在資源受限的設(shè)備上應(yīng)該實施Web服務(wù)架構(gòu)規(guī)范家族的哪個子集提供了指導(dǎo)。該概要力圖在由于資源限制而作出折衷時，在可用的豐富功能和最重要的功能之間找到平衡。
一致性協(xié)議——可靠的消息傳遞和事務(wù)
本節(jié)介紹可以提供可靠的消息傳送、事務(wù)行為和能夠在一組Web服務(wù)之間進行顯式協(xié)調(diào)的Web服務(wù)架構(gòu)組件。定義這些功能的規(guī)范是WS-ReliableMessaging、WS-Coordination、WS-AtomicTransaction和WS-BusinessActivity。
當(dāng)多個Web服務(wù)必須完成工作的某一共同單元或依照某種共同的行為進行操作時，對于使用哪個協(xié)議必須達成共識。Web服務(wù)之間這種最低限度的協(xié)調(diào)是不可避免的。協(xié)調(diào)協(xié)議還必須能夠確定并同意已達成一個共同目標。Web服務(wù)之間的每一個交互都可以看作一種協(xié)調(diào)。一致性協(xié)議為該架構(gòu)提供了一個改進的機會，即參與者服務(wù)在它們準備共同完成的任務(wù)方面將獲得成功。在傳輸丟失了消息和服務(wù)失常時，Web服務(wù)架構(gòu)仍然能夠正常工作。
任何多方協(xié)調(diào)都可以通過接連地隨需加入更多參與者從兩方協(xié)調(diào)逐步發(fā)展而成。兩方協(xié)調(diào)可能是自發(fā)的，也可能需要一個指定的協(xié)調(diào)者。廣泛使用的自發(fā)協(xié)調(diào)協(xié)議的一個例子是同步請求—響應(yīng)消息傳遞模式。這是一致性協(xié)調(diào)的最簡單形式之一；對于每個工作請求，接收方Web服務(wù)必須完成所有預(yù)期工作之后才能向請求者返回數(shù)據(jù)。雙方都遵循這種嚴格的模式，無需顯式協(xié)調(diào)服務(wù)。
可靠的消息傳遞
很多情形都可能中斷兩個服務(wù)之間的消息交換。當(dāng)使用不可靠的傳輸協(xié)議（如HTTP 1.0和SMTP）來進行傳輸或當(dāng)消息交換跨多個傳輸層連接時，這更會成為一個問題。消息可能會丟失、被復(fù)制或重新排序，Web服務(wù)可能會失敗并失去易變狀態(tài)。WS-ReliableMessaging是一個基于特定的傳送保證特征實現(xiàn)可靠消息傳送的協(xié)議。該規(guī)范定義了3個可結(jié)合使用的不同斷言：
- At-Least-Once Delivery（至少一次傳送）：每條消息至少傳送一次。
- At-Most-Once Delivery（至多一次傳送）：不傳送重復(fù)的消息。
- In-Order Delivery（依次傳送）：按消息的發(fā)送順序傳送消息。
至少一次和至多一次保證相結(jié)合的結(jié)果是恰好進行一次傳送。由于Web服務(wù)架構(gòu)的設(shè)計與傳輸無關(guān)，因此所有傳送都與所用的通信傳輸工具或其組合無關(guān)。由于開發(fā)人員必須預(yù)測的潛在傳送失敗模式數(shù)量減少，故使用WS-ReliableMessaging可以簡化系統(tǒng)開發(fā)。
可靠的消息傳送不需要顯式協(xié)調(diào)者。當(dāng)使用WS-ReliableMessaging時，參與者必須根據(jù)SOAP消息Header中所發(fā)送的信息識別協(xié)議。作為一個組傳輸?shù)南⒓戏Q為消息序列（Message Sequence）。消息序列可以由發(fā)起者/發(fā)送者或Web服務(wù)創(chuàng)建，當(dāng)建立一種雙向關(guān)聯(lián)時通常由它們共同創(chuàng)建。序列是使用CreateSequence和CreateSequenceResponse消息顯式創(chuàng)建的。當(dāng)想要的最終結(jié)果是用兩個單向序列來充當(dāng)一個雙向序列時，發(fā)起者將提供Web服務(wù)所要使用的序列。該序列的ID由發(fā)起者包含在CreateSequence消息中。
WS-ReliableMessaging中定義了幾個策略斷言。這些策略斷言用WS-Policy中定義的方法來表示。
可靠的消息傳遞協(xié)議簡化了開發(fā)人員為在傳輸不斷變化的情況下傳輸消息而必須編寫的代碼。也就是說，底層基礎(chǔ)架構(gòu)可以對消息在端點之間的正常傳輸進行驗證，必要時還會轉(zhuǎn)發(fā)消息并檢測重復(fù)。應(yīng)用程序不需要任何附加邏輯來處理提供傳送可能需要的消息轉(zhuǎn)發(fā)、重復(fù)消息的消除、消息重新排序或消息確認。WS-ReliableMessaging的實施是跨發(fā)起者和服務(wù)分布的。那些非‘在線’可見的特征，如消息傳送順序，是通過實施WS-ReliableMessaging規(guī)范來提供的。雖然由傳輸損失導(dǎo)致的消息重發(fā)等特征是通過不為應(yīng)用程序所知的消息傳遞層來處理的，其他端到端特征（如依次傳送）都要求消息傳遞基礎(chǔ)架構(gòu)和接收應(yīng)用程序相互協(xié)作。當(dāng)發(fā)送者希望按發(fā)送順序提供消息排序時，在接收者一方卻按接收順序提供消息排序的情況是依次傳送的一種不正確實施——注意到這一點是很有趣的。當(dāng)發(fā)送者希望按接收順序提供消息順序時，在接收者一方按發(fā)送順序提供消息順序的情況，是依次傳送的一種正確實施。
指定的協(xié)調(diào)者
N路協(xié)調(diào)協(xié)議的某些族需要一個指定的協(xié)調(diào)者來引導(dǎo)一個工作單元通過一系列合作服務(wù)，一個例子是活動必須在不希望被同時連接的服務(wù)之間協(xié)調(diào)。只要每個參與者和協(xié)調(diào)者在某一時刻通信，協(xié)調(diào)就可能發(fā)生，結(jié)果就可能達成一致。Web服務(wù)架構(gòu)為指定的協(xié)調(diào)者定義了某些簡單操作。
WS-Coordination規(guī)范定義了一個可擴展的協(xié)調(diào)框架來支持需要顯式協(xié)調(diào)者的情況。該協(xié)議引入了一個稱為協(xié)調(diào)上下文（Coordination Context）的SOAP頭塊，用以唯一地識別聯(lián)合工作中將要著手進行的部分。為了啟動工作的接合部分，Web服務(wù)會向一個或多個目標服務(wù)發(fā)送協(xié)調(diào)上下文。收到協(xié)調(diào)上下文后，接收方服務(wù)會得到提示，說有聯(lián)合協(xié)作請求提出。協(xié)調(diào)上下文中包含了足夠的信息，請求接收者可以利用這些信息來確定是否參與該工作。協(xié)調(diào)上下文中包含的確切信息根據(jù)被請求工作的種類的不同而變化。
協(xié)調(diào)類型集是可擴充的。只要參與該聯(lián)合工作的每個服務(wù)對所需行為都有個一般的了解，新類型就可以通過實施來定義。例如，原子事務(wù)是Web服務(wù)架構(gòu)中已經(jīng)定義了的幾個初始基礎(chǔ)協(xié)調(diào)類型之一。如果被請求的協(xié)調(diào)類型被理解并被接受，Web服務(wù)就會使用WS-Coordination注冊協(xié)議來通知協(xié)調(diào)者并參與該聯(lián)合工作。協(xié)調(diào)上下文中包含了協(xié)調(diào)者的一個端點引用和可能行為的可選標識符。注冊操作指定該多方參與的Web服務(wù)所支持的行為。一旦注冊消息發(fā)送到協(xié)調(diào)者，Web服務(wù)就會依照它們所預(yù)訂的協(xié)議參與該工作。注冊是協(xié)調(diào)框架中的關(guān)鍵操作，它允許意欲協(xié)同配合以完成工作的共同單元的不同Web服務(wù)相互連接在一起。
WS-AtomicTransaction為Web服務(wù)指定了傳統(tǒng)的ACID事務(wù)，并為原子事務(wù)協(xié)調(diào)類型定義了3個協(xié)議：完成協(xié)議（Completion Protocol）和兩階段提交協(xié)議（Two-Phase Commit Protocol）的兩個變體。完成協(xié)議用于啟動提交處理。為完成而注冊的Web服務(wù)能夠通知指定的協(xié)調(diào)者何時開始提交處理。該協(xié)議還詳細說明了用于通知啟動者事務(wù)最終結(jié)果的消息。不過，該協(xié)議不要求協(xié)調(diào)者確保啟動者對結(jié)果進行處理。相反，WS-AtomicTransaction中的其他行為則要求協(xié)調(diào)者確保參與者對協(xié)調(diào)消息進行處理。
兩階段提交（2PC）協(xié)議為所有已注冊的參與者提供了一個公共的提交或中止決定，確保了所有參與者都能得到最終結(jié)果通知。顧名思義，它使用兩輪通知來完成該事務(wù)。該協(xié)議的兩個變體是：易失2PC（Volatile 2PC）和持久2PC（Durable 2PC）。這兩個協(xié)議在線上使用相同的消息（對應(yīng)于Prepare、Commit和Abort操作），但易失2PC沒有持久性要求。易失2PC協(xié)議供管理易失資源的參與者使用，如緩存管理器或窗口管理器。這些參與者在第一輪通知中不與協(xié)調(diào)者發(fā)生聯(lián)系，且不需要第二輪的通知。持久2PC協(xié)議供管理數(shù)據(jù)庫和文件等持久資源的參與者使用。當(dāng)某一提交處理已經(jīng)啟動時，在所有易失2PC參與者被聯(lián)系過之后這些參與者會第一次被聯(lián)系。這使緩存能夠被刷新。持久2PC參與者需要完整的兩輪通知來實現(xiàn)協(xié)調(diào)者所要求的全有或全無行為以及完成該事務(wù)。這些行為最適合于可以在整個事務(wù)期內(nèi)持有資源，且該事務(wù)通常為非常短暫的事務(wù)的情況。該協(xié)議保證在正常處理的情況下，協(xié)調(diào)者提供第一階段結(jié)果的同時將聯(lián)系所有參與者。對于完成時間預(yù)計將比較長的事務(wù)，或當(dāng)資源（如鎖）無法持有時，其他協(xié)調(diào)協(xié)議就會定義替換行為。
WS-AtomicTransaction中定義了若干策略斷言，這些策略斷言使用WS-Policy中定義的方法來表示。
排隊系統(tǒng)（Queued System）
構(gòu)建分布式系統(tǒng)時被證明非常有用的一種模式是使用事務(wù)持久隊列來提供存儲轉(zhuǎn)發(fā)異步消息傳送。在這種模式下，原子事務(wù)被用于每一個傳輸端點。在發(fā)送端，發(fā)送應(yīng)用程序以原子事務(wù)方式將消息發(fā)送給一個持久隊列，此時應(yīng)用程序和隊列管理器都使用WS-AtomicTransaction來進行協(xié)調(diào)。只有在處理消息時不發(fā)生錯誤，消息才被認為成功發(fā)送至該隊列。接下來，發(fā)送隊列和接收隊列之間消息的傳送由隊列子系統(tǒng)來接管。該傳輸步驟可以在消息置入發(fā)送隊列之后的某一時刻完成。此外，發(fā)送隊列的位置無需與發(fā)出消息的應(yīng)用程序的位置一致。與此類似，從接收隊列檢索消息的應(yīng)用程序也使用原子事務(wù)來執(zhí)行類似操作。也就是說，只有不出現(xiàn)處理錯誤時消息才能從隊列中移除。
持續(xù)時間長的活動（Long Duration Activities）
WS-BusinessActivity為運行時間長的事務(wù)指定了兩個協(xié)議。WS-BusinessActivity規(guī)范在事務(wù)提交之前并不鎖定資源，而是基于補償操作。底層事務(wù)模型是所謂的開放嵌套事務(wù)。這些協(xié)議系統(tǒng)化地說明了松耦合服務(wù)如何對已經(jīng)完成某一聯(lián)合任務(wù)達成一致意見。在其中的一個協(xié)議中，協(xié)調(diào)者顯式地通知參與者沒有更多的工作正在以聯(lián)合任務(wù)的名義被請求。在另一個協(xié)議中，該參與者就是通知協(xié)調(diào)者以聯(lián)合任務(wù)名義出現(xiàn)的工作已經(jīng)完成的參與者。使用補償操作可以在不鎖定這些操作的情況下完成試驗性操作。不管出于何故，只要系統(tǒng)想要撤消已完成的試驗性操作結(jié)果，就要啟動補償操作。WS-AtomicTransaction和WS-BusinessActivity都利用WS-Coordination來管理Web服務(wù)之間的協(xié)作。
三方握手
三方握手連接的建立和解除協(xié)議是不需要指定協(xié)調(diào)者服務(wù)的協(xié)調(diào)協(xié)議的一個例子。為了建立連接，發(fā)送者要向接收者發(fā)送一個請求。該請求建立一個會話。如果該請求被接受，接收者就會發(fā)出一條確認消息，對該請求作出積極響應(yīng)。發(fā)送者然后再發(fā)送一條消息，作為對該確認消息的確認，從而證明雙方都知道對方已經(jīng)建立了一個會話。
解除協(xié)議類似。一方向另一方發(fā)送一個會話解除請求。接收者以對解除消息的確認消息作為響應(yīng)。接收到該確認消息之后，發(fā)出解除消息的一方通過再對該確認消息發(fā)送一條確認消息結(jié)束消息交換。
枚舉、傳輸和事件
本節(jié)介紹提供Web服務(wù)架構(gòu)中的服務(wù)資源枚舉、其狀態(tài)管理和事件通知的規(guī)范。這些規(guī)范基于WS-Enumeration、WS-Transfer和WS-Eventing。
枚舉（Enumeration）
很多情況所要求的數(shù)據(jù)交換都使用不只一對的請求/響應(yīng)消息。需要這些更長時間數(shù)據(jù)交換的應(yīng)用類型包括數(shù)據(jù)庫查詢、數(shù)據(jù)流、命名空間等信息的遍歷和枚舉列表。特別是枚舉，它是通過建立數(shù)據(jù)源和請求者之間的會話來實現(xiàn)的。會話中接連不斷的消息用于傳送正在被檢索的元素的集合。對于該服務(wù)用于組織將要生成的項的方法不作假設(shè)。在正常處理的情況下，枚舉應(yīng)在會話結(jié)束前生成所有底層數(shù)據(jù)。
WS-Enumeration指定了用于建立枚舉會話和檢索數(shù)據(jù)序列的協(xié)議。枚舉協(xié)議允許數(shù)據(jù)源向正在使用的服務(wù)提供一個叫做枚舉上下文的會話抽象。該上下文通過一個數(shù)據(jù)項序列來表示邏輯光標。然后，請求者將該枚舉上下文用于一個或多個SOAP消息的某一區(qū)間以請求數(shù)據(jù)。枚舉數(shù)據(jù)表示為XML Infoset。該規(guī)范還允許數(shù)據(jù)源提供一種自定義機制來開始新的枚舉。既然枚舉會話可能需要若干個消息交換，那么會話狀態(tài)必須保持穩(wěn)定。
關(guān)于迭代進度的狀態(tài)信息可以由數(shù)據(jù)源或正在使用的服務(wù)在請求間維護。WS-Enumeration允許數(shù)據(jù)源一個請求一個請求地決定哪一方將負責(zé)維護下一個請求的狀態(tài)。這種靈活性實現(xiàn)了若干種優(yōu)化。例如，使服務(wù)器能夠避免對調(diào)用之間的任何光標狀態(tài)進行保存。由于消息潛伏時間對于支持若干個同時枚舉的服務(wù)來說可能會很長，不保存狀態(tài)可能會使必須維護的信息總量大大減少。資源受限設(shè)備（如移動電話）上的服務(wù)實現(xiàn)可能根本無法維護任何狀態(tài)信息。
傳輸（Transfer）
WS-Transfer詳細說明了對通過Web服務(wù)進行訪問的數(shù)據(jù)實體進行管理所需的基本操作。要了解WS-Transfer需要介紹兩個新術(shù)語：工廠（Factory）和資源（Resource）。工廠是能夠從其XML表示形式創(chuàng)建資源的Web服務(wù)。WS-Transfer引入了用于創(chuàng)建、更新、檢索和刪除資源的操作。應(yīng)當(dāng)注意，對于資源狀態(tài)維護，宿主服務(wù)器最多也只能做到盡力而為。當(dāng)客戶端獲知服務(wù)器接受了創(chuàng)建或更新某一資源的請求時，它可以適當(dāng)?shù)仡A(yù)期資源目前在的確定位置，并具有確定了的表示形式，但這并不是一個保證——即使是在沒有任何第三方的情況下。服務(wù)器可能會更改某一資源的表示形式，可能會徹底刪除某一資源，也可能會恢復(fù)已經(jīng)刪除的某一資源。這種保證的缺乏與Web提供的松耦合模型一致。如果需要，服務(wù)可以提供非Web服務(wù)架構(gòu)所必需的附加保證。
WS-Transfer的創(chuàng)建、更新和刪除操作擴展了WS-MetadataExchange中的只讀操作功能。檢索操作與WS-MetadataExchange中的Get操作完全相同。Create請求發(fā)送給工廠。然后，工廠創(chuàng)建被請求的資源并確定其初始表示形式。工廠被假定與所創(chuàng)建的資源不同。新資源被分配給一個在響應(yīng)消息中返回的，由服務(wù)決定的端點引用。Put操作通過提供一種替換表示形式來更新資源。資源表示形式的一次性快照與WS-MetadataExchange中的Get操作一樣，也可以通過WS-Transfer中的Get操作來檢索。Delete操作成功后，資源將無法再通過端點引用來使用。這4個元數(shù)據(jù)管理操作構(gòu)成了Web服務(wù)中狀態(tài)管理的構(gòu)建基礎(chǔ)。
事件（Eventing）
在由需要相互通信的服務(wù)構(gòu)成的系統(tǒng)中，可能會使用異步消息傳遞。在很多情況下，由一個服務(wù)生成的信息也是其他服務(wù)所需要的。由于伸縮性差，輪詢往往不是獲得這種信息的有效方法；通過網(wǎng)絡(luò)發(fā)送的不必要的消息太多了。相反，該架構(gòu)需要一種當(dāng)事件發(fā)生時發(fā)出顯式通知的機制。更重要的要求是源服務(wù)和用戶服務(wù)的綁定必須在運行時動態(tài)完成。為此，Web服務(wù)架構(gòu)提供了一個輕量級事件協(xié)議。
WS-Eventing詳細說明了實現(xiàn)下面4個實體交互的機制：訂戶、訂閱管理器、事件源和事件接收。這使某一Web服務(wù)在作為一個訂戶時能夠登記它對另一個Web服務(wù)（事件源）所提供的特定事件的興趣。這種注冊叫做訂閱。WS-Eventing定義了某一服務(wù)可以提供的支持訂閱創(chuàng)建和管理的操作。當(dāng)事件源判定有事件發(fā)生時，它就會將此信息提供給訂閱管理器。訂閱管理器然后可以將該事件傳送給所有匹配的訂閱，這類似于傳統(tǒng)的發(fā)布/訂閱事件通知系統(tǒng)中的發(fā)布主題。Web服務(wù)架構(gòu)提供了主題定義、組織和發(fā)現(xiàn)方式的全面靈活性；它為在很多不同的應(yīng)用場合中可能會用到的訂閱提供了一個通用的管理基礎(chǔ)架構(gòu)。也可以訂閱出租的資源，但最終都必須收回。用于收回資源的主要機制是各個訂閱的到期時間。查詢訂閱狀態(tài)同樣也有一種機制，幫助訂戶管理其若干訂閱事項（包括續(xù)訂、通知和取消訂閱的請求）的附加操作規(guī)范中也有詳細說明。當(dāng)然，任何服務(wù)都可以隨時自由地終止訂閱，這與所有Web服務(wù)的自主原則一致。訂閱終止消息可供事件源通知訂戶訂閱終止過早。
雖然基于事件的異步消息的一般模式很常見，但不同的應(yīng)用通常都要求使用不同的事件傳送機制。例如，在某些情況下簡單異步消息可能是最佳選擇，但如果事件接收能夠通過輪詢控制消息流和消息到達時間，則其他情況可能會更適用。當(dāng)接收無法從源頭到達目的地時，如接收有防火墻阻攔的情況下，輪詢也是必要的。WS-Eventing中所引入的傳送模式概念就是用來支持這些要求的。傳送模式被用作一個擴展點，以便為訂戶、事件接收和事件源建立定制的傳送機制提供一種手段。下述管理規(guī)范利用了這種機制。
事件代理可用于聚合或重新分配來自不同來源的通知，代理還可以用作獨立的訂閱管理器。這兩個方法都得到了WS-Eventing的支持。代理在系統(tǒng)中可以扮演若干個重要角色。主題可以按特定的應(yīng)用類來組織使用。代理可以充當(dāng)通知聚集器，用于整合來自多個來源的事件信息。它們也可以充當(dāng)過濾器，這比用于其自己通知的過濾器所接收的消息要多。這種靈活性是部署健壯而可伸縮的通知系統(tǒng)所必需的。
管理（Management）
管理功能是要討論的Web服務(wù)架構(gòu)的最后一個方面。這些功能在WS-Management規(guī)范中有詳細的說明。WS-Management構(gòu)建于該架構(gòu)的若干組件之上，提供了所有系統(tǒng)管理解決方案都必需的一個公共操作集。其中包括發(fā)現(xiàn)管理資源存在及其相互導(dǎo)航的能力。個別管理資源（如設(shè)置和動態(tài)值）可以被檢索、設(shè)置、創(chuàng)建和刪除。容器和集合的內(nèi)容，如大表和日志，可以被枚舉。規(guī)范最后定義了事件訂閱和特定的管理操作。在這些方面，WS-Management只詳細說明了最低的實現(xiàn)要求。規(guī)范還使符合WS-Management的實現(xiàn)可以部署到小型設(shè)備。同時，它還支持向大型數(shù)據(jù)中心和分布式安裝的擴展。此外，各種機制的定義都不依賴于任何暗示的數(shù)據(jù)模型或系統(tǒng)健康模型。這種獨立性使它可以應(yīng)用到各種各樣的Web服務(wù)。
WS-Management要求托管資源的引用使用帶有特定附加信息的端點引用。該信息包含了對該資源提供訪問的代理的URL、該資源所屬資源類型的唯一標識符URI以及識別該資源的零個或更多個密鑰。這些密鑰被假設(shè)為名稱/值對。該信息是這樣映射到WS-Addressing端點引用的：資源的URL映射到地址屬性，資源類型標識符映射到一個名為ResourceURI（在適當(dāng)?shù)腦ML命名空間中）的特定引用屬性，各密鑰分別映射到一個名為Key、屬性為Name的引用參數(shù)。為了滿足管理服務(wù)的消息傳遞需要，規(guī)范為操作定義了3個限定符。這些限定符的SOAP表示位于header元素中。operation timeout指定了一個截止時間，之后操作將不需要接受服務(wù)；locale元素在需要或期望轉(zhuǎn)換底層信息時使用；freshness限定符用于請求最新的值并避免返回陳舊數(shù)據(jù)。對于使用WS-Transfer操作的數(shù)據(jù)訪問，WS-Management指定了另外3個限定符。Get操作可用于SummaryPermitted header和NoCache header。如果可用，SummaryPermitted限定符允許傳輸簡略表示形式。NoCache限定符要求傳輸最新數(shù)據(jù)，禁止信息緩存。對于Put和Create操作，ReturnResource限定符要求服務(wù)返回資源的新表示形式。ReturnResource使資源受限的Web服務(wù)能夠在更新資源時不保留狀態(tài)。
WS-Management為事件通知定義了3個自定義的傳送模式：批、拉和捕獲。這些模式都由URI來識別，這些URI在建立訂閱時使用。批傳送模式使訂戶能夠接收捆綁在一個SOAP消息中的多個事件消息。訂戶可能還會要求捆綁某一最大數(shù)目的事件、服務(wù)收集事件可耗用的最長時間，以及應(yīng)返回數(shù)據(jù)的最大量。拉傳送模式使生成服務(wù)的數(shù)據(jù)能夠維護事件的邏輯隊列，以便訂戶能夠按需輪詢通知。該輪詢是通過使用WS-Enumeration和返回時附帶訂閱響應(yīng)消息的枚舉上下文來完成的。最后，如果UDP多路廣播是一種合適的消息傳遞方式，捕獲傳送模式便允許事件源使用它。在捕獲模式下，事件源可以將其通知發(fā)送給某一預(yù)定義的UDP多路廣播地址。
結(jié)束語
本文介紹了Web服務(wù)架構(gòu)的功能構(gòu)造塊及其底層原理。每個構(gòu)造塊都是依據(jù)協(xié)議規(guī)范來闡述的。我們希望本文所述的功能范圍和指導(dǎo)原則保持不變。不過我們也希望架構(gòu)能夠得到擴展，以支持更多情況。能夠支持創(chuàng)新是該架構(gòu)的基本特征。
已經(jīng)進行的大量細致入微的工作可以確保各種Web服務(wù)協(xié)議能夠不加變動地相互組合；盡管是一起設(shè)計的，它們?nèi)钥梢砸苑浅６嗟慕M合方式來使用。和功能構(gòu)造塊一樣，它們的使用方式與傳統(tǒng)開發(fā)框架類似。必要時，如對于SOAP附件，我們已經(jīng)開發(fā)了新的解決方案，而且不加變動它們就可以很好地用于該架構(gòu)內(nèi)。關(guān)注組合不是對豐富功能的威懾。
該架構(gòu)的SOAP消息傳遞基礎(chǔ)保證了 foundation assures wide reach。SOAP消息傳遞以一種傳輸獨立的方式支持異步和同步模式。具有更高靈活性的基礎(chǔ)架構(gòu)不存在。為了加快Web服務(wù)架構(gòu)的廣泛采用，很多技術(shù)合作伙伴都參與了這些規(guī)范的制定。與這些重要技術(shù)提供程序的合作加快了設(shè)備和支持這些在線協(xié)議的編程環(huán)境的部署。實現(xiàn)廣泛覆蓋、廣泛采用和與規(guī)模無關(guān)的構(gòu)造是我們的3個核心目標。我們力爭確保該架構(gòu)能夠在任何平臺上用任何編程語言來實現(xiàn)。該架構(gòu)基于消息的和基于協(xié)議的特性為此提供了便利。必要時，如只使用WS-Security來支持消息完整性、機密性和身份驗證，以及只使用WS-Policy來表示元數(shù)據(jù)時，我們已經(jīng)限定了用于提高互操作水平的技術(shù)方法的使用領(lǐng)域。理論上講，只要實現(xiàn)切實遵守該架構(gòu)的協(xié)議規(guī)范，它們就能與其他任何Web服務(wù)通信。
附錄A：術(shù)語表
活動請求者（Active Requestor）——活動請求者是能夠發(fā)出如WS-Security和WS-Trust中所述的Web服務(wù)消息的應(yīng)用程序（可能是Web瀏覽器）。
身份驗證（Authentication）——驗證安全憑證的過程。
授權(quán)（Authorization）——根據(jù)提供的安全憑證授權(quán)訪問安全資源的過程。
規(guī)范化（Canonicalization）——將XML文檔轉(zhuǎn)換成符合每一方要求的格式的過程。在簽名文檔和解譯簽名時使用。
斷言（Claim）——斷言是對發(fā)送者、服務(wù)或其他資源（如名稱、身份、密鑰、組、特權(quán)、功能等）所作的陳述。
協(xié)調(diào)上下文（Coordination Context）——一組協(xié)調(diào)服務(wù)要完成的一組工作的唯一標識符。
反序列化（Deserialization）——從一個八位字節(jié)流構(gòu)建XML Infoset的過程。它是用于從消息的有線格式創(chuàng)建消息的Infoset 表示形式的方法。
摘要（Digest）——摘要是八位字節(jié)流的加密校驗和。
域（Domain）——安全域代表安全管理或信任的一個單元。
持久的兩階段提交（Durable Two Phase Commit）——用于文件或數(shù)據(jù)庫等持久資源事務(wù)的協(xié)議。
有效策略（Effective Policy）——有效策略，針對某一給定的策略主題，是附加在包含該策略主題的策略范圍上的策略組合。
交換模式（Exchange Pattern）——用于服務(wù)之間消息交換的模式。
工廠（Factory）——工廠是可以從XML表示形式創(chuàng)建資源的Web服務(wù)。
聯(lián)盟（Federation）——聯(lián)盟是已經(jīng)建立相互信任的信任域的集合。信任級別可能變化，但通常都包括身份驗證，并可能包括授權(quán)。
身份映射（Identity Mapping）——身份映射是創(chuàng)建身份屬性之間關(guān)系的一種方法。某些身份提供程序可能會利用身份映射。
身份提供程序（IP，Identity Provider）——身份提供程序是為最終請求者提供身份驗證服務(wù)的實體。身份提供程序還為服務(wù)提供程序提供數(shù)據(jù)源驗證服務(wù)（這通常是安全性令牌服務(wù)的一種擴展）。
消息（Message）——消息是可由服務(wù)發(fā)送或接收的完整數(shù)據(jù)單元。它是信息交換的獨立單元。無論何時消息都會包含SOAP信封，并有可能包含附加MTOM中指定的MIME部件、傳輸協(xié)議header。
消息路徑（Message Path）——遍布在初始源和最終接收者之間的SOAP節(jié)點集。
被動請求者（Passive Requestor）——被動請求者是一個使用得到普遍支持的HTTP（如HTTP/1.1）的HTTP瀏覽器。
策略（Policy）——策略就是策略選項集。
策略選項（Policy Alternative）——策略選項就是策略斷言集。
策略斷言（Policy Assertion）——策略斷言表示特定于域的單個要求、功能、其他屬性或行為。
策略表達式（Policy Expression）——策略表達式是策略的XML Infoset表示形式，可以是正規(guī)形式，也可以是等同的壓縮形式。
主體（Principal）——可以被授予安全權(quán)限或可以給出安全性或身份斷言的任何系統(tǒng)實體。
協(xié)議組合（Protocol Composition）——協(xié)議組合是在保持技術(shù)連貫性的同時組合協(xié)議并避免任何非指定功能副作用的能力。
資源（Resource）——資源是可由端點引用尋址的任何實體，在該端點引用中，該實體可以提供其自身的XML表示形式。
安全上下文（Security Context）——安全上下文是一個抽象概念，指的是已建立的身份驗證狀態(tài)和可能具有與安全有關(guān)的附加屬性的協(xié)商密鑰。
安全上下文令牌（Security Context Token）——安全上下文令牌（SCT）是安全上下文抽象概念的有線表示形式，它使上下文能夠被URI命名并和一起使用。
安全性令牌（Security Token）——安全性令牌用于表示一組斷言的集合。
安全性令牌服務(wù)（Security Token Service）——安全性令牌服務(wù)（STS）發(fā)行安全性令牌的Web服務(wù)。更確切地說，它根據(jù)它所信任的證據(jù)來作出斷言，并發(fā)送給信任它的任何一方（或特定接收者）。為了表明信任，服務(wù)需要證據(jù)（如簽名），以證實安全性令牌或安全性令牌集提供的信息。服務(wù)本身可以生成令牌，也可以通過它自己的信任陳述依靠某一獨立的STS發(fā)行安全性令牌（注意，對于某些安全性令牌格式，這只能是重新發(fā)行或聯(lián)合簽名）。這構(gòu)成了信任代理的基礎(chǔ)。
序列化（Serialization）——將XML Infoset表示為八位字節(jié)流的過程。它是用于創(chuàng)建消息的有線格式的方法。
服務(wù)（Service）——通過消息來與其他實體進行交互的軟件實體。注意，服務(wù)不需要連接到網(wǎng)絡(luò)。
簽名（Signature）——簽名是通過加密算法計算出來，并綁定到數(shù)據(jù)的一個值。而且經(jīng)過綁定，數(shù)據(jù)的指定接收者可以使用該簽名來驗證數(shù)據(jù)沒有改變并發(fā)自消息的簽名者，從而提供了消息完整性和身份驗證。簽名的計算和驗證可以通過對稱或非對稱密鑰算法來進行。
退出（Sign-Out）——退出是這樣一個過程：某主體表明它們將不再使用其令牌且該域中的服務(wù)可能會破壞該主體令牌緩存。
單點登錄（SSO，Single Sign On）——單點登錄是對身份驗證序列的一種優(yōu)化，旨在消除在請求者身上進行的反復(fù)操作負擔(dān)。為了便于進行SSO，稱為身份提供程序（Identity Provider）的元素能夠以請求者的名義充當(dāng)代理，將身份驗證事件的證據(jù)提供給請求該請求者信息的第三方。這些身份提供程序（IP）是受信任的第三方，既需要得到請求者的信任（以維護請求者的身份信息，因為該信息的丟失可能會泄露請求者身份），又需要得到Web服務(wù)的信任，Web服務(wù)可能會根據(jù)該IP提供的身份信息的完整性提供對重要資源和信息的訪問權(quán)。
SOAP中介（SOAP Intermediary）——SOAP中介是一個SOAP處理節(jié)點，它既不是原始消息發(fā)送者，也不是最終接收者。
對稱密鑰算法（Symmetric Key Algorithm）——一種加密算法，其中的消息加密和解密都使用相同的密鑰。
系統(tǒng)（System）——實現(xiàn)某一特定功能的服務(wù)的集合。與分布式應(yīng)用程序意思相同。
信任（Trust）——信任表示一個實體愿意依靠另一個實體來執(zhí)行一組操作，對一組主題、范圍作出一組斷言。
信任域（Trust Domain）——信任域是一個得到有效管理的安全空間，在其中，請求的來源和目標可以確定來自某一來源的特定憑證集是否符合該目標的相關(guān)安全策略，并對此達成一致。目標可以將信任決定延期至第三方的加入（如果這已被確立為一致意見的一部分），從而將受信任的第三方包括在信任域中。
易失的兩階段提交（Volatile Two Phase Commit）——用于緩存或窗口管理器等易失資源事務(wù)的協(xié)議。
Web服務(wù)（Web Service）——Web服務(wù)是一種可重復(fù)使用的軟件組件，它依據(jù)XML、SOAP和其他業(yè)界公認的標準通過網(wǎng)絡(luò)實現(xiàn)交互式的消息交換。
附錄B：XML Infoset信息項
XML文檔可以包含11類信息項。下面，我們列出并詳細說明了SOAP所支持的信息項，并簡要介紹了其他的信息項。SOAP支持6類信息項：
- 文檔（Document）：每個信息集里都有一個文檔信息項。它用于引用所有的其他信息項。
- 元素（Element:）：文檔中每個XML元素的信息集中都包含一個元素信息項。對所有元素的訪問是通過對Child屬性的遞歸跟蹤提供的。
- 屬性(Attribute)：文檔中每個屬性的信息集中都包含一個屬性信息項。附加屬性信息項用于命名空間。
- 命名空間(Namespace)：每個在其父元素范圍內(nèi)的名稱空間信息集中都包含一個名稱空間信息項。
- 字符(Character)：文檔中每個數(shù)據(jù)字符的信息集中都包含一個字符信息項。
- 注釋(Comment)：除了出現(xiàn)在DTD中的以外，文檔中每個注釋的信息集中都包含一個注釋信息項。
SOAP不支持但出現(xiàn)在XML Infoset初始定義中的5類信息項是：處理指令(Processing Instruction)、文檔類型聲明(Document Type Declaration)、未擴展的實體引用(Unexpanded Entity Reference)、未解析實體(Unparsed Entity)和表示法(Notation)。
附錄C：常見的安全攻擊
對分布式系統(tǒng)的攻擊可以分為若干個方面。它們可以指向系統(tǒng)中的一個或多個主機，或指向它們之間的通信網(wǎng)路。攻擊的目的可能是中斷操作、獲得機密信息或在系統(tǒng)內(nèi)部執(zhí)行未授權(quán)的操作。它們可能會攻擊系統(tǒng)中所使用的加密技術(shù)或以安全性為中心的其他技術(shù)，也可能企圖通過攻擊下面的系統(tǒng)和網(wǎng)絡(luò)層或上面的應(yīng)用層來旁路它們。以下是一個簡短的不全面的安全性攻擊類及針對每類攻擊的標準對策的列表，它們是按上述的幾個方面組織編排的：
對主機的攻擊
- 拒絕服務(wù)（DoS，Denial-of-Service）攻擊通過擊垮主機的響應(yīng)能力來中斷其操作
當(dāng)指向加密層時，DoS通常會盡力迫使主機反復(fù)執(zhí)行特定身份驗證或密鑰交換協(xié)議所需的計算代價高昂的公鑰操作。對抗這類攻擊的典型防御措施是延遲公鑰操作，直到對話者的合法性能夠通過花費較少的方法（如對稱加密或“謎語”）來驗證時為止。DoS對底層網(wǎng)絡(luò)層或頂層應(yīng)用層的攻擊很難預(yù)防，特別是在攻擊者控制著大量資源且通信量處于正常通信量難以覺察的情況下。要實現(xiàn)網(wǎng)絡(luò)基礎(chǔ)架構(gòu)的部署，通常必須通過漏斗方式將通信量降至一個可管理水平。
- 主機機密性或授權(quán)攻擊企圖泄露隱私或身份
這些攻擊可能會利用主機軟件中的薄弱點來獲得對主機的控制。適當(dāng)?shù)陌踩怨芾恚绨惭b補丁、配置防火墻以及削減暴露應(yīng)用程序的特權(quán)，是比較常用的對策。另一類攻擊利用系統(tǒng)或應(yīng)用程序中的弱點，如設(shè)置不正確的策略或應(yīng)用程序邏輯錯誤，除了一般的主機泄密以外，它們還會考慮機密性或授權(quán)泄密。恰當(dāng)?shù)陌踩圆呗怨芾砗椭苊艿膽?yīng)用程序設(shè)計是對付這類攻擊的唯一防御措施。在“電子欺騙”攻擊中，攻擊者企圖通過冒用某一經(jīng)過授權(quán)的其他方的身份并做出相應(yīng)的行為來獲得對各種操作的授權(quán)。只要主機和經(jīng)授權(quán)方切實保護好身份驗證密碼，并正確使用安全的身份驗證協(xié)議，就可以預(yù)防電子欺騙。
對通信網(wǎng)路的攻擊
- DoS對網(wǎng)絡(luò)的攻擊試圖中斷與服務(wù)的通信
和對主機網(wǎng)絡(luò)層的攻擊一樣，這些攻擊確實也只能使用網(wǎng)絡(luò)基礎(chǔ)架構(gòu)方法來應(yīng)對。
- 對網(wǎng)絡(luò)通信機密性的攻擊企圖在線泄露隱私
明文通信的直接監(jiān)聽可以通過加密來阻止。通過足夠強大的加密算法和足夠長的密鑰，密碼分析攻擊也可以被扼制。
- 對網(wǎng)絡(luò)通信授權(quán)的攻擊企圖泄露身份
攻擊者企圖將消息插入會話的“消息偽造攻擊”和攻擊者修改會話中發(fā)送的消息的消息，變更攻擊都可以通過包含消息身份驗證的消息安全性協(xié)議來阻止。攻擊者將以前發(fā)送的（因而通過了正確的身份驗證）消息插入會話的消息重放，攻擊可以通過序號或時間戳和消息緩存的組合來檢測和阻止。