《WCF技術内幕》翻譯33：第2部分_第6章_通道：通道形狀

<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">Chapter 6: Channels</a>

<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">第6章：通道（Channel）</a>

<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">Overview</a>

<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">概述</a>

<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">Channels in Perspective</a>

<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">正确認識Channel</a>

<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">The Channel State Machine</a>

<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">通道狀态機</a>

<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">Introduction to Channel Shape</a>

<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">通道形狀</a>

<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">Channel Interfaces and Base Types</a>

<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">通道接口和基本類型</a>

<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">Channel Flavors</a>

<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">通道功能</a>

<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">Creating a Custom Channel</a>

<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">自定義通道</a>

<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">Summary</a>

<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">本章小結</a>

通道形狀是我們對通道進行分類的重要依據之一。概念上，一個通道形狀對應于一個或多個消息交換模式（MEPs）,第3章“消息交換模式、拓撲與編排”裡曾經讨論過這個概念。為了說明問題，考慮一下發送者和接收者使用請求/應答模式來交換消息的情況。在請求/應答模式裡，發送者發送消息給接收者，接收者回複消息給發送者，請求消息和應答消息之間的關系是固定的。因為通道是發送者和接收者交換消息的實體途徑，發送者和接收者必須建立它們自己的通道。當發送者和接收者通過請求/應答模式來交換消息的時候，發送者和接收者必須了解請求/應答模式的規則。在結構上來說，這意味着發送者上的通道要定義發送消息和接收消息的成員。此外，發送者和接收者需要定義關聯請求消息和應答消息的成員。

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

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

圖6-2消息交換模式（MEP）與通道形狀的關系

MEP

Sender

Receiver

資料報

IOutputChannel

IInputChannel

請求/應答

IRequestChannel

IReplyChannel

雙工

IDuplexChannel

P2P

這裡還需要解釋一下表6-2裡的雙工MEP。記住雙工MEP裡，發送者和接收者都可以發送和接受消息。在成員級别上，兩者都可以定義一個名為一個名為Send和一個名為Receive的方法。

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

所有支援會話的通道的一個共同特性就是它們可以擁有自己的辨別符，WCF基礎結構裡的不同子產品都可以使用這個辨別符來關聯消息。概念上看，通道需要實作System.ServiceModel.Channels.ISessionChannel&lt;T&gt;接口來會支援會話。ISessionChannel&lt;T&gt;的泛型參數必須實作System.ServiceModel.Channels.ISession接口。下面代碼展示了這些接口裡的成員：

public interface ISession { 

 String Id { get; } 

} 

public interface ISessionChannel&lt;T&gt; where T: ISession { 

 T Session { get; } 

}

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

圖6-3消息交換模式（MEP）與會話通道形狀的關系

IOutputSessionChannel

IInputSessionChannel

IRequestSessionChannel

IReplySessionChannel

IDuplexSessionChannel

<a></a>

備注：與上一節裡介紹的“通道狀态機”相反,這裡隻有通道才會實作通道形狀接口，并且需要一個表示通道形狀接口的引用。

【老徐備注】

使用資料報 MEP 時，用戶端使用“啟動後不管”的交換形式發送消息。“啟動後不管”交換形式是一種要求對成功傳遞做帶外确認的交換形式。消息在傳輸過程中可能會丢失，而永遠不能到達服務。如果在用戶端成功完成發送操作，這并不保證遠端終結點已經收到消息。資料報是消息傳遞的基本構造塊，因為您可以在它上面建構自己的協定，包括可靠的協定和安全的協定。用戶端資料報通道實作 IOutputChannel 接口，而服務資料報通道實作 IInputChannel 接口。

在此 MEP 中會發送一個消息并收到一個答複。此模式由請求-響應對組成。請求-響應調用的示例是遠端過程調用 (RPC) 和浏覽器的 GET 請求。此模式也稱為半雙工。在此 MEP 中，用戶端通道實作 IRequestChannel，而服務通道實作 IReplyChannel。

雙工 MEP 允許用戶端發送任意數量的消息，并且這些消息可以以任何順序接收。雙工 MEP 就像電話通話，所說的每一個字都是一條消息。由于在這種 MEP 下雙方都能發送和接收，由用戶端和服務通道實作的接口是 IDuplexChannel。

http://msdn.microsoft.com/zh-cn/library/aa751829.aspx

 本文轉自 frankxulei 51CTO部落格，原文連結：http://blog.51cto.com/frankxulei/318569，如需轉載請自行聯系原作者