學習有關進行 Windows Communication Foundation 編程的基礎知識

 

Windows Communication Foundation (WCF)（以前的代號為“Indigo”）將為使用 Microsoft .NET Framework 的開發人員從根本上改變分布式編程的介面。WCF 將現有的整套 .NET 分布式技術整合為一個編程模型，通過穩定的結構、極大改進的功能性和互通性以及您希望擁有的所有可擴充性，全面改善了您的體驗。本文將向您介紹 WCF 編程以及如何快速入門。

正如其名稱表明的那樣，WCF 為 .NET Framework 提供了一個基礎，使其能夠編寫代碼，以在組件、應用程式和系統之間進行通訊。WCF 的設計遵循的是面向服務的原則。服務是指可以通過訊息與之進行互動的一段代碼。服務是被動的。它們等待傳入訊息後才開始工作。用戶端是發起者。用戶端將訊息發送給服務來請求工作。

圖 1：服務和端點

服務提供一個或多個端點，可將訊息發送到這些端點。每個端點由一個地址、一個綁定和一個合約組成（請參見圖 1）。地址指定發送訊息的目標位置；綁定描述如何發送訊息；合約描述訊息所包含的內容。用戶端需要先獲知此資訊才能訪問服務。

服務可以將端點描述打包以實現與用戶端的共用，一般通過使用 Web 服務描述語言 (WSDL) 來實現。隨後，用戶端可以使用所提供的服務描述在其環境內（能夠發送和接收正確的訊息）產生代碼（請參見圖 2）。

圖 2：共用端點描述

Windows Communication Foundation 提供了一個位於 System.ServiceModel 命名空間中的新的類庫，使這些面向服務的概念成為現實。這就是通常所說的 WCF 編程模型。

WCF 編程模型

通過 WCF，您可以編寫提供端點的服務，也可以編寫與端點進行互動的用戶端。因此，端點是 WCF 編程模型和基礎結構的核心。具有 .NET 類和介面的 WCF 模型端點如圖3 所示。無論您編寫的是 WCF 用戶端還是服務，該映射都是正確的。

在建立 WCF 服務時，通常首先定義用作服務合約的 .NET 介面定義。然後在 .NET 類（稱為服務類型）中實施服務合約並配置其行為。接下來，定義服務要提供的端點，並為每個端點指定位置、綁定及合約。最後，使用 WCF 託管基礎結構在應用程式中託管服務類型。服務類型被託管後，用戶端就可以檢索其端點描述並開始與其整合。

建立 WCF 用戶端時，首先需要獲得要訪問的目標端點的描述。該端點描述可用於動態地建立一個類型代理。WCF 提供了一種名為 SvcUtil.exe 的工具來自動執行該進程。然後，您可以針對類型代理編寫代碼，通過向目標端點發送相應的訊息來訪問服務。

返回頁首

服務合約和調度行為

使用傳統的 C# 介面定義在 .NET 中建立服務合約。可以將任意 .NET 介面作為起始點，如以下所示：

namespace ServiceLibrary{public interface IEchoService{string Echo(string msg);}}

要使其成為 WCF 服務合約，必須使用 [ServiceContract] 為介面本身添加批註，使用 [OperationContract] 為要提供的每個操作添加批註：

using System.ServiceModel；namespace ServiceLibrary{[ServiceContract(Namespace="http://example.org/echo/")]public interface IEchoService{[OperationContract]string Echo(string msg);}}

這些屬性影響 .NET 領域和 SOAP 領域之間的映射。WCF 使用服務合約中的資訊來執行調度和序列化。調度是為傳入的 SOAP 訊息確定調用方法的過程。序列化是 SOAP 訊息中的資料和方法調用中使用的相應 .NET 對象之間映射的過程。該映射由操作的資料合約進行控制。

