• 發行項

本文章是由機器翻譯。

工作流程優先 Web 服務

使用 Windows Communication Foundation 進行結構描述式的開發作業

Christian Weyer (& ) Buddhike de Silva

「 如果我具有 [來截斷向樹狀目錄下的八小時我想花六個銳利化之斧" 說 Abraham Lincoln。 這是，則為 True 軟體工程以及在不同的階段。 well-擬出設計是大部分的軟體成功故事背後密碼。 設計通訊系統如 [Web 服務] (WS) 時，這是如此。 注意應支付向型式的介面，用來通訊。 這個介面會要求您系統的互通性與可用性。 因此，在生命週期的早期階段設計--也就是也稱為合約--這個介面是重要的。 此的文件中我們將告訴您如何設計和開發第一次 Windows Communication Foundation (WCF) 架構服務合約著重在 Web 服務的區域。 WS 的合約與兩個主要方法存在--程式碼的第一個合約的第一個開發 和 結構描述的第一個合約的第一個開發。 在後者會主要到我們的焦點。

合約的第一個開發是什麼？

合約的第一個設計和開發不是新的項目。 它已正式由引入小姐君他艾菲爾程式語言設計的一部份，並已自 1986年 1，2 各種技術的出版物中出現。 因此，瞭解合約從舊學校工具/技術觀點來看，可能有幫助瞭解它很有用的原因。

雖然電腦現在可以進行大量的項目從簡單的算術控制 orbiting 我們的地球，附屬後新增是 19 世紀的機器,，尚未變更的輸出為電腦的基本概念。 因此，軟體工程師仍然撰寫函式取得某些輸入並執行某些工作，和輸出的項目。 然後，這些函式用從其他位置。 函式的合約定義期望和該函式的承諾。 亦即函式的輸入的參數可以想像為其期望，且傳回的值可以被視為為它的承諾。 函式的使用者只需要知道使用合約。 這是典型的範例是 C + + 標頭檔。 當您要叫用在另一個 C + + 程式庫中的函式時，您不感興趣大部分的情況下，查看實作--在就其實，您會沒有實作的存取。 純文字標頭檔會告訴您和您的編譯器，足夠有關所需叫用該函式和就會出現在它完成。

在 COM 中的型別程式庫檔案，並 ActiveX 和 C# 中的介面通常會被視為其他形式的合約。 因為合約的軟體元件的抽象資料型別為基礎的型式、 正確、 可驗證的介面規格的定義方式，還有一個自然的傾向，要先建立合約。 這就是為什麼幾乎所有 C/C + + 程式設計人員藉由第一個寫入標頭檔都啟動程式。

在 WS 合約是沒有例外狀況。 WS 程式開發人員為您的目的是要共用您的輸入/輸出系統為 Web 服務--可能跨平台的界限。 我們會確定您已經聽過幾次之前，您的 Web 服務的使用者不應該 worrying 關於您的實作詳細資料。 可以存取您的合約應該足夠供他人使用它。 因為 Web 服務獨立於平台的所以我們會使用 Web 服務定義語言 (WSDL) 和 XML 結構描述 (XSD) 的互通性、 以標準為主建構，來定義合約。 模型的合約，牽涉到模型資料、 訊息和您的 Web 服務的介面。

第一次，您的模型您用來在用戶端與服務之間傳送資料的資料合約 (也就是資料結構)。 資料合約可以是簡單或原始型別，例如 字串、 整數、 雙精度浮點 或複雜，或特定網域的類型，例如 產品]、 員工 ] 或 路線。

RPC/編碼樣式會使用結構描述中定義型別來定義的 WSDL 訊息部分。 這樣就難以驗證整個 SOAP 主體對的結構描述，其中只有部分代表什麼 ’s 結構描述中定義。 其餘部分是來自於 WSDL。 它也會編碼 SOAP 主體內容為每個區段 5 編碼 SOAP 1.1 規格所定義的規則。 雖然此樣式合法但這不是 WS-我-相容。

RPC/常值 樣式很 RPC/編碼樣式很類似。 但是，與 RPC/編碼樣式，不同的是它不會編碼 SOAP 主體。 雖然此樣式 WS 我-相容但是很仍然很難驗證。

