：

考虑到不同组件协议对于交互过程数据表示的不同，WCF中抽象了很具意义的消息（Message）对象，整个WCF是一个基于消息的API系统，而抽象消息对象的出现也为上层调度和业务逻辑部分提供了必要支持。首先，它是对调用过程载体和传输机制的抽象，例如：MSMQ调用中的报文、Web Service调用中的XML over HTTP请求；其次它也适应了对通信协议的抽象，将文本数据、二进制数据和用于大容量持续交互的特殊编码数据从业务处理的角度剥离——业务逻辑就关心对象实体需要的内容条目即可。消息的处置采用通道（Channel）方式，也就是通过一个栈(Channel Stack)的方式逐层对消息数据、消息头进行处理，为了适应不同协议、不同通信机制，Channel被分为协议通道（transport channels） 和协议通道（protocol channels）。前者是面向网络的，主要负责从网络读写外部数据，同时考虑到不同数据编码方式的不同，传输通道还负责转换相关数据编码，事实上WCF项目开发中该类channel一般采用微软提供的现成类型。后者是面向协议相关数据加工的，由于一般而言WS-*相关协议的操作都是通过在消息头部进行扩展，所以protocol channel一般也都是面向消息头操作，例如常用的WS-Security协议。

       一般而言，根据需要您可以选择各个WCF环境内置的一些通道：

l         采用增加了WS-Reliable协议的消息通道，因为它主要用于保障消息的可靠交付，由于WCF设计上即是面向一个完全分布的网络环境，因此尤其对于基于HTPP的调用更是需要考虑到可能的消息交付错误。因此，这个通道借助被业内主要厂商普遍接受的WS-Reliable标准解决了与业务逻辑无关，但是技术上又非常具有挑战性的开发工作，他可以保证4种可靠交付模式：At Least Once、At Most Once、Exactly Once、A Ordering Group（确保一组消息按照既定次序逐个有效交付），前三种模式的示意如下：

l         考虑到防火墙、IPSEC等网络限制，建议尽量采用HTTP Channel进行消息内容的HTTP编码，不过如果您的应用是同一信任域（或者具有直接信任关系的信任域）之间的服务调用，TCP Channel将使您在传输效率、网络流量方面获益。

l         在需要事务性保障的情况下应选择Transaction Flow Channel；如果消息的调用是进程内调用，可以采用类似Unix系统命名管道（Named Pipe）机制的Named Pipe Channel。

l         如果调用上涉及与VMS、非TCP/IP协议平台应用、高安全性敏感隔离应用（例如：采用网闸隔离）等这类特殊应用通信，那么MSMQ Channel将非常必要。