作者：Mark Fussell
Microsoft Corporation 首席專案經理
http://weblogs.asp.net/mfussell

2005 年 6 月

適用於：
   Web Services Enhancements 3.0 for .NET

摘要： Web Services Enhancements for .NET (WSE) 是一項能讓您快速且輕鬆地建置安全 Web 服務的產品。本文旨在說明最新版 WSE 3.0 背後的推動目標，文章著重於介紹主要功能，以及如何運用這些功能開發出以 Web 服務規則為主的分散式應用程式。(此文章包含連至英文網頁的連結，列印共 28 頁)

目錄

WSE 3.0 的設計宗旨
輕鬆建置安全的 Web 服務
重新建立工作階段
Web Farm 裡的工作階段
簡化的服務導向系統開發作業
互通性和與未來技術的兼容性
總結
參考資料

簡介

Web 服務已經有五年之多的歷史，至少從 .NET Framework 的角度來看是這樣子的。在分散式運算當道的今天，為了因應安全性、可靠性且交易性的通訊需求，實踐互通性與跨平台整合兩個目標，Web 服務規格 (也稱為 WS-* 通訊協定) 受到驅使而不斷蛻變。要想全面瞭解 Web 服務架構，請閱讀《An Introduction to the Web Services Architecture and Its Specifications》。

Web Services Enhancements 又名 WSE，他的英文發音與「Wizzy」一字相同，是開發人員的新工具，讓您在將安全性整合至連線系統應用程式時，不再拘泥於規格上的細節。WSE 主要是把訊息層級的安全性引入分散式應用程式的開發。《Why WSE?》一文裡就舉例說明這種情況。基本上，它就是要提昇應用程式架構開發的靈活度。如果您觀察一下 WS-* 規格，就會發現一個趨勢，也就是主要功能會從傳輸通訊協定層級 (安全性、可靠性、工作階段管理) 提昇到訊息通訊協定層級 (WS-Security、WS-ReliableMessaging、WS-SecureConversation)，而與同意的資料交換規格 (XML、XML Schema、SOAP、WSDL) 以及現有傳輸通訊協定 (HTTP、TCP、UDP) 組合在一起時，這可以提供具適用性 (Adaptability) 及延伸性的應用程式，達到互通性與整合性的目標。

Aaron Skonnard 在他的文章《What's New in WSE 2.0》裡提供了詳盡的 WSE 2.0 概觀說明，其中大部分內容仍適用於 WSE 3.0。話雖如此，閱讀完本篇文章的介紹後，您會發現 WSE 已經成熟許多，正邁向 3.0 版的時代，提供絕佳的可用性 (Usability)，而在建置安全性、服務導向應用程式方面，互通性和簡化性 (Simplification) 也受到大幅改善。

WSE 3.0 的設計宗旨

WSE 3.0 基本上是一個 Web 服務的安全性產品。WSE (1.0 和 2.0) 專案構想剛誕生時，其主要目的是展示一個實際而且可用的實作方法，實作新興的 WS-* 安全性規格，像是 WS-Security、WS-Trust 和 WS-SecureConversation，進而提供標準化流程相關的回應。它並不僅限於安全性規格，也推動了其他種的規格，例如，WS-Addressing (如何將訊息從傳送者手裡送達最終目的地) 和 WS-Attachments (如何與訊息一同寄送相關附件)。現在 WS 安全性規格已大幅度受到整合，也因此 WSE 3.0 版的目的不再是影響新興的規格 (雖然它實作較新版的規格版本)，而是要認清，Web 服務已廣用於許多開發領域，它必須擴充 Visual Studio 的現有 Web 服務支援，而首要工作就是解決、簡化開發人員在現實世界裡所面臨的問題。

WSE 3.0 的設計宗旨如下：

輕鬆建置安全的 Web 服務： 它不僅是一個簡單、在直覺上又容易使用的 API 設計，目的更是要在保全端對端訊息之際，也提取出常見的最佳要領。從一項對數百名 WSE 客戶所進行的調查結果顯示，訊息層級安全性可分為五種常見的情況，它們叫做「周全」(Turnkey) 傳訊安全性情況，能提供高層級安全性建置區塊，讓您專注在 Web 服務商務邏輯所鞏固的內容。

採用 Web 服務通訊協定與 .NET Framework 2.0 簡化服務導向系統的開發工作： 依照目標 Web 服務規格，繼續提供方便使用的程式設計 API 抽象層，引進最新、最根本的規格 (例如，Message Transmission Optimization Mechanism (MTOM))，善用 .NET Framework 2.0 的改進之處，並提供一組與 Visual Studio 2005 整合的工具。

互通性和與未來技術的兼容性： 長期來看，分散式運算開發環境會以 Indigo 為中心，而 WSE 3.0 有兩種方法帶領您邁向 Indigo。第一，使用 HTTP 時 ，WSE 3.0 保證與 Indigo 在底層協定 (Wire-Level) 方面互通，第二，在周全安全性情況，以及在全面受支援產品內以服務導向 (Service Orientation，SO) 原則來建置分散式應用程式兩方面，WSE 3.0 引進與 Indigo 相似的設計概念。WSE 3.0 也經過其他廠商的 Web 服務堆疊測試，確定具有跨平台互通性。

WSE 產品團隊本著上述的設計宗旨，著手建置 WSE 3.0 的功能。

注意   本文所列舉之範例，截自於 WSE 3.0 QuickStarts，這在您安裝 WSE 3.0 後，可於 /Program Files/Microsoft WSE/v3.0/Samples 資料夾內找到。

輕鬆建置安全的 Web 服務

本節內容會介紹能改善現有 WSE 2.0 安全性功能的功能，主要著重於解決可用性問題，以及提供方法更輕鬆處理常見的狀況。除了互通性之外，WSE 3.0 的另一個開發重點是要簡化訊息層級安全性，進而改善可用性。詳細資訊會利用訊息層級周全安全性情況來介紹。

周全安全性情況

WSE 被數百家企業級客戶用來建置分散式應用程式已有兩年多的時間，我們於是得以從常見的保全訊息情況下觀察出一些規律來。下面 [表 1] 就一一列出這些情況與相關說明，並提供典型的部屬用途，但它們的用途不只有這些，通常還端視其他的部屬考量而定。一般來說，在建置安全 Web 服務時，只要選擇其中一種周全安全性情況，就能心無旁鶩，專心構思服務的商業邏輯。

[表 1] 以周全安全性情況作為最佳的訊息安全性原則