文件/常值使用項目定義的 WSDL 訊息部分，並不會編碼主體內容。 這可消除這兩個先前討論過的樣式中主要的問題。 因此，這已經成為廣為接受的 WS 我-相容樣式。

Microsoft 引進文件/常值/Wrapped 樣式。 它 ’s 文件/常值樣式，相同，但也換行的項目內的作業名稱所建立的項目內容]。 在本文中具有的作業名稱，比較容易分派，非 HTTP 端點的郵件。 但更重要的是一定要符合 [WS 有幫助-我標準要求項目內只能有一個子項目。

通常，Web 服務與他們的用戶端互動，藉由交換 SOAP 訊息 3。 模型這些訊息合約是合約的第一個開發的第二個步驟。 您該怎麼的 SOAP 訊息您想要使用的格式而定：

  • RPC/編碼
  • RPC/常值
  • 文件/常值
  • 文件/常值/包裝

還有另一種稱為文件/編碼的格式，但其實非常難發現使用它的實作。 這個的文件我們將焦點只在文件/常值/Wrapped 因為最常使用它，而且它也是 Web 服務互通性的組織 (WS-我)-相容。

定義訊息合約有兩個層面。 第一次，它應該定義 SOAP 主體的結構。 可以使用 XSD 要執行這項操作，而且您也可以使用您在前一個步驟中所定義的資料合約。 訊息合約的其他外觀定義 SOAP 標頭的結構。 您的郵件的標頭被定義在 WSDL 中。 這是使用在步驟 1，模型的資料合約定義哪個這些標頭中是常見的做法。

一旦您的資料和訊息合約，您可以建立您的介面模型的定義服務中可用的一或多個作業。 作業的合約可能會使用第二個步驟中建立模型的訊息合約來定義哪些訊息交換的作業期間。

除了三個主要的合約類型--資料、 訊息和介面合約--Web 服務合約也會有一個原則、 繫結和端點。 圖 1 彙總的 WSDL/結構描述建構用來表示在 Web 服務合約中的不同成品。


圖 1 WSDL 和 XSD 建構使用

程式碼-第一對。 結構描述名字

如簡介所提到有兩種模型合約-程式碼的第一個 與 結構描述的第一個 的方法。 為了要選擇符合您需求的瞭解兩者重要的。

在程式碼的第一個方法中，您可以使用功能強大的宣告式合約提供不同的 Web 服務堆疊 (WCF、 ASMX、 JAX-WS，等等) 的程式設計建構。 如此，您可以在您最愛的編輯器中使用您最愛的程式語言模型。 因此代替學習 WSDL 和 XML 結構描述建構，您可以使用您已熟悉的程式設計建構和資料類型。 產生原生形式 (WSDL 和 XSD) 的 WS 合約大量 lifting 負責基礎 WS 堆疊。 這些宣告式程式設計建構也容易許多從頭整合新的 Web 服務或公開為服務的現有實作。

但是，此簡化及方便可能會導致微妙的問題如果採用沒有感知的基礎 WSDL/XSD 建構用來代表您建立模型的成品。 是，這 contradicts 有關能夠開發不知情 WSDL 和 XSD 的情況下您合約上述的陳述式。 但是，不幸的是，事實上，程式碼的第一個抽象遺漏。 讓我們試著了解從.NET 開發人員的觀點的原因。

當您使用程式碼時，您仍然必須在思維模式的模型使用.NET 型別系統的物件圖形。 就例如程式碼-第一種方法並不妨礙您使用.NET 特性，例如 System.Data.DataSet 或 System.DateTimeOffset。 這些型別明確地以 XML 表示 (而且也有 XML 序列化)。 但是，非.NET 用戶端並沒有相同的型別存取。

另一個很好的範例是循環的圖形。 如同先前所述與程式碼的第一個您仍然必須是物件導向的思維模式。 因此，您傾向於模型的物件圖形，而且這些圖形也可能有循環參考。 請考慮下列資料結構的循環參考：

public class OrderItem
    {
        public Order Order { get; set; }
    }

    public class Order
    {
        public List<OrderItem> Items { get; set; }
    }

Order 的訂的 OrderItems 清單，每個的 OrderItem 參照回父順序。 如果想這表示在 XML 中您叫用問題的 XML 沒有物件識別的一個概念，因此您可能會得到類似圖 2，永遠會到上的 XML。

圖 2 代表與 XML 循環參考的物件圖形

<Order>
  <Items>
    <OrderItem>
      <Order>
        <Items>
          <OrderItem>
            ...
          </OrderItem>
        </Items>
      </Order>
    </OrderItem>
  </Items>
</Order>

這種行為是因為階層式 XML 文件的性質與差異圖形模型中的物件圖形。 不幸的是，這是當您採用程式碼的第一個方法是不容易偵測的項目。 若要修正這個問題您必須啟用追蹤 DataContractSerializer 的 DataContractAttributeIsReference 屬性透過參考。 但是，然後您將面對一組不同的問題：第一次，您不能夠驗證 XML 文件避免使用標準的結構描述驗證 API，結構描述第二個，追蹤機制的序列化程式所使用的標準參考根據 5 節編碼 SOAP 1.1 規格中定義的規則。 這些規則會取代文件/常值的樣式郵件也就是標準的 WS 中指定-我規格。

儘管這些問題的程式碼-第一種方法中，您仍可能會發現它更容易使用 WCF 程式設計建構的 WSDL/XSD 而不是建構，只要在有點知道這些兩個世界會對應到彼此的方式，以及 WCF 序列化的運作方式。 雖然討論程式碼的第一個合約-第一種方法的詳細資料，超出本文章下列的範圍圖表應該提供您最常使用的 WCF 合約程式設計建構之間關係的 20，000 英呎檢視和 WSDL/XSD 建構。

圖 3 對應期間常用的 WCF 中的宣告式程式設計建構和 WSDL/結構描述建構

直接為您的模型使用 WSDL 和 XSD 架構的第一次 設計代碼的第一次設計的主要替代。 這是的您現在正在處理原生建構模型化 WS 合約一個更為自然的方式。 使用 WSDL 和 XSD 可讓您建立模型與多個以 XML 為中心思維模式，消除許多程式碼-第一種方法缺點您合約。

不過，如果想向這個曲目您需要知道 WSDL 和 XSD 很好。 而且，因為連線這些兩個世界，是，所以您不能著重完全 WSDL 和 XSD 是。 就例如在結構描述的第一個的方式有些時候您必須從您的結構描述產生的程式碼，以程式設計方式操作資料結構。 可用的不同 WS 堆疊今天提供的 (我們會討論有關可用工具的 WCF 在本文稍後) 的工具。 但是，因為 XML 結構描述規格的 enormity，這些工具通常只支援結構描述建構函式的子集。 因此，如果您在您的結構描述中使用這些不受支援的建構，您仍然可以執行到在交互操作性方面的問題。 而且，您模型像 XSD 限制有許多工具套件沒有宣告式對等用法，因此可能會消失在程式碼產生期間特定事件。

在最的程式碼的第一個方法您可以撰寫程式碼，並讓您為您產生 WSDL/XSD 的工具組。 因此，如果您變更在您的程式碼中的項目，它將自動反映在產生結構描述中。 結構描述的第一種方法中，WSDL 和 XSD 可能會變得過時沒有適當的變更程序，而 disciplined 在小組中的開發人員。 在就另外您也可能需要模型您 WSDLs，因為您的 IDE 不能有這些功能現成的工具。

通常，同時程式碼的第一個] 和 [結構描述的第一個有優缺點。 結構描述的第一個方法可讓您好處特別在案例中，您需要使用現有的結構描述，它們可能已被模型您開發生命週期的初期階段為了達成共識與利害關係者。 這是常見的情況政府和銀行環境中。 您也可能需要使用現有的結構描述，如果您正在建置遵守現有的業界標準如開啟旅遊聯盟 (OTA) 的應用程式。 選擇這兩個合約定義的方法也應該根據您案例資源和適用於您的小組的技術。 對於執行個體如果要建置 WCF 服務並不需要支援其他平台上執行的用戶端，可能不想考慮以結構描述的第一個方法。 而且，如果您很熟悉與合約程式設計建構 WCF 中、 序列化處理程序的清楚瞭解和能夠專注於階層式結構，而不是物件圖形，您可以請依照下列程式碼第一種方法，並達到相同的結果。

因此如果您決定現在使用結構描述的第一個方法，這份文件的其餘部分顯示您如何為 WCF 服務。

說明結構描述的第一個方法

結構描述的第一種方法有五個不連續的步驟，如 圖 4 中所示。


圖 4 結構描述的第一個合約名字開發程序

我們已經所討論這份文件的開頭前三個步驟。 因此，讓我們只是彙總這些並移動上到下一個的幾個關鍵點。

步驟 1 的模型資料： 您的模型用於您的服務和使用 XML 結構描述的用戶端之間傳輸資料的資料結構。 您可以使用 Visual Studio XSD 編輯器] 或 [類似 Altova XmlSpy 或液體的 XML Studio 等工具。

步驟 2 的模型訊息： 如我們在稍早所述，在這個步驟中您模型使用 XML 結構描述您郵件內文的結構。 您可能會使用您在此模型在步驟 1 中的資料結構。

步驟 3 模型介面: 在這個步驟中，您可以藉由定義其作業模型您介面的合約。 但是，不像在先前的步驟此處您必須使用 WSDL，而不是 XML 結構描述。 編輯 WSDL 不是在 Visual Studio 中使用，但在 Altova XmlSpy 像某些產品中可用。

步驟 4 的產生程式碼： 一旦您具有模型化您的資料、 訊息和作業的時候產生程式碼來表示這些成品，您最愛的程式語言。 接下來的兩個章節將詳細說明如何使用目前的工具為 WCF 開發人員。

步驟 5 Iterate 合約設計和程式碼產生： 很極難達到完美的一個嘗試。 一旦您設計您的合約時，您可能要重整它數次直到您找到您需要最佳化結構。

使用結構描述的第一個合約的第一個開發全新的 WCF 工具

若要示範這種情況下，讓我們建立簡單的 Web 服務有擷取的主機電腦中的使用中處理序清單的作業。 我們開始資料合約，模型兩個複雜型別。

  1. 複雜型別 process 代表主機機器中的處理程序。
  2. 複雜型別 processList 代表 process 型別所定義的程序的清單。

我們建立模型的兩個項目，然後瀏覽並以抽象的主體的 exploreResponse 輸入/輸出訊息。 如前所述之前, 要符合的 WS-我要確認您的郵件內文 soap:body 項目內只能有一個子項目。 ASMX 和 WCF 處理透過與作業名稱建立包裝函式項目。 如果用模型的訊息來命名慣例是不同的標準 WCF，程式碼產生工具將會產生的要求和回應MessageContract 類別。 我們可以使用 WCF 命名慣例來命名訊息項目及時我們在此程序在稍後產生程式碼，因而有更簡單的物件模型。

最後，我們模型 WSDL 使用外部工具。 在這種情況下我們會使用 Altova XML 間諜來幫助我們的。

找 4、 5 和 6 包含上述資料、 訊息和介面合約定義分別。

圖 4 Data.xsd

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
           xmlns:ns1="http://schemas.thinktecture.com/contractfirst/2009/07/data" 
           targetNamespace="http://schemas.thinktecture.com/contractfirst/2009/07/data" 
           elementFormDefault="qualified" 
           attributeFormDefault="unqualified"
           >
    <xs:complexType name="process">
        <xs:sequence>
            <xs:element name="pid" type="xs:int"/>
            <xs:element name="name" type="xs:string"/>
        </xs:sequence>
    </xs:complexType>
    <xs:complexType name="processList">
        <xs:sequence>
            <xs:element name="process" type="ns1:process" maxOccurs="unbounded"/>
        </xs:sequence>
    </xs:complexType>
</xs:schema>

圖 5 Messages.xsd

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns:data="http://schemas.thinktecture.com/contractfirst/2009/07/data"
           xmlns:ns1="http://schemas.thinktecture.com/contractfirst/2009/07/"
           targetNamespace="http://schemas.thinktecture.com/contractfirst/2009/07/"
           elementFormDefault="qualified">
  <xs:import namespace="http://schemas.thinktecture.com/contractfirst/2009/07/data"
             schemaLocation="data.xsd"/>
  <xs:element name="explore">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="hostname" type="xs:string" nillable="true"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:element name="exploreResponse">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="processes" type="data:processList" nillable="true"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>  
</xs:schema>

圖 6 ProcessExplorerService.wsdl

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions xmlns:wsdl="https://schemas.xmlsoap.org/wsdl/" 
                  xmlns:soap="https://schemas.xmlsoap.org/wsdl/soap/" 
                  xmlns:http="https://schemas.xmlsoap.org/wsdl/http/" 
                  xmlns:xs="http://www.w3.org/2001/XMLSchema" 
                  xmlns:soapenc="https://schemas.xmlsoap.org/soap/encoding/" 
                  xmlns:mime="https://schemas.xmlsoap.org/wsdl/mime/" 
                  xmlns:tns="http://schemas.thinktecture.com/contractfirst/2009/07/" 
                  xmlns:soap12="https://schemas.xmlsoap.org/wsdl/soap12/" 
                  xmlns:msg="http://schemas.thinktecture.com/contractfirst/2009/07/" 
                  xmlns:ns="http://schemas.thinktecture.com/contractfirst/2009/07/data"
                  xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl"
                  targetNamespace="http://schemas.thinktecture.com/contractfirst/2009/07/">
    <wsdl:types>
        <xs:schema targetNamespace="http://schemas.thinktecture.com/contractfirst/2009/07/" 
               elementFormDefault="qualified">
            <xs:import schemaLocation="messages.xsd"/>
        </xs:schema>
    </wsdl:types>
    <wsdl:message name="exploreRequestMessage">
        <wsdl:part name="parameters" element="msg:explore"/>    
    </wsdl:message>
    <wsdl:message name="exploreResponseMessage">
        <wsdl:part name="parameters" element="msg:exploreResponse"/>
    </wsdl:message>
    <wsdl:portType name="processExplorer">
        <wsdl:operation name="explore">      
            <wsdl:input wsaw:Action="http://schemas.thinktecture.com/contractfirst/2009/07/explore" 
                  message="tns:exploreRequestMessage"/>
            <wsdl:output wsaw:Action="http://schemas.thinktecture.com/contractfirst/2009/07/exploreResponse" 
                   message="tns:exploreResponseMessage"/>
        </wsdl:operation>
    </wsdl:portType>
    <wsdl:binding name="processExplorerHttpBinding" type="tns:processExplorer">
        <soap12:binding style="document" transport="https://schemas.xmlsoap.org/soap/http"/>
        <wsdl:operation name="explore">
            <soap12:operation 
        soapAction="http://schemas.thinktecture.com/contractfirst/2009/07/explore" 
        soapActionRequired="true"/>
            <wsdl:input>        
        <soap12:body use="literal"/>
            </wsdl:input>
            <wsdl:output>
                <soap12:body use="literal"/>
            </wsdl:output>
        </wsdl:operation>
    </wsdl:binding>
    <wsdl:service name="ProcessExplorerService">
        <wsdl:port name="processExplorerPort" binding="tns:processExplorerHttpBinding">
            <soap12:address location="http://localhost/processexplorer"/>
        </wsdl:port>
    </wsdl:service>
</wsdl:definitions>

一旦合約就，我們可以啟動 Visual Studio 2008 命令提示字元，並為 WCF 使用 svcutil.exe，產生 C# 程式碼，如下列程式碼所示：

svcutil -noconfig -serializer:datacontractserializer -d:../ -
namespace:*,Thinktecture.Samples.ProcessExplorerService
ProcessExplorerService.wsdl Messages.xsd Data.xsd

Svcutil.exe 主要用來產生用戶端程式碼。 不同於其前置任務，wsdl.exe 它並沒有產生服務端基本架構的選項。 因此，您將注意到所產生的程式碼包含用戶端 Proxy 程式碼不是必要的服務端實作。 的服務實作的您必須從產生的程式碼中移除這些不相關的型別。 在我們的範例案例中我們執行，從產生的程式碼移除 processExplorerClient 及 processExplorerChannel 的類別。 完成有，您只可以實作產生的介面型別 processExplorerProcessExplorerService1 專案中隨附的範例方案中所示。

最後，您裝載服務之前先您必須調整的 ServiceMetadataBehavior 若要關閉自動 WSDL 的產生和點 WCF 的中繼資料產生至靜態 WSDL 檔案的執行階段。 下列 WCF 組態中指定的外部中繼資料的位置：

<serviceMetadata httpGetEnabled="true"                            
externalMetadataLocation="..\contracts\processexplorerservice.wsdl"/>

您可能已經注意到，使用這種方法的結構描述的第一個開發可能有點可觀，在實際應用程式中。 若要關閉補充不足之處，建立 WSCF.blue，可用 Web 服務合約第一個 (WSCF) 工具的後續任務。

看一下 WSCF.blue

WSCF.blue 是一個可用 Visual Studio 2008 新增的。 其主要功能啟用您最愛的 IDE 內部的結構描述的第一個合約的第一個開發。 您的模型在 Visual Studio 的 XML 結構描述編輯器或免費工具像液體 XML 編輯器中您的資料和訊息合約。 您可能想後者因為結構描述編輯器中可用 Visual Studio 2008 提供較少的模型支援比 Visual Studio 2005 中可用的。 結構描述已準備好之後您可以使用 WSCF.blue 的 WSDL 產生精靈來建立您的服務介面的模型。 它提供易記能夠模型介面的作業，並隱藏實際的 WSDL 建構的詳細資料。 可以啟動這個精靈，以滑鼠右鍵按一下 XSD 檔案包含您的訊息合約，並選取 建立 WSDL 介面描述 功能表項目從 [內容] 功能表，的圖 7] 所示。