WCF 根據訊息動作進行調度。服務合約中的每個方法都將根據服務命名空間和方法名稱自動被指定一個動作值。例如，剛才所示的 Echo 方法的預設動作為 http://example.org/echo/Echo。可以使用 [OperationContract] 為每個方法自訂動作值。如果具體匹配不存在，可使用值 * 來代表任意動作。

在下例中，WCF 會將帶有 urn:echo:string 動作的訊息調度到 Echo 方法，並將帶有任何其他動作的訊息調度到 EchoMessage 方法：

[ServiceContract(Namespace="http://example.org/echo/")]public interface IEchoService{[OperationContract(Action="urn:echo:string")]string Echo(string msg);[OperationContract(Action="*")]Message EchoMessage(Message msg);}

返回頁首

資料合約

根據動作確定目標方法後，WCF 將依靠該方法的資料合約來執行序列化。資料合約由方法簽名中使用的類型進行定義。在上例中，EchoMessage 是通用的，可用於處理多種傳入的 SOAP 訊息。因此，我已經使用 Message 來建立輸入和輸出。Message 是一種特殊類型，用於表示流經 WCF 的所有訊息。使用 Message 時，WCF 不執行基於類型的序列化。而是使您可以直接存取存在於 SOAP 訊息中的內容。

不使用 Message 時，WCF 將執行序列化以在存在於 SOAP 訊息中的資料和需要調用方法的相應 .NET 對象之間建立映射。例如，對於 Echo，WCF 將 SOAP 承載映射到一個 .NET 字串。WCF 為所有 .NET 原始類型（字串、整數、雙精確度等）提供隱含映射。

WCF 序列化 .NET 類的方式取決於正在使用的序列化引擎。預設的序列化引擎稱為 DataContract，它是目前在 ASMX 中使用的預設序列化引擎 XmlSerializer 的簡化版本。DataContract 定義批註類定義的屬性，以便影響序列化進程。以下為使用 DataContract 的樣本：

[DataContract(Namespace="http://example.org/person")]public class Person{[DataMember(Name="first", Order=0)]public string First;[DataMember(Name="last", Order=1)]public string Last;[DataMember(IsRequired=false, Order=2)]private string id;...}

使用 DataContract，只能序列化標有 DataMember 的欄位。還可以序列化私人欄位。這與 XmlSerializer 的作用方式大不相同。現在，可以在操作合約中使用 Person：