周全安全性情況	說明	典型用途
UsernameOverTransport	在這種情況裡，安全保護是在「傳輸層級」(舉例而言，SSL 憑證) 上進行的，它利用提供的使用者名稱及密碼 (跟 Active Directory、ADAM 或 SQL Server 等存放區比對進行驗證) 來辨識用戶端。	為「服務」所知的人士。從網際網路向當中的應用程式之安全性基礎結構有限的網際網路或內部網路進行呼叫。通通常第一步會使用 SSL，然後於防火牆內使用另一種周全安全性情況，例如 Kerberos。
UsernameOverCertificate	在這種情況裡，安全保護是透過伺服器的 X.509 憑證來進行的，並利用提供的使用者名稱及密碼 (跟 Active Directory、ADAM 或 SQL Server 等存放區比對進行驗證) 來辨識用戶端。	為「服務」所知的人士。從網際網路向當中的應用程式為智慧型用戶端 (例如，Windows Form 應用程式) 而且有維護公開金鑰基礎結構 (PKI) 的網際網路或內部網路進行呼叫。可利用 Click Once 技術來部署 Windows Form 應用程式和必要憑證。
AnonymousOverCertificate	在這種情況裡，安全保護是透過伺服器的 X.509 憑證來進行的，用戶端無法辨別或為匿名；換言之，凡具有某伺服器公開憑證的用戶端皆可安全地與該伺服器進行通訊。	為「服務」未知的人士。從網際網路向當中的應用程式為智慧型用戶端 (例如，Windows Form) 而且有維護公開金鑰基礎結構 (PKI) 的網際網路或內部網路進行呼叫。由於任何有伺服器公開憑證的人皆能連接到服務，因此僅限非重要服務才行得通，或是只有擁有所提供之伺服器公開金鑰的某些公司和個體能進行通訊。
MutualCertificate	在這種情況裡，雙方會交換 X.509 憑證，用於鞏固彼此間資料交換的安全性。	商務對商務 (B2B) 使用。跨網際網路或是僅於內部網路內，在電腦或應用程式伺服器之間。 可用於有限的對等網路，因為數目並不大。
Kerberos (Windows)	此情況中，應用程式位在一個或多個 Windows 網域之內，而 Kerberos 提供一個可設定的安全性基礎結構。Kerberos 還有其他優點，像是單一登入，還有它的效能也比搭配 PKI 與 X.509 憑證的方法還佳。進行驗證與訊息保護時，會用到 Kerberos 票證。Kerberos 也支援委派，允許服務代表呼叫使用者進行執行。	在可將 Microsoft Windows 機器和 Kerberos Domain Controller (KDC) 用作為安全性基礎結構的內部網路內。

介紹完這五種周全安全性情況後，讓我們進一步探討它們的用法，以更加了解它們的用途。

注意   為 Web 服務套用安全性應該是部署方面的考量，而非設計階段的考量。也就是說，您撰寫的應用程式應該能透過所指定的宣告式原則檔案 (Declarative Policy File) 在內部網路中執行，然後再以不同的宣告式原則檔案在網際網路上重新部署同樣的應用程式也一樣可行。

現在我們將探討兩種周全安全性情況：UsernameOverCertificate 和 Kerberos，這兩種情況常搭配用在端對端傳訊 (End-to-End Messaging) 的情況。

在下面的 [圖 1] 中，部署在網際網路上的某用戶端應用程式正與一個部署在內部網路上之防火牆內的 ASP.NET 應用程式伺服器進行通訊。此用戶端應用程式已安裝了伺服器的 X.509 憑證，以保護 (加密) 傳送到伺服器的訊息。由於 X.509 憑證會經過嚴格地加密編譯，還是使用最佳化技術比較有效率，表示要建立所謂的加密金鑰 (利用 X.509 的公開金鑰進行加密)，然後選擇從這個加密過的金鑰裡衍生出另一個金鑰，稱為衍生金鑰。衍生金鑰是用來簽署與加密訊息。訊息內會同時包含加密金鑰與衍生金鑰。衍生金鑰是一個對稱金鑰，在加密編譯的等級上比 X.509 憑證略低一籌。要送到伺服器的訊息會以用戶端所產生的衍生金鑰來簽署和加密，如此一來，伺服器就可以對所收到的訊息解密；該訊息內含有加密金鑰與衍生金鑰，受到伺服器的 X.509 憑證的保護。衍生金鑰比所收到的訊息的大小還小，因此只對它進行解密，再利用所得到的結果在伺服器上解密訊息，包括接收使用者名稱與密碼 (U/P) ，速度會比較快。U/P 是用來驗證使用者的，它還會決定使用者對 Active Directory、ADAM 或 SQL Server 等存放區的存取權限。請注意，在訊息裡，使用者名稱語彙基元會經過加密，如此能鞏固密碼的機密性。

[圖 1] 併用 UsernameOverCertificate 和 Kerberos 周全安全性情況，來鞏固從用戶端傳送至服務的訊息序列的安全性。

在 [圖 1] 的情況下，驗證來自網際網路的使用者，同時，應用程式伺服器對內部網路的另一個服務進行呼叫，在此例中，它位於另外一台不同的電腦上。此訊息所部署的安全性是 Kerberos，這可透過對應到領域帳戶所提供的 U/P 來取得，但如果是應用程式伺服器的話，則一般是透過機器帳戶的 U/P。在內部網路，Kerberos 使用方便，因此是個常用的選擇。當然，內部網路裡可能會有非 Windows 的機器，而 Kerberos 正朝著不同廠商之間的互通性標準安全性語彙基元邁進 (例如，WSE 和 Indigo 兩者皆成功地展示了在 Kerberos 上能與 IBM 互通)，但目前為止，還是最適合使用其他形式的安全性，像是 MutualCertificate 情況。

應用程式伺服器在呼叫內部網路服務來執行一些商務流程後，就可以把結果回應給用戶端。由於使用 U/P 來進行密碼編譯作業十分不當也不安全 (原因請參閱《Securing the Username Token with WSE 2.0》)，而且在 Indigo 也不可能使用 U/P 來密碼編譯作業，我們究竟如何才能保護傳回用戶端的訊息呢？既然用戶端送出的是一個對稱且加密的金鑰給伺服器，這表示用戶端已經知道這個金鑰，所以我們可以利用它來保護送回的訊息。因此，使用 X.509 憑證時，加密金鑰不僅能改善安全性作業的效能，而且不必使用 U/P 亦不需要伺服器安裝用戶端 X.509 憑證，就可以將訊息安全地回應給用戶端。用戶端收到應用程式伺服器送來的回應後，就能夠以它所儲存的加密金鑰進行解密，如此一來，整個端對端的訊息序列既安全又有效率。

在此提醒您一點，雖然我詳述了衍生金鑰產生如何保全用戶端對應用程式伺服器的呼叫，但實作細節全部是由特定的周全安全性情況替您處理。您不必知道也不用去想密碼編譯最佳化一事，只要瞭解哪個周全安全性情況最適合您的部署環境就夠了。您不必知道也不用去想密碼編譯最佳化一事，只要瞭解哪個周全安全性情況最適合您的部署環境就夠了。

瞭解周全安全性情況的原理後，我們來看看應如何進行實作。在 WSE 3.0 中，會採用原則檔案來進行。

原則與周全安全性情況

在我們開始討論 WSE 3.0 的新原則檔案之前，先回想一下 WSE 2.0。在 WSE 2.0 中，為了鞏固訊息交換而撰寫的程式碼與宣告式原則檔案之間並無關連。您需要在腦子裡先將該原則轉譯成 EncryptedData 和 MessageSignature 類別。WSE 3.0 中雖然還存在而且也還需要這些類別，不過在保全訊息安全性時，有一個實用而且簡單的程式設計模型，只要利用程式碼就能將原則套用到用戶端或服務。在 WSE 3.0 裡面，可以使用 Policy 屬性或 WSE 產生之用戶端 Proxy (透過 Visual Studio 的「加入 Web 參考」) 上的 SetPolicy 方法，就可以在程式碼中使用原則，保障用戶端或服務的安全性。實際上，強制式和宣告式的程式設計模型已經統一，能提供一貫的程式設計方式來套用原則。