圖 7 開始 WSDL 產生精靈

此精靈包含幾個步驟來收集您想要在服務介面中有作業合約的相關資訊。 大部分的步驟都是相當直接了當的。 但是，有幾件事可能需要您在步驟 2 及 3，4 的注意。

結構描述中定義的類型檔案中選取您的 WSDL 模型將可使用方案總管] 來啟動精靈。 不過，如果您有其他類型在其他 XSD 檔案時，您可以匯入步驟 2 中它們，就也為 圖 8 顯示。


圖 8 匯入其他結構描述文件到精靈

在步驟 3 中您建立模型的作業。 精靈也有一個功能，可以周遊您訊息合約項目，並推斷作業。 這的項功能但是，只適用於使用命名慣例用在精靈的 inferring 的規則中所示的圖 9 的郵件。


圖 9 新增或移除介面作業

在步驟 4 中，您可以將您模型化成要求和回應您作業的訊息對應。 如果使用步驟 3 中的 inferring 功能此對應將會由精靈自動完成。 您也可以定義在您的要求和回應訊息中的郵件標題在此步驟 (的圖 10)。


圖 10 定義中作業的輸入/輸出訊息。

最後，當您完成 [精靈時所產生的 WSDL 檔案會新增至您的專案。
現在，合約模式化，您可以使用 WSCF.blue 程式碼產生工具在您的專案語言中產生 WCF 的程式碼。 WSDL 檔案，在 [方案總管] 中以滑鼠右鍵按一下，然後選取 [內容功能表來啟動程式碼產生工具 (的圖 11] 所示) 中的 [產生 Web 服務程式碼功能表項目。


圖 11 啟動程式碼產生工具

[程式碼產生] 對話方塊可讓您不同的程式碼產生選項。 它包含大部分的可用選項中 svcutil.exe，以及一些額外的這類：伺服器端虛設常式，以產生伺服器端程式碼 ；調整將用於結構描述來 Pascal 大小寫的名稱，而不會影響序列化 ； Camel 命名法的大小寫名稱的大小寫然後，個別檔案，以產生程式碼檔案的每個 CLR 型別產生用來表示相對應的結構描述成品 (的圖 12)。 圖 13 包含完整的程式碼產生工具中可用的選項清單。


圖 12 的程式碼產生選項

圖 13 的 WSCF.blue 程式碼產生選項

工具 描述

用戶端 Proxy 產生用戶端 Proxy 的服務的消費者。

服務端虛設常式 產生服務實作器服務端程式碼。

公用屬性 公開為公用屬性，產生類別成員。

可序列化類別 產生的類別會以 SerializableAttribute 裝飾。

集合 使用集合 < T >型別來代表集合型別的型別。

清單 < T > 使用清單 < T >型別來代表集合型別的型別。

資料繫結 產生程式碼，才能將產生的類別繫結至資料繫結的元件。

順序識別項 使用每個 DataMemberAttribute 產生 Order 屬性。

非同步方法 產生非同步作業的版本，並將 OperationContextAttribute.AsyncPattern] 屬性設定為 true，告訴他們存在的 WCF]。