[ServiceContract(Namespace="http://example.org/echo/")]public interface IEchoService{... //先前的方法已省略[OperationContract]Person EchoPerson(Person p);}

調用 EchoPerson 後，WCF 將根據在 Person 類上指定的 DataContract 屬性來序列化 Person 執行個體。DataContract 將產生一種非常簡單的 XML 結構，即元素序列。可以控制每個元素的名稱、順序以及是否需要特殊元素，但也只能控制這些。

如果需要執行更複雜的操作，WCF 允許您後退，以使用 XmlSerializer。您通過使用 [XmlSerializerFormat] 批註介面來表明要使用 XmlSerializer：

[ServiceContract][XmlSerializerFormat]public interface IEchoService { ... }

這會要求 WCF 根據 XmlSerializer 預設值和不同的 System.Xml.Serialization 自訂屬性來對合約中的所有類型都使用 XmlSerializer。這使得將現有 ASMX 服務移動到 WCF 更加輕鬆。

WCF 還支援對標有 [Serializable] 的類型進行序列化，從而可以不更改 .NET 遠程類型就能與 WCF 一起使用。WCF 為 [Serializable] 類型提供隱含映射，在其中將自動序列化所有公用/私人欄位。

返回頁首

訊息和服務合約

到現在為止的所有樣本均依靠 WCF 將方法簽名自動對應到 SOAP 訊息。參數列表和傳回型別將始終分別映射到請求和響應的 SOAP 主體。如果需要支援標題，可以編寫另一個類來為個別操作建立整個 SOAP 封裝的結構，同時指定哪些欄位對應到標題和主體。使用 [MessageContract] 屬性定義該映射：

[MessageContract]public class EchoPersonMessage{[MessageBody]public Person Person;[MessageHeader]public Authorization Authorization;}

在本例中，Person 欄位被映射到 SOAP 主體，而 Authorization 欄位被映射到 SOAP 標題。現在，可以在操作合約中使用 EchoPersonMessage：

[ServiceContract]public interface IEchoService{... //先前的方法已省略[OperationContract]void EchoPerson(EchoPersonMessage msg);}

Using MessageContract 是一項更先進的技術，僅在需要對 SOAP 合約進行直接控制時才有必要使用該技術。

返回頁首

實施服務合約

現在，只需通過在類中實現 .NET 介面即可實施服務合約：

using System.ServiceModel;namespace ServiceLibrary{public class EchoService :IEchoService{public string Echo(string msg){return msg;}... //其餘的方法已省略}}

執行此操作，將確保 EchoService 支援由 IEchoService 定義的服務合約。使用介面定義服務合約時，不需要類定義上的任何與合約相關的屬性。然而，您可能希望使用 [ServiceBehavior] 來影響其本地行為：

using System.ServiceModel;namespace ServiceLibrary{... //介面定義已省略[ServiceBehavior(InstanceContextMode=InstanceContextMode.Single,ConcurrencyMode=ConcurrencyMode.Multiple)]public class EchoService :IEchoService{...

該特殊樣本要求 WCF 管理服務類型的單個執行個體以及允許對該執行個體的多線程訪問。還存在一個用於控制操作層級行為的 [OperationBehavior] 屬性。

行為會影響主機內的進程，但絕不會影響服務合約。行為是其中一個主要的 WCF 可擴充性要點。實現 IServiceBehavior 的任何類都可以通過使用自訂屬性或配置元素而被應用到服務中。

返回頁首

託管服務和定義端點

要使用 EchoService，需要在基於 .NET 的應用程式中對其進行託管。ServiceHost 類使您可以對 WCF 託管基礎結構進行直接控制。您可以根據特定的服務類型執行個體化 ServiceHost。以下代碼顯示了如何在控制台應用程式中執行該操作：

using System;using System.ServiceModel;using ServiceLibrary;class Program{static void Main(string[] args){using (ServiceHost host = new ServiceHost(typeof(EchoService), new Uri("http://localhost:8080/echo"))){...

除指定服務類型之外，還需要為計劃使用的各個傳輸指定基址。在本例中，我已指定了一個基址 http://localhost:8080/echo。該地址將用作任何相對 HTTP 地址（我可能在添加端點時指定）的基址。HTTP 基址還用作檢索服務描述的預設地址。

然後，添加服務端點。此外，服務可能包含一個或多個端點，每個端點都由一個地址、一個綁定和一個合約組成。通過調用 AddServiceEndpoint 為 ServiceHost 提供該資訊。這是您指定先前所定義服務合約 (IEchoService) 的位置。對於綁定，通常從 WCF 附帶的許多預定義的綁定和給定綁定傳輸的相應地址中進行選擇。下面是一個樣本：

host.AddServiceEndpoint(typeof(IEchoService),new BasicHttpBinding(), "svc");host.AddServiceEndpoint(typeof(IEchoService),new NetTcpBinding(), "net.tcp://localhost:8081/echo/svc");

在此特殊樣本中，我已將 IEchoService 指定為兩個端點的合約，但每個端點都使用不同的綁定和地址。第一個端點使用 BasicHttpBinding 和 svc 相對 HTTP 地址（將 http://localhost:8080/echo/svc 作為其絕對位址）。第二個端點使用 NetTcpBinding 和地址 net.tcp://localhost:8081/echo/svc。因此，該服務允許使用者使用不同的 WS-* 協議（由每個綁定定義）通過 HTTP 或 TCP 與其通訊。

返回頁首

選擇和自訂綁定

WCF 基礎結構嚴重依賴端點定義來控制處理訊息的方式。實際上，WCF 使用端點定義來動態地建立主機與用戶端之間的相應訊息處理運行時。綁定對該過程具有最顯著的影響。

綁定控制訊息通訊的三個方面：WS-* 協議的套件，包括 WS-Security、WS-ReliableMessaging 等；訊息編碼方式，例如 XML 1.0、訊息傳輸最佳化機制 (MTOM) 和二進位；傳輸協議，包括 HTTP、TCP 和 Microsoft Message Queuing (MSMQ)。一個給定的綁定指定一種訊息編碼方式和一個傳輸，但可以指定多個 WS-* 協議。因此，存在相當多的排列可以使用。為了簡化需要，WCF 提供一套預定義的綁定，適用於最常用的情況。圖4 列出了部分綁定並描述了它們所表示的內容。

那些注重互通性但不需要 WS-* 功能的開發人員通常會使用 BasicHttpBinding。那些注重互通性、但同時也需要基於訊息的安全、可靠的訊息傳送和事務的開發人員通常會選擇 WSHttpBinding。在兩端（用戶端和服務）上同時使用 WCF 的開發人員可以從 NetTcpBinding 和 NetNamedPipeBinding 中選擇，從而提供顯著的最佳化。那些組建非同步系統的開發人員可以選擇 NetMsmqBinding。還有少數綁定未列於此，例如用於與現有 MSMQ 應用程式進行整合的 MsmqIntegrationBinding、用於組建對等網路服務的 NetPeerTcpBinding 以及用於聯合安全性的 WSFederationBinding。服務可以支援這些綁定的任意組合。

選擇並執行個體化一個綁定後，可以通過綁定類上提供的屬性來自訂它的某些特徵。下例顯示了如何在 BasicHttpBinding 上啟用基於傳輸的安全性：

BasicHttpBinding b = new BasicHttpBinding();b.Security.Mode = BasicHttpSecurityMode.Transport;b.Security.Transport.ClientCredentialType =HttpClientCredentialType.Basic;host.AddServiceEndpoint(typeof(IEchoService), b, "svc");

如果預定義綁定及其自訂仍然不能滿足您的要求，還可以通過實現從綁定派生的類來編寫自訂綁定。

返回頁首

開啟主機

既然已經使用端點資訊配置了主機，那麼 WCF 就可以建立支援您的配置所需要的運行時。當您在特定的 ServiceHost 上調用 Open 時會發生這種情況：

host.Open();

返回對 Open 的調用後，WCF 運行時已建立並準備在每個端點指定的地址處接收訊息。在此過程中，WCF 為每個提供的端點產生了一個端點偵聽程式，並產生了支援由綁定指定的 WS-* 協議所需的代碼。（端點偵聽程式是一段代碼，實際上，它使用指定的傳輸和地址偵聽傳入的訊息）。

您可以通過 ServiceHost 提供的物件模型來檢索關於在運行時的服務的資訊。這使您可以檢索可能希望獲知的有關初始化服務的任何資訊，例如，服務所提供的端點以及當前活動的端點偵聽程式。

圖5 顯示了一個關於託管 EchoService 的控制台應用程式的完整樣本。圖 6 顯示了輸出。請注意，有兩個我並未在 ServiceEndpoint 中指定的附加端點偵聽程式地址。通過使用 HTTP 基址檢索服務描述，WCF 自動提供了這些地址。

圖 6：控制台應用程式的輸出

如果瀏覽 http://localhost:8080/echo，您將看到預設的 WCF 協助頁面（請參見圖 7），如果瀏覽 http://localhost:8080/echo?wsdl，您將看到產生的 WSDL 定義。另一個端點偵聽程式 (http://localhost:8080/echo/mex) 知道如何表達 WS-MetadataExchange。需要注意的很重要的一點是，該樣本未以任何方式使用 IIS。WCF 提供了與 httpsys 的內嵌式整合，這樣可以使任意應用程式自動成為一個 HTTP 偵聽程式。

圖 7：EchoService 協助頁面

返回頁首

佈建服務端點

由於端點詳細資料可能會隨時間的推移而變化，因此將端點資訊寫入程式碼到主應用程式中並不是理想的方法。不難想象如何才能將端點資訊儲存到設定檔或資料庫中，並在初始化 ServiceHost 時讀取該資訊。由於這是一個常見需求，因此 WCF 通過預定義的 <system.serviceModel> 配置區段自動提供該功能。

以下設定檔定義了已通過調用 AddServiceEndpoint 指定的兩個相同的端點：

<configuration><system.serviceModel><services><service type="ServiceLibrary.EchoService"><endpoint address="svc" binding="basicHttpBinding"contract="ServiceLibrary.IEchoService"/><endpoint address="net.tcp://localhost:8081/echo/svc"binding="netTcpBinding"contract="ServiceLibrary.IEchoService"/></service></services></system.serviceModel></configuration>

如果將該設定檔添加到圖5 所示的主應用程式並標註對 AddServiceEndpoint 的調用，您將會在輸出中看到相同的結果。由於通訊詳細資料已經從編譯代碼中完全分解出來，因此這會提高部署的靈活性。您還可以在 <system.serviceModel> 中配置綁定。圖8 顯示了如何配置 basicHttpBinding 以使用傳輸安全性（正如我在代碼中已經使用的）。

甚至可以使用 <customBinding> 元素從頭開始定義新的自訂綁定，這等同於從 Binding 中派生一個新類。當開始配置端點、綁定甚至行為時，在代碼中可以執行的任何操作，在配置時也都可以執行。

圖 9：使用 GUI 定義端點

儘管用於設定檔的 IntelliSense 可以在 Visual Studio 2005 中運行得很好，但是某些開發人員依舊從來不使用 XML。WinFX SDK 包括一個名為 SvcConfigEditor 的工具，該工具提供了一個可以與多種 <system.serviceModel> 設定一起使用的圖形介面。圖 9 顯示了如何使用該工具配置端點。

返回頁首

使用啟用服務

儘管我一直在嘗試控制台應用程式，但 ServiceHost 使得在各種應用程式（包括 Windows Forms 應用程式和管理 Windows 服務）中託管 WCF 服務更加便捷。在所有這些應用程式方案中，您負責管理託管 WCF 的過程。這在 WCF 術語中稱為自託管。

除自託管之外，WCF 還通過將 IIS 與傳統的 虛擬主機技術結合使用，使啟用服務成為可能。可以通過使用 .svc 檔案（與 .asmx 類似）指定要託管的服務類型來完成此操作：

<%@Service class="ServiceLibrary.EchoService" %>

將該檔案放到一個虛擬目錄中，並將服務類型部署到其 \bin 目錄或全域組件快取 (GAC) 中。使用該技術時，您在 web.config 中指定服務端點，但由於 .svc 檔案位置已經隱含了該地址，因此無需再指定地址。

<configuration><system.serviceModel><services><service type="ServiceLibrary.EchoService"><endpoint address="" binding="basicHttpBinding"contract="ServiceLibrary.IEchoService"/></service>...

如果現在瀏覽到 .svc 檔案，您會注意到已顯示協助頁面，表示已在 ASP.NET 應用程式定義域中自動建立了 ServiceHost。該操作由一個 HTTP 模組完成，此模組可以過濾傳入的 .svc 請求並在需要時自動建立和開啟相應的 ServiceHost。

如果安裝 Visual Studio 2005 的 WinFX 擴充，您會發現一個名為 Indigo Service（該名稱將更改）的新 Web 網站項目模板。根據該模板建立新的 Web 網站時，它將自動向您提供 .svc 檔案和相應的實作類別（存在於 App_Code 中）。該模板還在 web.config 中附帶了一個預設的端點配置。

在 IIS 5.1 版和 6.0 版中，WCF 啟用模型被捆綁到 ASP.NET 流水線，因此也就被捆綁到 HTTP。IIS 7.0（計劃與 Windows Vista 一起發布）引入了中立傳輸啟用機制，稱為 Windows 啟用服務 (WAS)。通過 WAS，您可以在任何傳輸中應用 .svc 之類的啟用。

返回頁首

進行用戶端編程

進行 WCF 用戶端編程包括根據服務端點的地址、綁定和合約向其發送訊息。要完成該操作，首先要建立 ServiceEndpoint 來表示目標端點。下例顯示了如何根據服務的 HTTP 端點在用戶端控制台應用程式中建立 ServiceEndpoint：

using System;using System.ServiceModel;using ServiceLibrary;class Program{static void Main(string[] args){ServiceEndpoint httpEndpoint = new ServiceEndpoint(ContractDescription.GetContract(typeof(IEchoService)),new BasicHttpBinding(), new EndpointAddress("http://localhost:8080/echo/svc");

該代碼假定用戶端可以訪問該服務所使用的同一 IEchoService 介面定義，並且假定用戶端知道要使用的綁定和地址。然後，可以根據 ServiceEndpoint 建立 ChannelFactory：

ChannelFactory<IEchoService> factory =new ChannelFactory<IEchoService>(httpEndpoint);

ChannelFactory 用於建立類型代理。在本例中，它建立了 IEchoService 類型的代理，您可以使用該代理調用由合約定義的操作：

IEchoService svc = factory.CreateChannel();Console.WriteLine(svc.Echo("Hello, world"));

如果服務需要一個自訂綁定，您必須在建立 ServiceEndpoint 之前建立該綁定並對其進行自訂。如果您要訪問 TCP 端點，只需建立另一個 ServiceEndpoint 來指定 TCP 端點詳細資料並將其提供給 ChannelFactory 而不是 HTTP 端點即可。其他所有項目保持不變。

代理使您可以避免使用不同的地址和綁定，並允許您針對服務合約編寫應用程式代碼。圖10 顯示了完整的用戶端控制台應用程式。

返回頁首

配置用戶端端點

將端點資訊寫入程式碼到用戶端代碼也不是很理想的方法。因此，WCF 提供了一個類似的配置機制用於在 <system.serviceModel> 中指定用戶端端點。以下應用程式設定檔指定了在該代碼中使用的同一用戶端端點詳細資料：

<configuration><system.serviceModel><client><endpoint name="httpEndpoint"address="http://localhost:8080/echo/svc"binding="basicHttpBinding"contract="ServiceLibrary.IEchoService"/><endpoint name="tcpEndpoint"address="net.tcp://localhost:8081/echo/svc"binding="netTcpBinding"contract="ServiceLibrary.IEchoService"/></client></system.serviceModel></configuration>

請注意，我已經為每個用戶端端點指定了名稱。建立 ChannelFactory 時，可以在您的代碼中使用這個名稱，如以下代碼所示：

using (ChannelFactory<IEchoService> httpFactory =new ChannelFactory<IEchoService>("httpEndpoint")){svc = httpFactory.CreateChannel();Console.WriteLine("Invoking HTTP endpoint: {0}",svc.Echo("Hello, world"));}

現在，如果要為 TCP 端點建立一個 ChannelFactory，只需將配置名稱更改為 tcpEndpoint 即可。還可以在用戶端設定檔中配置綁定，正如我在服務組態檔中所做的那樣。

如果將此設定檔添加到圖10 中所示的用戶端控制台應用程式、標註建立 ServiceEndpoint 對象的代碼並在構造每個 ChannelFactory 時指定端點名稱，將得到相同的結果。

返回頁首

產生用戶端代理

上述樣本假定了用戶端可以訪問用於實現服務的同一介面定義。當 .NET 用於執行兩端（在傳統的 .NET 遠程方案中）時這種假定是可以的，但它不一定適用於所有情況，當服務未通過 .NET Framework 實現時，這種假定就不成立。上述樣本還假定用戶端事Crowdsourced Security Testing道準確的端點詳細資料，但這種假定也不一定始終成立。

當用戶端沒有訪問此類資訊的許可權時，它們可以使用 WS-MetadataExchange 規範獲得該資訊。服務通過 WSDL 定義與用戶端共用端點描述。大多數服務平台提供了用於從 WSDL 定義產生用戶端代碼的工具。WinFX SDK 為此目的提供了 SvcUtil.exe。

執行 SvcUtil.exe 時，您指定了 WSDL 定義的 URL，它將產生所需的 .NET 代碼和配置元素，用以定義端點和服務端點使用的綁定。圖 11 顯示了通過 http://localhost:8080/echo 運行 SvcUtil.exe 的輸出。請注意，它產生了兩個檔案：EchoService.cs 和 output.config。

圖 11：SvcUtil.exe 輸出

EchoService.cs 包含一個與服務實現的定義等效的 .NET 介面定義。Output.config 包含訪問服務所需的用戶端端點資訊（與我剛才手寫的內容類別似）。您必須手動將 output.config 的內容與應用程式設定檔進行合并。這種情況下，可以使用上述樣本中所使用的相同技術編寫用戶端代碼，僅使用產生的介面和設定檔。

總之，WCF 用戶端編程模型的服務邊界非常明確。根據特定的服務端點建立一個類型通道，然後通過該通道發送訊息。儘管它有助於強調面向服務的原則，但這可能使該層級的工作始終枯燥乏味。為了協助您更好地工作，SvcUtil.exe 還產生一個代理類，可以完全隱藏 ChannelFactory 和 ServiceEndpoint 建立詳細資料。如果開啟 EchoService.cs，您將看到以下類定義：

public partial class EchoServiceProxy :System.ServiceModel.ClientBase<IEchoService>, IEchoService{public EchoServiceProxy(){}public EchoServiceProxy(string endpointConfigurationName) :base(endpointConfigurationName){}...

該代理類可以簡化用戶端應用程式代碼。您需要做的只是執行個體化代理、指定端點配置的名稱和進行方法調用。下面是一個樣本：

using (EchoServiceProxy proxy = new EchoServiceProxy("IEchoService")){//調用服務作業Console.WriteLine("Invoking HTTP endpoint: {0}",proxy.Echo("Hello, world"));}using (EchoServiceProxy proxy = new EchoServiceProxy("IEchoService1")){//調用服務作業Console.WriteLine("Invoking TCP endpoint: {0}",proxy.Echo("Hello, world"));}

產生的設定檔 (output.config) 定義了 IEchoService 和 IEchoService1 端點配置。

返回頁首

記錄訊息

開始使用 WCF 編程模型時，您可能會發現跟蹤在用戶端和服務之間傳輸的 SOAP 訊息非常有用。Windows Communication Foundation 為訊息日誌記錄提供內嵌式支援，可以在應用程式設定檔中將其開啟。

圖 12：SvcTraceViewer.exe

SvcConfigEditor 提供了一個“診斷”選項卡，您可以在此啟用訊息記錄功能。啟動訊息記錄並重新運行應用程式後，您將看到追蹤檔案顯示在指定的位置。WinFX SDK 還提供了 SvcTraceViewer.exe，用於查看追蹤檔案中的資訊（請參見圖 12）。

返回頁首

小結

對於使用 .NET Framework 的開發人員來說，WCF 是分布式編程領域的一個新台階。如果您當前正使用目前的任何 .NET 分布式技術建立系統，那麼您應該開始關注 WCF 及其發展趨勢。使用 WCF 編寫所有與通訊相關的以 .NET 為目標的代碼只是一個時間問題。

註：本文中介紹的所有程式碼範例均基於 Visual Studio 2005 和 WCF November 2005 CTP。