下面程式碼說明如何在一個名為 WSSecurityUsernameService (請參看 /Security 子資料夾內的 WSSecurityUsername 範例) 的 .NET Web 服務設定 ServerPolicy 原則。此 Web 服務包含一個叫做 StockQuoteRequest 的單一 [WebMethod]，本文稍後會常提到。這個 Web 方法會接受一個堆疊符號陣列，然後傳回對應的引號。

[WebService(Namespace = "http://stockservice.contoso.com/wse/samples/2005/10")]
[Policy("ServerPolicy")]
public class WSSecurityUsernameService : System.Web.Services.WebService
{
   public WSSecurityUsernameService()
   {
   }
   [WebMethod]
public List<StockQuote> StockQuoteRequest([XmlArray(),
    XmlArrayItem("Symbol"] string[] symbols)
   {
// Business logic here
   }
}

在討論 ServerPolicy 之前，我們先談談原則是如何產生的。在 Visual Studio 2005 中，產生一個「New Web Site (新增網站)」專案，選取「ASP.NET Web Service (ASP.NET Web 服務)」範本，如 [圖 2] 所示。

[圖 2] Visual Studio 2005 內新的 ASP.NET Web 服務

建立新的 Web 服務之後，在 Visual Studio 裡以右鍵按一下 [Solution Explorer (方案總管)]，選取內容功能表底部的 [WSE Configuration Tool (WSE 設定工具)] 功能表選項。接著會出現「WSE 3.0 Configuration tool (WSE 3.0 設定工具)」。選取 [Enable this project for Web Services Enhancements (為 Web Services Enhancements 啟用本專案)] 和 [Enable Microsoft Web Services Enhancements Soap Protocol Factory (啟用 Microsoft Web Services Enhancements Soap Protocol Factory)] 核取方塊，它們能確保這個專案在處理 SOAP 訊息時會使用 WSE。接下來，選取 [Policy (原則)] 索引標籤，勾選 [Enable Policy (啟用原則)] 核取方塊，按一下 [Add (新增)] 按鈕，然後為將建立的新原則輸入一個名稱。如此就能透過「WSE Security Settings Wizard (WSE 安全性設定精靈)」來產生新的原則。在完成第一頁後，就會看到如 [圖 3] 所示的驗證頁面。

[圖 3] 「WSE Security Settings Wizard (WSE 安全性設定精靈)」的「Authentication Settings (認證設定)」頁面

您會發現，首先要決定的是要鞏固用戶端還是伺服器應用程式的安全。這些驗證模式是用來決定您的部署適合採用哪種周全安全性情況的第一步。建議您試試看各種設定，精靈會詢問您相關的問題，逐步引導您進行設定。舉例而言，要想採用 UsernameOverCertificate 情況，就得選擇 [Username (使用者名稱)] 的驗證方法，然後逐步回答精靈的問題。最終結果會產生一個能說明您安全性需求的原則，如下面 [圖 4] 所示。

[圖 4] 為 UsernameOverCertificate 周全安全性情況所建立的原則

按一下此螢幕內的 [Finish (完成)] 按鈕，會產生一個原則檔案，並且依照預設，會以 wse3policyCache.config 的名稱儲存。下面的原則是安全性設定精靈所產生的。

<policies>
  <extensions>
    <extension name="usernameOverCertificateSecurity" 
type="Microsoft.Web.Services3.Design.UsernameOverCertificateAssertion, 
Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, 
PublicKeyToken=31bf3856ad364e35" />
    <extension name="x509" type="Microsoft.Web.Services3.Design.X509TokenProvider, 
Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral,
 PublicKeyToken=31bf3856ad364e35" />
  </extensions>
  <policy name="ServerPolicy">
    <usernameOverCertificateSecurity establishSecurityContext="true" 
renewExpiredSecurityContext="true" signatureConfirmation="false" 
protectionOrder="SignBeforeEncrypting" deriveKeys="true" actor="">
      <serviceToken>
        <x509 storeLocation="LocalMachine" storeName="My"
     findValue="CN=WSE2QuickStartServer" 
     findType="FindBySubjectDistinguishedName" />
      </serviceToken>
      <protection>
        <request signatureOptions="IncludeAddressing, IncludeTimestamp, IncludeSoapBody" encryptBody="true" />
        <response signatureOptions="IncludeAddressing, IncludeTimestamp, IncludeSoapBody" encryptBody="true" />
        <fault signatureOptions="IncludeAddressing, IncludeTimestamp, IncludeSoapBody" encryptBody="false" />
      </protection>
    </usernameOverCertificateSecurity>
  </policy>
</policies>

如果您很熟悉 WSE 2.0 的原則檔案，就會發現這個 WSE 3.0 版的原則檔案已簡化許多。它是由已命名原則以及 項目 (例如，，<policy name="ServerPolicy">) 所集合而成的。。<policy> 項目內具有您所選取的周全安全性情況類型，在此例中，是 <usernameOverCertificateSecurity> 項目，而裡面有多項設定屬性，例如，是否要建立安全性工作階段，訊息受保護的順序等等。端視原則檔案產生的方式而定，<usernameOverCertificateSecurity> 可能會含有一個 <serviceToken> 或 <clientToken>，它們會依照所選的安全性設定來說明應於何處取得安全性憑證。上述的原則範例中，<serviceToken> 內就含有一個 <x509> 項目，來指明應如何保護抵達伺服器的要求。<x509> 項目裡面有些屬性，說明從哪裡可以取得這個語彙基元資訊 (包括存放區名稱、存放區的位置)，以及如何以一種唯一的方法來識別 X509 憑證。

<protection> 項目則會指出在要求、回應和錯誤訊息等訊息裡所要簽署和加密的部分。舉例而言，所有的請求訊息裡面，在預設的情況下都會簽署 WS-Addressing 標頭、安全性標頭時間戳記和訊息主體，但只會加密訊息主體 (若加密 WS-Addressing 標頭，則很難將訊息傳閱到最終目的地)。

在此建議您摸索一下安全性設定精靈，看看它產生的各種周全安全性情況，瞭解其相對的原則檔案內容。大部分而言都與上面所提到的相符。

原則架構

有關 WSE 3.0 的原則架構，我們日後會詳細探討，但在這裡先大概介紹一下，讓您瞭解它和周全安全性情況的關聯。原則會利用幾個可以加入、移除的判斷提示 (Assertion)，來說明輸入和輸出處理管道。這些判斷提示能建立篩選器，說明 XML 訊息從線上以 SOAP 訊息的型態流向應用程式，然後再傳出去的整個轉換過程。請看下面 [圖 5] 的說明。

[圖 5] WSE 3.0 的原則架構，說明判斷提示的管道

安全判斷提示 (由橘色方塊代表) 是發生在輸入管道開始及輸入管道結束的時候。追蹤判斷提示只會把訊息寫入記錄檔，但不會實際轉換訊息。您可以指定想要的管道順序，在任何地方插入自訂的判斷提示。舉例而言，某自訂判斷提示可以用已知的 XML 結構描述集合來驗證內送訊息。

使用周全安全性情況

瞭解周全安全性情況，知道原則是如何實作這些情況之後，現在我們來討論如何實際應用它們。WSE 3.0 版內隨附的 QuickStart 範例裡含有一組安全性範例，其中包括各種周全安全性情況。我們將討論 WSSecurityUsernamePolicy 範例，這個解決方案會說明如何應用 usernameOverCertificate 這種周全安全性情況。

我們前面解說過用安全性設定精靈所產生的伺服器原則檔案，也闡釋了如何透過 [Policy] 屬性將它套用到 Web 服務。現在，在同一個解決方案裡開啟用戶端主控台應用程式。這個用戶端專案裡，已經有一個利用「加入 Web 參考」內容功能表產生出來的 WSE Proxy。要鞏固傳送至伺服器的訊息的安全性，有兩種設定用戶端原則的方法。一是呼叫 Proxy 的 SetPolicy 方法，例如，

serviceProxy.SetPolicy("ClientPolicy"); 

二是運用在伺服器所採用的方法，在用戶端上使用 CLR [Policy] 屬性。不過，用戶端 Proxy 檔案是自動生成的，只要用戶端 Proxy 以 Add Web Reference 進行更新，就會失去所有加到用戶端的屬性。還好用戶產生的程式碼使用 .NET Framework 2.0 所引進的 CLR 部分類別，也就是說，我們可以在另一個檔案中套用 [Policy] 屬性，然後編譯器自己會編構完整的類別定義。如果您仔細閱讀 WSSecurityUsernameClient.cs 檔案，就會看到下面的註解程式碼，它說明了如何利用部分類別在用戶端上套用 [Policy] 屬性。

namespace localhost
{
    [Policy("ClientPolicy")]
  public partial class WSSecurityUsernameServiceWse : 
     Microsoft.Web.Services3.WebServicesClientProtocol {}
}

同一個檔案內，我們再來看看 Run 方法的用戶端程式碼 。

public void Run()
{
    // Create an instance of the Web service proxy
    WSSecurityUsernameServiceWse serviceProxy = new
 WSSecurityUsernameServiceWse();

    // Configure the proxy
    ConfigureProxy( serviceProxy );

    UsernameToken token = null;
    bool useCorrectPassword = true; 
    string username = Environment.UserName;
    byte[] passwordBytes = System.Text.Encoding.UTF8.GetBytes(username);
    Array.Reverse(passwordBytes);

    if (useCorrectPassword)
    {
        string passwordEquivalent = Convert.ToBase64String(passwordBytes);
        token = new UsernameToken(username, passwordEquivalent);
    }
    else
    {
        token = new UsernameToken(username, "BadPassword");
    }

    // U/P are set through code. X509 is set through policy.
    serviceProxy.SetClientCredential(token);
    
    // Set the ClientPolicy onto the proxy
    serviceProxy.SetPolicy("ClientPolicy");

    // Call the service
    Console.WriteLine("Calling {0}", serviceProxy.Url);
    String[] symbols = {"FABRIKAM", "CONTOSO"};
    StockQuote[] quotes = serviceProxy.StockQuoteRequest(symbols);

    // Success!
    Console.WriteLine("Web Service called successfully. Simple view:");
    foreach( StockQuote quote in quotes )
    {
        Console.WriteLine("");
        Console.WriteLine( "Symbol: " + quote.Symbol );
        Console.WriteLine( "/tName:/t/t/t" + quote.Name );
        Console.WriteLine( "/tLast Price:/t/t" + quote.Last );
        Console.WriteLine( "/tPrevious Change:/t" + quote.PreviousChange +
 "%");
    }
}

看過上述程式碼後，您會發現，使用者名稱和密碼會經由 usernameToken 類別在程式碼中設定，這比起在原則檔案裡面指定這些值，是比較好的方式。然後，以 SetClientCredential 方法將 U/P 設定為用戶端憑證，驗證用戶端傳送到伺服器的訊息。本例中使用 SetPolicy 方法來設定原則，該方法從檔案裡讀取名為 ClientPolicy 的原則，而最後以提供的堆疊引號符號來呼叫 StockQuoteRequest。如果您閱讀一下用戶端原則 (也儲存在 wse3PolicyCache.config 檔案中)，會發現，它和伺服器原則幾乎一模一樣，只有要存取伺服器 X.509 憑證的地方 (storeLocation) 不一樣。

如果您使用「WSE Configuration Tool (WSE 設定工具)」裡面的 [Diagnostics (診斷)] 索引標籤，開啟「WSE Tracing (WSE 追蹤)」功能來執行此範例，然後檢閱追蹤記錄檔，就能看到用戶端和伺服器之間傳送的訊息是採用 usernameOverCertificateSecurity 周全安全性情況來確保安全。那只需要產生用戶端和伺服器原則檔案，再利用 SetPolicy 方法和 [Policy] 屬性把檔案分別套用到用戶端及伺服器就可以了。

注意   WSE 3.0 不再實作 WS-SecurityPolicy，因為這個規則已經被歸到標準流程中，而且跟早期的 WSE 2.0 版比起來，變化很大。WSE 3.0 版裡面的原則應該被視為服務的一個設定繫結。

WSE 3.0 並不實作能讓您在服務上決定原則的 WS-MEX 來進行中繼資料交換，原則檔案需要以 Out-of-Band 方式來進行交換。

到此我們瞭解，無論是宣告式檔案還是強制式程式碼，WSE 3.0 原則都是一致的，提供了一個清晰、一貫的開發方式來鞏固用戶端及服務的安全性。

以 MTOM 傳送大量資料

MTOM 全名為「訊息傳輸最佳化機制」(Message Transmission Optimization Mechanisum)，能讓您以 SOAP 訊息有效傳送二進位資料。這裡的關鍵在於「最佳化」一字，因為開發人員可以明顯感覺得到其效果，而且只要設定為啟用，它就會自動進行。MTOM 是 W3C 推薦用來取代 DIME 和 WS-Attachment 的機制，是傳送文件檔案和影像等大量資料的最佳選擇。

和現有技術相比，MTOM 的主要優點有三。

1. 安全性： MTOM 的主要優點是它會以安全性來撰寫 (透過 WS-Security)，也就是說，資料和 SOAP 訊息均安全。若使用 DIME，附件並不安全 (除非您使用了傳輸層級安全性)，只要用任何 TCP 追蹤公用程式或是網路通訊協定分析工具，就能夠以純文字檢視附加的資料。
2. 縮減傳送大小： 使用 MTOM，二進位字元值會以 MIME 附件的方式傳送，而且這些值會受到 SOAP 訊息內文的參考。通常來說，由於 XML 1.0 只允許特定的字元範圍 (舉例而言，多半 < 0x20 的字元都不會被包含在 XML 文件中)，二進位資料會透過 base64 編碼演算法轉為 ASCII 字元 (請參閱 http://en.wikipedia.org/wiki/Base64)。而轉換後 base64 編碼資料會比原始二進位資料還長大約百分之三十三。MTOM 其實就是另一種編碼演算法，由於它不會帶來大小擴張的弊病，因此傳送資大小比較小。唯有在頻寬限制大到會影響訊息的時候，傳送大小才會是個問題。
   

   注意   雖然以安全性撰寫時，MTOM 能縮減傳送大小，但它無法縮短在用戶端或伺服器上的處理時間，用此鞏固訊息的安全性。原因是，WS-Security 需要資料轉成 base64，才能套用正規化和標準演算法，產生加密值，進而達到互通性。

3. 簡化的程式設計模型： 若採用 MTOM，就不需要像使用 DIME 時一樣，要使用個別的附件集合才能傳送資料。您只要撰寫服務，然後在應用程式的設定檔案中指明該服務支援 MTOM 編碼即可。所有從服務傳回的 byte[] 型別就會自動編碼成 MTOM。

探討完 MTOM 的優點後，我們來看看一個把二進位檔案從伺服器傳回用戶端的 Web 服務範例。下面程式碼所示範的服務，能將該檔案傳回成指定檔名的 GetFileResponse 型別。此程式碼摘自隨 WSE 3.0 範例附隨的 BinaryDataMTOM QuickStart 範例。

 [WebService(Namespace = "http://stockservice.contoso.com/wse/samples/2005/10")]
public class BinaryDataMTOMService : System.Web.Services.WebService
{
    //This WebMethod returns MTOM encoded binary data 
    [WebMethod]
    public GetFileResponse GetFile(string fileName)
    {
        GetFileResponse response = new GetFileResponse();
        response.FileName = fileName;
        String filePath = AppDomain.CurrentDomain.BaseDirectory +
  @"App_Data/" + fileName;
        response.FileContents = File.ReadAllBytes(filePath);  
        return response;
    }
}

// Web Method return type
[XmlRoot("getFileResponse", 
Namespace = "http://stockservice.contoso.com/wse/samples/2005/10")]
public class GetFileResponse
{
    [XmlElement("fileName", IsNullable = false)]
    public string FileName;

    [XmlElement("fileData", IsNullable = false)]
    public byte[] FileContents;
}

由於只要使用 File.ReadAllBytes 方法來讀取檔案，FileContents 就能以 byte[] 傳回，因此 GetFileResponse 型別正是 MTOM 的魔力所在。使用「WSE Configuration Tool (WSE 設定工具)」內的 [Messaging (傳訊)] 索引標籤，能透過設定在用戶端或伺服器上啟用 MTOM。[圖 6] 顯示了這些 MTOM 設定選項，只要把它們設定好，就能寫入用戶端的 app.config 檔案或是伺服器的 web.config 檔案。

[圖 6] MTOM 的設定選項

注意
MTOM 有三種伺服器模式： [optional (選用)]、[always (每次)]、[never (從不)]。

[always (每次)] 表示，服務「每次」都會要求來自用戶端的 MTOM 訊息，而且「每次」都會使用 MTOM 回應訊息。

[never (從不)] 表示，從來不會用到 MTOM，而且服務會拒絕 MTOM 要求。

[optional (選用)] (預設值) 表示，服務會依照用戶端所傳送的訊息種類以同樣的方式進行回應。如果用戶端傳送 MTOM 要求，它就會以 MTPM 回覆進行回應。

而用戶端 MTOM 有 [On (開啟)」和 [Off (關閉)] (預設值) 兩個值。

現在來看看呼叫 MTOM 服務所用的用戶端程式碼，它會傳回 GetFileResponse 型別 ，然後將檔案寫入磁碟內。注意看，它和呼叫 ASP.NET Web 服務來傳回檔案是一樣的，只不過它能利用 MTOM 將傳輸最佳化。

//Get winter.jpg file as a binary file 
//MTOM is enabled by default for the client in app.config via <mtom clientMode="On" /> element
String fileName = "Winter.jpg";
BinaryDataMTOMServiceWse serviceproxy = new BinaryDataMTOMServiceWse();
localhost.GetFileResponse response = serviceproxy.GetFile(fileName);

Console.WriteLine("File Name: {0}", response.fileName);
Console.WriteLine("Unsecured Bytes Received (at Client): {0}", response.fileData.Length);

File.WriteAllBytes(response.fileName, response.fileData);

您能呼叫 WSE 產生的 Proxy 上的 RequireMtom 方法，覆寫每個用戶端 Proxy 的 MTOM 組態設定。舉例而言，下面的程式碼關閉了 Proxy 的 MTOM。

serviceproxy.RequireMtom = false;

那麼多作業在進行之際，您怎麼知道二進位資料正透過連線在傳送當中呢？為了要目睹傳送作業，我們需要使用 TcpTrace.exe 這種 TCP 追蹤工具，您可於 http://www.pocketsoap.com/tcptrace/ 進行下載。

執行這個公用程式後 (記得要在用戶端 app.config 檔案內把連接埠 8080 加到 URL 中，或是在 reference.cs 檔案內把連接埠 8080 加到用戶端 Proxy 產生的程式碼裡面，如此才能確保要求訊息會通過 TcpTrace.exe 公用程式)，您就可以看到類似 [圖 7] 的訊息。

[圖 7] 使用 MTOM 從 Web 服務傳回二進位資料 (按影像看放大圖)

這個螢幕擷取畫面的最上方是來自用戶端的要求，中下方則是來自伺服器的 MTOM 編碼回應，裡面的重要資訊是在 <fileData> 項目裡，其內含有一個對各別 MIME 界限的 xop:Include 參考。

<getFileResponse>
  <fileName>Winter.jpg</fileName>
  <fileData>
    <xop:Include href="cid:1.632536037467392@example.org" />
  </fileData>
</getFileResponse>

螢幕擷取畫面中下方具有 cid:1.63253603746739 的 MIME 界限包含來自伺服器的 winter.jpg 檔案的二進位資料。

以 MTOM 資料流處理二進位資料

前面使用 MTOM 的程式碼範例是先將檔案載入到伺服器上的 FileContents byte[]，之後再於伺服器上快取檔案。如果檔案很大，而且要求又多，則會耗用伺服器上大量的記憶體。在此建議您，最好能經由伺服器到用戶端的網路資料流，來資料流處理檔案。就利用 HTTP 裝載到 IIS 的 ASP.NET Web 服務而言，只要實作一個衍生自 IXmlSerializable 的傳回型別，就可以辦到。如果您再回去看一下 BinaryDataMTOM QuickStart 範例裡 BinaryDataMTOMService.cs 檔案中的程式碼，就會發現另一個 Web 服務，它所傳回的是衍生自 IXmlSerializable 的一個叫做 GetFileResponseWrapper 的型別。這個 Web 服務在執行已命名檔案的回傳功能上是一樣的，不過，這次它是在 IXmlSerializable 介面實作 ReadXml 和 WriteXml 方法，檔案是從伺服器以資料流的方式傳送到網路。

改善的工作階段管理

WSE 2.0 支援安全交談 (WS-SecureConversation)，能在用戶端與服務之間建立一個工作階段，進而達到多訊息有效通訊。工作階段和安全交談意義相同。《WS-Security Drilldown in Web Services Enhancements 2.0》一文提供有關安全交談的概觀，它仍適用於 WSE 3.0，只不過，WSE 3.0 現在能透過服務的原則來建立工作階段，如此一來，所有指定的服務也都可以成為安全性內容語彙基元 (Security Context Token，SCT) 發行者，也稱為安全性語彙基元服務 (Security Token Service，STS)。回想一下前面討論過的範例原則檔案，應該會發現，對於所有特定的周全安全性情況，您都可以把 establishSecurityContext 屬性設為 true，以指明服務可以自動發佈 SCT，正如下面一小段原則範例所示。

<usernameOverCertificateSecurity establishSecurityContext="true"
  renewExpiredSecurityContext="true" 
  signatureConfirmation="false" 
  protectionOrder="SignBeforeEncrypting" 
  deriveKeys="true" actor="">

在 WSE 2.0 中，服務的 web.config 檔案會負責所有工作，自動發佈 SCT，而 WSE 3.0 則不同，它會指明在與特定已命名原則關聯後，這只是服務本身的一個屬性。除此，要保護 SCT 發行，要透過已命名的周全安全性情況。在前述的情況中，usernameOverCertificateSecurity 判斷提示會用來保護 RST/RSTR 訊息交換，以將 SCT 發行到用戶端，建立工作階段。

WSE 3.0 已加入許多額外功能，能大幅提昇工作階段管理。首先，如前面所提到的，可以透過 renewExpiredSecurityContext 屬性來更新工作階段。和 WSE 2.0 一樣，如果 SCT 逾時，把這個屬性設為 true，就能自動使用新的 SCT 重新建立一個新的工作階段。更新後原來的 SCT 識別項並不會保留下來，而會產生一個新的 SCT 和一個新的識別項值。我們接下來會詳細討論其他功能，包括工作階段取消以及可設定狀態的工作階段。

工作階段取消

我們除了可以處理 SCT 逾時之外，還可以從用戶端的 Proxy 取得 SCT，呼叫它的 Cancel 方法，來明確取消 SCT。也就是說，現在服務能知道工作階段已經完成，而且可以清除其 SCT 快取。下面的程式碼示範如何從用戶端 Proxy 裡 (儲存在它的 SessionState 物件中)，取得 SCT 執行個體。

String[] symbols = { "FABRIKAM", "CONTOSO" };
StockQuote[] quotes = serviceProxy.StockQuoteRequest(symbols);

// Success!
Console.WriteLine("Web Service called successfully. Simple view:");
foreach (StockQuote quote in quotes)
{
    Console.WriteLine("");
    Console.WriteLine("Symbol: " + quote.Symbol);
    Console.WriteLine("/tName:/t/t/t" + quote.Name);
    Console.WriteLine("/tLast Price:/t/t" + quote.Last);
    Console.WriteLine("/tPrevious Change:/t" + quote.PreviousChange + "%");
}

SecureConversationCorrelationState correlationState =
 serviceProxy.RequestSoapContext.SessionState.
Get<SecureConversationCorrelationState>("");

if (correlationState != null)
{
    // Get the SCT for the current conversation
    SecurityContextToken sct = correlationState.Token as
 SecurityContextToken;

   // Cancel the conversation
if (sct != null)
        sct.Cancel();

}

成功對服務進行呼叫後，就會取消 SCT，此後，用戶端與服務的工作階段就會「瓦解」。

可設定狀態的工作階段

WSE 3.0 已經有能力可以從用戶端的角度建立出可設定狀態的工作階段，這也稱為「有狀態的 SCT」。在 WSE 2.0 中，SCT 在訊息中是由 <SecurityContentToken> 項目來表示，它只含有一個 <Identifier> 項目，以及一個在伺服器與用戶端上皆能快取且指向 SCT 的值。換言之，一個傳遞於用戶端與伺服器之間的數值會用在兩端雜奏表中尋找 SCT。由於兩端都將識別項值對應到快取的 SCT，因此訊息受到 SCT 的安全保護。

然而，下列兩種情況下如果只採用 <SecurityContentToken> 項目裡的識別項值是不夠的：

1. 在服務失敗後重新建立工作階段
2. 在 Web Farm 中使用工作階段 (它們實際上是多台機器的邏輯集合)

我們稍後會一一詳述。

重新建立工作階段

服務不是永遠都穩定且可靠的，它會受到一些因素的影響，像是載入條件和負荷條件，以及由於其他資源限制而導致的應用程式領域重新設定。如果一個服務停用，快取的 (記憶體中) SCT 就會遺失，而工作階段也會遺失。但若在用戶端上保留 SCT 狀態，將它與每個要求一起傳送，如此就能重新與伺服器建立工作階段。在訊息中，除了使用 <Identifier> 項目之外，SCT 狀態也以 <SecurityContentToken> 項目內的一個 <Cookie> 項目來表示。在效能方面，仍舊會在 SCT 快取內先檢查 <Identifier> 項目。<Cookie> 項目永遠會包含工作階段金鑰和用戶端的識別語彙基元 (例如，使用者名稱/密碼語彙基元)。Cookie 是以伺服器語彙基元來加密的，因此唯獨目標服務能夠解密 SCT 內的 Cookie，來擷取此項資訊。下面一小段 XML 訊息示範了，透過應用程式要求從用戶端傳送可設定狀態的 SCT 當時 <SecurityContentToken> 項目裡加密 Cookie 的 <EncodedData> 項目。

<wssc:SecurityContextToken 
  wsu:Id="SecurityToken-5b35b4de-c0a3-4cae-b349-930ffbb237a0" 
  xmlns:wssc="http://schemas.xmlsoap.org/ws/2005/02/sc">
    <wssc:Identifier>uuid:9ee5a3c1-97c0-4f42-8ac1-8d819e80cb27 </wssc:Identifier>
    <p:Cookie xmlns:p="http://schemas.microsoft.com/wse/2005/03/StatefulSCT">
      <p:EncodedData>AQAAANCMnd ...(abbreviated)/p:EncodedData>
    </p:Cookie>
</wssc:SecurityContextToken>

預設的情況下會採用 Windows Data Protection API (DPAPI) 來加密和解密可設定狀態的 SCT 的 Cookie 資料，因為它是個壓縮的二進位格式，對訊息大小的影響微不足道。有關 DPAPI 的相關說明，請參閱《Windows Data Protection》。DPAPI 使用的是與目前登入帳戶執行緒有關的金鑰。因此，如果 SCT 發行者 (STS) 和目標服務是在同個帳戶下執行 (建議採用此方法)，就不需要用到用來加密 SCT 的伺服器語彙基元 (例如，伺服器的 x509 憑證或 Kerberos 語彙基元)，因為執行緒金鑰本來就是用來加密 SCT 的金鑰。雖然這在協力廠商 STS 也很常見，但通常說來，如果服務也可以作為 STS 還是比較好的。

在呼叫的服務也是安全性語彙基元服務 (STS) 時若要使用可設定狀態的 SCT，必須在服務的 web.config 中把 <statefulSecurityContextToken> 項目裡的 enabled 屬性設為 true，如下所示。

    <tokenIssuer>
      <statefulSecurityContextToken enabled="true" />
    </tokenIssuer>

這個值也可透過「WSE Configuration Tool (WSE 設定工具)」來設定，只要選取 [TokenIssuing] 索引標籤，再選 [Enable Stateful Security Context Token (啟用可設定狀態的安全性內容語彙基元)] 即可，如 [圖 8] 所示。

[圖 8] 服務上可設定狀態的 SCT 的設定

要體驗可設定狀態 SCT 的功能有多麼強大實用，能輕鬆地重新建立工作階段，最簡單的方法是修改 SecureConversationPolicy QuickStart 範例，讓用戶端 Proxy 呼叫 Web 服務兩次。先確定服務已經啟用可設定狀態的 SCT，然後在各個傳送到伺服器的要求間隔間，利用命令提示字元執行 iisreset.exe，模擬服務失敗。此時務必等待 IIS 重新啟動。啟用可設定狀態的 SCT，第二次對服務進行的呼叫不會受剛才服務失敗的影響，還是會成功，也就是工作階段又會重新建立。但若停用可設定狀態的 SCT，則第二次呼叫會失敗，因為訊息只傳送了識別項的資訊。

注意   工作階段取消和可設定狀態的 SCT 實際上是不能撰寫的。如果啟用了可設定狀態的 SCT，即使可以取消工作階段，下一個用戶端要求還是會重新建立工作階段，這跟服務失敗然後再啟動後工作階段會重新建立是一樣的。提醒您注意一下您管理工作階段的方式。

Web Farm 裡的工作階段

可設定狀態的 SCT 的第二種情況是在 Web Farm 裡使用工作階段。《Managing Security Context Tokens in a Web Farm》是一篇很相當不錯的文章，對 Web Farm 裡面的狀態管理提出三種解決方案。WSE 3.0 的可設定狀態 SCT 與「把 SCT 的狀態資訊放到 SCT 的擴充領域」這個解決方案很像，而後者可直接用來使用 WSE 3.0 可設定狀態 SCT。我建議您詳讀那篇文章，深入瞭解在面對裝載有某服務的多個執行個體的 Farm 時，應如何管理裡面的安全性內容語彙基元。還有，如前面所述，使用 DPAPI 來保護 SCT 即表示，在 Web Farm 裡無須以伺服器語彙基元來設定目標服務，就能輕鬆地進行管理。

簡化服務導向系統的開發

本節涵蓋一些利用 WSE 3.0 和 Visual Studio 2005 使服務導向系統能夠更輕鬆建立的功能。

在 IIS 之外裝載 ASMX Web 服務

WSE 2.0 引進 SoapClient 和 SoapService 類別，目的是要在 IIS 之外裝載 Web 服務，再利用 SOAP 訊息以傳輸協定而非 HTTP，來呼叫它們。SoapClient、SoapService 以及低層級 SoapSender 和 SoapReceiver 類別使得 WSE 成為替代傳訊平台，當中的基礎是傳輸中立的傳訊與替代主機。。有關 WSE 2.0 訊息傳送的詳細資訊，請閱讀《Web Service Messaging with Web Services Enhancements 2.0》。

為了讓 ASMX Web 服務享有傳訊的好處，WSE 3.0 能在 Runtime 裝載 ASMX Web 服務。採用 .NET Framework 2.0，就能夠整合 WSE 和 ASMX 程式設計模型，進而分開進行傳輸與裝載，繼續利用 Visual Studio 2005 的支援工具。

在 WSE 3.0 版中，ASMX Web 服務能裝載於主控台應用程式、Windows 服務、COM+ 元件或 Windows Form 應用程式，然後透過 TCP 通訊協定來呼叫。另外還有其他一些針對 WSE 發佈的自訂傳輸，包括 UDP 和 MSMQ，它們也能使用這些 ASMX Web 服務的替代主機，而不侷限於只能使用 TCP 通訊協定。

下面的程式碼範例說明在主控台應用程式裡應該如何進行實作。要取得衍生自 System.Web.Services.WebService 型別的 StockService 類別，只要替透過 EndpointReference 類別指定之特定 TCP 接聽埠，把該型別提供給 SoapReceivers 集合即可。

class ServiceHost
{
    static void Main(string[] args)
    {
       // This Web Service is hosted in a console application
        ServiceHost host = null;

        try
        {
            host = new ServiceHost();
            host.Run();
            Console.WriteLine("");
            Console.WriteLine("Press any key to exit when done...");
            Console.WriteLine("");
            Console.ReadLine();
        }
        catch (Exception ex)
        {
            Console.WriteLine(ex.Message);
        }
    }

    public void Run()
    {
        // The address to start listening for requests
        Uri address = new Uri("soap.tcp://localhost/tcpstockservice");
  // Add the System.Type of the service (StockService) to the
        // SoapReceivers collection.
        SoapReceivers.Add(new EndpointReference(address),
 typeof(StockService));
        Console.WriteLine("Listening for messages at address " + address);
    }
}

而用戶端部分，可使用以 Visual Studio 「Add Web Reference (加入 Web 參考)」產生的 Proxy 類型 (若此 Web 服務也是由 IIS 裝載)，來與裝載於主控台上的 ASMX Web 服務進行通訊，只要更新 Proxy 的 Url 屬性就行了。

注意
未來發行的 WSE 3.0 版內，您可以使用 wsewsdl.exe 工具，透過 TCP 來產生衍生自 Microsoft.Web.Services3.WebServicesClientProtocol 的用戶端 Proxy，而 TCP 可用來與 ASMX Web 服務進行通訊。

而 Wsewsdl.exe 還是能夠產生衍生自 SoapClient 的用戶端 Proxy，就和現在的 WSE 2.0 版一樣。

下面一小段程式碼說明如何使用用戶端 Proxy，透過 TCP 來呼叫裝載於主控台上的 ASMX Web 服務。

public void RunTcpClient(StockServiceWse serviceProxy)
{
    Console.WriteLine();
    Console.WriteLine("Call ASP.NET Web Service via TCP");
    Console.WriteLine();
    serviceProxy.Url = "soap.tcp://localhost/tcpstockservice";
    // set the action in the message to indicate which WebMethod to call
    serviceProxy.RequestSoapContext.Addressing.Action = 
new Action("StockQuoteRequest");

    // Call the service
    Console.WriteLine("Calling {0}", serviceProxy.Url);
    String[] symbols = { "FABRIKAM", "CONTOSO" };
    StockQuote[] quotes = serviceProxy.StockQuoteRequest(symbols);

    // Success!
    Console.WriteLine("Web Service called successfully. Simple view:");
    foreach (StockQuote quote in quotes)
    {
        Console.WriteLine("");
        Console.WriteLine("Symbol: " + quote.Symbol);
        Console.WriteLine("/tName:/t/t/t" + quote.Name);
        Console.WriteLine("/tLast Price:/t/t" + quote.Last);
        Console.WriteLine("/tPrevious Change:/t" +quote.PreviousChange + "%");
    }
}

與 Visual Studio 2005 整合

WSE 3.0 與 Visual Studio 2005 和 .NET Framework 2.0 的發行相配合，也因此，能善用基本平台的變更之處。WSE 3.0 無法在 .NET Framework 1.1 和 Visual Studio 2003 上執行，所以，WSE 3.0 文件說明了從 WSE 2.0 專案移轉到 WSE 3.0 的所需步驟，其中包括能支援自動將 WSE 設定檔案升級到更高版本的設定工具。整體來說，從 WSE 2.0 升級到 WSE 3.0 是一個機械性的流程，沒有什麼重大的變更。

為了因應 .NET Framework 2.0 的需求，WSE 3.0 支援 64 位元。

互通性和與未來技術的兼容性

WSE 3.0 版本的主要目的之一是在為 Indigo 鋪路，進而建置出以 Web 服務通訊協定為基礎的服務導向應用程式。WSE 3.0 與 Visual Studio 2005 和 .NET Framework 2.0 能相互搭用，且支援 ASMX Web 服務的安全性。Indigo 是未來建置分散式服務導向應用程式的平台，將於 Windows Longhorn 的期間內發行。

WSE 3.0 會於今年稍晚發行上市，它是個全面受支援的產品。支援部分相當重要，以前 WSE 1.0 發行時，它的支援服務週期有限，但從 WSE 2.0 開始，WSE 已經延長客戶支援服務，使之與 .NET Framework 一致。有關 WSE 產品週期的詳細資訊，請參閱 Product Lifecycle Dates - Developer Tools Family。

使用周全安全性情況時，WSE 3.0 保證與 Indigo 在底層協定上能相容，也就是說，您能部署 WSE 3.0 服務，並且透過 Indigo 用戶端與之通訊，反之亦然。WSE 3.0 也可與 Indigo 並存執行，換言之，您可以部署服務，等到有了 Indigo，再依需求加入其他服務，並端視可靠性或改善效能等其他功能之需求，來決定何時進行部分或全部的移轉。

注意   使用 HTTP 通訊協定和對應的周全安全性情況的話，WSE 3.0 與 Indigo 在底層協定方面相容。若採用其他通訊協定，像是 TCP，則無法保證互通性。

WSE 3.0 是用來建立安全性 Web 服務的程式設計 API，因此，從那個角度來看，所有您藉由它來建立應用程式時所學習到和累積的概念與經驗，都適用於 Indigo 和其他互通的 WS-* 工具套件。用來定義服務、傳訊模式和與其他產品整合等合約的概念，像是用於訊息轉換與商務協調 (Orchestration) 的 BizTalk Server，還有儲存用的 SQL Server 2005，都可套用到 Indigo。也就是說，要想在分散式應用程式開發領域上累積經驗，從今天起，就採用 WSE 建置解決方案。

WSE 3.0 版與 Indigo 在程式設計模型上有些雷同之處，尤其是在周全安全性情況方面，WSE 的周全安全性判斷提示與 Indigo 的安全性項目繫結驗證模式是一貫的。就在我撰寫本文之際，有關 WSE 的設定和原則設定與 Indigo 的標準繫結兩者的一慣性以及指引也正在開發之中，未來會有專文探討 WSE 3.0 與 Indigo 之間的互通性。

雖然 WSE 3.0 和 Indigo 能並存執行，但在程式碼移轉上還不盡完美。計劃 WSE 3.0 移轉到 Indigo 的作業會是簡單而且機械性的，可能利用記載的指導、指令碼以及工具來協助進行。而採用周全情況的部分，在移轉工作上會受到簡化，因為屆時有關現有基礎結構的架構方面的決定都已完成。

WSE 2.0/3.0/Indigo 常見問題集

本文探討了 WSE 3.0 功能上的議題，但在支援以及技術選擇方面的問題，還是以簡短的常見問題集來解說比較完善。

WSE 3.0 的發行時間表為何？

WSE 3.0 會在 Visual Studio 2005 發行 (暫定 11 月 7 日) 的四個星期內發行，在那之前，每個月會有的 Community Technology Previews (CTP)，而相關的反應與議題可以向 Product Feedback Center (網址：http://lab.msdn.microsoft.com/productfeedback/) 報告。

我應該使用 WSE 2.0、WSE 3.0 還是 Indigo？

WSE 3.0 是一項為 .NET Framework 2.0 擴展 ASP.NET 2.0 Web 服務的產品。它是以 Visual Studio 2005 時期為目標，一旦發行後，即能支援且實作最新 Web 服務規格與標準。在周全安全性情況方面，WSE 3.0 保證能與 Indigo 服務互通使用。Indigo 則是以 Windows Longhorn 時期為目標。

以 .NET Framework 1.1 為目標的應用程式應採用 WSE 2.0，不過基於規格上的一些異動，例如，WS-Addressing，WSE 2.0 在底層協定方面並不與 WSE 3.0 和 Indigo 相容。

WSE 2.0、WSE 3.0 和 Indigo 之間的關係為何？

WSE 能解決當今開發人員最迫切的需求，讓他們輕鬆在 .NET Framework 2.0 建置安全性 Web 服務。在 Longhorn 時期，Indigo 會推出統一的程式設計模型與 Runtime，來建置分散式系統。Indigo 提供一組當今的 Microsoft 分散式系統建置技術，包括 COM+、Enterprise Services、MSMQ 和 WSE 等等。WSE 3.0 保證與 Indigo 具有連線相容性，而且兩者能並存執行。WSE 就好比當今的 API 集，能支援進階的 Web 服務，將服務導向功能帶入您現有的應用程式設計。而 Indigo 則是一組能建置分散式系統的 API，支援 Longhorn 一波的 Web 服務通訊協定。

WSE 3.0 的物件模型與 Indigo 的相同嗎？WSE 的原始程式碼與 Indigo 相容嗎？

不，它們不相容。WSE 提供一個遵循 Web 服務規則的程式設計模型，因此每個版本會有所差異。Indigo 程式設計模型統一了 Microsoft 建置分散式系統的技術，整合的技術與功能範圍比較廣。

.NET Framework 2.0 支援 WSE 2.0 嗎？

WSE 2.0 發行後，會推出一個受到 .NET Framework 2.0 支援的版本。以 WSE 2.0 SP2 和 SP3 建置的應用程式將受到 .NET Framework 2.0 的支援，不過在 .NET Framework 2.0 上還是使用 WSE 3.0 比較好。WSE 2.0 與 Visual Studio 2005 搭用時，並沒有設計階段支援 ，WSE 2.0 僅在 32 位元而非 64 位元方面受到支援。WSE 2.0 SP3 可與 Visual Studio 2005 Beta 2 和 .NET Framework 2.0 一起安裝，但不受到它們的支援。

WSE 2.0 應用程式可以與 WSE 3.0 應用程式並存執行嗎？

可以，您可以將 WSE 2.0 和 WSE 3.0 安裝在同一部機器上。

WSE 3.0 能與 .NET Framework 1.1 或 Visual Studio 2003 舊版相容嗎？

不能，WSE 3.0 只能在 .NET Framework 2.0 上執行。

WSE 2.0 和 3.0 版的支援服務政策為何？

WSE 2.0 與 .NET Framework 1.1 一致，因此都有 5 年的主要支援服務 (Mainstream Support) 和 5 年的延伸支援服務 (Extended Support) (5+5)。有關 WSE 2.0 的支援服務，請參閱 Product Lifecycle Dates - Developer Tools Family 和 Microsoft Support Lifecycle。

WSE 3.0 的支援服務與 .NET Framework 2.0 一致。

結論

WSE 2.0 大幅簡化安全性 Web 服務的開發與部署過程，讓開發人員能將訊息層級的安全性，加入到以服務導向原則及新興 Web 服務 (WS-*) 規格為準則的應用程式。

本文深入探討 WSE 3.0，解說它的嶄新功能，其中包括能在多項傳輸時啟用 ASMX 程式設計模型，有能提供周全安全性傳訊情況的簡化安全性原則，以 MTOM 傳送大量的二進位資料，具有與 Indigo 的互通性，以及符合最新 Web 服務規格。為了達成輕鬆建置安全性 Web 服務、透過 Visual Studio 來簡化伺服器導向系統的開發工作，以及為 Indigo 鋪路這三個宗旨，WSE 3.0 不斷地提供高生產力、高延伸性以及易於使用的平台，以協助開發安全的 Web 服務。