不同的檔案 每個產生的類別會放在自己的檔案。

調整大小寫 當命名產生的類別和其屬性，而不會影響序列化處理序會使用 Pascal 大小寫。

並行處理模式 指定產生 ServiceBehaviorAttribute.ConcurrencyMode] 屬性的值。

執行個體內容模式 指定產生 ServiceBehaviorAttribute.InstanceContextMode] 屬性的值。

使用同步處理內容 指定產生 ServiceBehaviorAttribute.UseSyncrhronizationContext] 屬性的值。

啟用 WSDL 端點 將端點加入至服務，以公開 (Expose) 靜態的中繼資料檔案。 您想要公開 (Expose) 自我裝載的服務中的靜態的中繼資料文件) 時，這非常重要的。

目的檔案名稱 輸出檔的名稱。 如果已開啟個別的檔案選項，便會捨棄這個參數，並類別名稱作為檔名。

目標命名空間 要用來產生型別進行 CLR 命名空間。

請記住設定 會記住最近使用的程式碼產生選項。

覆寫現有檔案 指定您允許 WSCF.blue 覆寫現有的檔案，而非建立唯一的檔名，若要解決衝突。 ’s 一定要記住 ’ve 為了產生的程式碼的任何自訂將會覆寫。 因此我們建議您執行這類修改透過部分類別。

