WCF開發插件的應用在一定程度上大大提高了開發人員的開發效率，尤其是在通信方面的操作，提供了一個簡單的操作方法。在這里我們將會針對WCF通道形狀的相關內容，為大家詳細講解這方面的知識。#t#

WCF通道形狀是我們對通道進行分類的重要依據之一。概念上，一個通道形狀對應于一個或多個消息交換模式（MEPs）。為了說明問題，考慮一下發送者和接收者使用請求/應答模式來交換消息的情況。在請求/應答模式里，發送者發送消息給接收者，接收者回復消息給發送者，請求消息和應答消息之間的關系是固定的。因為通道是發送者和接收者交換消息的物理途徑，發送者和接收者必須建立它們自己的通道。當發送者和接收者通過請求/應答模式來交換消息的時候，發送者和接收者必須理解請求/應答模式的規則。在結構上來說，這意味著發送者上的通道要定義發送消息和接收消息的成員。此外，發送者和接收者需要定義關聯請求消息和應答消息的成員。

咋一看，發送者和接收者有著相同的角色。例如，發送者和接收者都可以發送和接收消息。邏輯上的區別就是發送和接收消息過程中的順序不同。這意味著發送者和接收者上的通道會略有不同。這些不同點體現在發送者和接收者通道里定義的成員上。WCF通道形狀是我們命名和劃分這些不同點的方式。因為.NET接口是鑒別.NET類型成員的天然方式，所以它們也是區別通道形狀的最佳方式。

WCF類型系統定義了幾個描述不同WCF通道形狀的接口，這些接口與消息交換模式一一對應。消息交換模式（MEP）、發送者和接受之間的對應關系。這些接口都定義在System.ServiceModel.Channels命名空間下。

實際上，消息程序需要把多個消息關聯到一起。例如，一個交易系統（發送者）也許要發送關于一個交易訂單或者產品的多個消息到財務系統（接收者）。這個關聯的邏輯邊界就是會話（session）。當第一次考慮這些會話的時候，很容易理解為接收者會根據發送者來關聯這些消息。這樣一來，很自然地就會猜想，同時處理5個發送者請求的接收者將會把消息關聯到一個特定的發送者上，正像ASP.NET程序處理來自于多個瀏覽器的請求消息一樣。在WCF應用程序里，這些耦合過于緊密以至于不能滿足過多的消息需求。例如，一個交易系統（發送者）或許發送多個訂單有關的消息，財務系統（接收者）也許要根據需訂單實例而不是交易系統（發送者）來關聯這些消息。

WCF會話是一個通道級別的構造。因為這個概念也就是為了關聯消息，每個通道都自己關聯消息的方式。例如，TCP/IP通道能夠根據接收消息的socket來關聯同一個會話里的消息。與之相對的是，實現了WS-ReliableMessaging規范的通道，可以在消息頭里使用ID屬性來關聯同一個會話里的消息，所以，這也就不需要依賴具體的socket或者傳輸結構了，就可以實現同一個會話里消息的關聯。

所有支持會話的通道的一個共同特性就是它們可以擁有自己的標識符，WCF基礎結構里的不同模塊都可以使用這個標識符來關聯消息。概念上看，通道需要實現System.ServiceModel.Channels.ISessionChannel<T>接口來會支持會話。ISessionChannel<T>的泛型參數必須實現System.ServiceModel.Channels.ISession接口。下面代碼展示了這些接口里的成員：

public interface ISession {  
String Id { get; }  
}  
public interface ISessionChannel<T> where T: ISession {  
T Session { get; }  
} 

如代碼所示，接口暴露了一個名為Id的成員，這個成員表示一個會話標識符。在WCF里，實現了ISessionChannel<T>接口的通道類型被稱為會話通道。為了連貫性考慮，WCF里把會話作為通道形狀的一個變量考慮。換句話說，IDuplexChannel接口包含一個名為IDuplexSessionChannel的變量。從WCF通道形狀的角度來看，IDuplexSessionChannel與IDuplexChannel的通道形狀不同，盡管它們都能夠實現雙工通信。兩者真正的區別在于IDuplexSessionChannel實現了ISessionChannel<T>接口。表6-3列舉了WCF類型系統里的會話通道形狀.