發行的本文 (Beta 1，7 月 25 2009年的) 中所討論的 WSCF.blue 還不支援合併的組態檔。 因此，必要的組態來裝載您的服務發出到 output.config 檔案。 手動步驟，才能移動到您的 web.config 檔案或適當的 app.config 檔案的內容。

當組態檔準備好之後您可以繼續將加入至產生的服務類別中所需的實作。

最後，您可以修改您在 Visual Studio 中的結構描述，並使用 WSDL round-tripping 功能在 WSDL 產生精靈中變更您的合約，並重新產生程式碼。

什麼 ’s 下一個

WSCF.blue 則發行為開放原始碼專案位於 wscfblue.codeplex.com。 目前的 Beta 版有一些限制，可能會限制您基本但最常見 Web 服務實作。 就例如 WSDL 的產生精靈目前支援只有基本的 HTTP 繫結。 而且，目前程式碼產生 WSCF.blue 中的只會產生 XmlSerializable 類別，而不是 DataContractSerializable 類別，以支援更多的範圍的結構描述建構。 完整的已知的問題和工具的道路地圖清單位於可用 CodePlex 站台。

如何使用 WSCF 的詳細逐步解說的 thinktecture.com/resourcearchive/tools-and-software/wscf/wscf-walkthrough。 雖然文件根據 WSCF 0.6，說明這些步驟套用到同樣以

總結

Web 服務的結構描述為基礎合約的第一個模型可讓您建立模型的 XML 為主的思維模式與您合約。 這個程序可以讓您著重在可普遍接受的類型和能夠以 XML 格式呈現的階層式資料結構。 tooling 支援務必讓 Web 服務的平台的成功。 WSCF.blue 延伸為 WCF 開發人員輕鬆結構描述為基礎的合約的第一個開發的 WCF 所提供，方塊工具的郵件。

Christian Weyer * 且 cofounder thinktecture 的主要架構設計人員與模型和許多年實作 Java、 COM、 DCOM、 COM +，Web 服務，WCF 及其他技術的分散式應用程式。 Christian 是傳統的 Web 服務合約第一個工具，.NET 的原始的 inventor。 在 thinktecture.com/staff/christian，以取得他的聯繫。*

Buddhike de Silva 會根據澳洲的工程的夥伴。 之前將移至澳洲，他是 thinktecture 在前置重疊時間工程。 設計及實作分散式應用程式多年 Buddhike，他也很長的時間參與者 WSCF/WSCF.blue 專案。 您可以在 http://blogs.thinktecture.com/buddhike 取得他的聯繫。

1 合約，技術報告 TR-EI-12/CO，互動式軟體工程 Inc.，1986年所設計。

2 http://se.ethz.ch/~meyer/publications/computer/contract.pdf

3 rESTful 服務不過透過交換標準的 HTTP 訊息與他們的用戶端進行通訊並遵循完全不同的範例。