WCF绑定策略图
今天前，我看到了下面一副关于WCF的绑定策略图，但是我忘了来源，原图有些小错误，我已经进行了修正，如果还是有错误的话，请在这里留言，原作者会修改。
图上Class-A的logo来源于我们的培训材料，不代表什么信息，你可以随便使用这幅图。
让我们再次回到正题上。绑定指定了客户端连接到服务的方式，也就说，连接方式是如何被绑定描述的。从下图就能看出，绑定由选择的协议层（protocols），编码层（encoder）和传输层（transport）构成。
上图也显示了WCF的架构。service-host初始化了数个调度程序（dispatchers）。在配置文件中，需要为每个endpoint需要设置要采用的protocols, encoder以及transport。在客户端，也需要这么做。当一条消息从客户端发送到服务端，会首先通过proxy，配置的协议，encoder，并最终发送至传输层。而在服务端，会进行相同的过程，但是顺序却恰好相反。
- 协议层（Protocols）
协议可以是任何东西，或者WCF中某些默认的东西，比如可信赖的消息队列（messaging）或者transactions。当消息需要被加密时，就在这个层完成的。 - 编码层（Encoder）
编码层可以是用于HTTP绑定的text/xml，或者用于TCP绑定的二进制xml。 - 传输层（Transport）
传输层可以是HTTP，TCP, NamedPipes或MSMQ.
选择什么样的绑定方式，取决于你的实际需求。从上面的那个绑定策略图上可以很容易地看出，什么样的绑定在什么样的情况下可以使用。下面的表格显示了一些属性，以及那些绑定方式支持他们。
从上图可以看出，如果选择interop，传输层就只能选择HTTP，不能选择其他传输层的原因在于WCF不能同其他的不支持这些层的平台进行交互。使用basicHttpBinding，服务就能同遵从WS-Basic Profile的客户端进行通信。对于webservices能够使用basicHttpBinding进行通信，大家都知道。wsHttpBinding可以视为一种基本的内置WSE 3.0的webservice结构。因为是可互操作的（interoperable）,所以可以带来诸多便利，但是对于其他平台而言，即使这些平台遵从WS-* 规范，也很难同我们的服务进行通信。
所有的绑定方式中，只有一个既支持transport (T),也支持message (S) security。不过，基本上如果你选择了basicHttpBinding，就只能通过SSL来对你的服务进行加密了，也就是说，你将得到一个以HTTPS://开头的地址。
绑定同session有交叉之处，也就是说支持session，同样也支持transactions。双向（Duplex）意味着服务端和客户端可以来回发送消息，举例来说，在耗时长的请求过程中更新状态。
当然通过扩展WCF（extending WCF），上表仍然可以继续进行更改。这里就不再对其进行讨论，因为扩展WCF在internet上的应用非常广泛。一个典型的扩展就是可以创建一个新的传输层来支持通过SMTP，FTP或者其他任何你可以想象的东西来发送消息。Microsoft有一个例子演示了通过添加传输层和编码层，能够让客户端轻而易举地同任何外部系统进行通信。但是我想这只不是就是在这些系统的顶层添加一个服务接口而已，然后再使用缺省或者规则的绑定方式通过WCF暴露出来。
WCF和绑定的神奇之处就在于，理论上，部署一个服务后，仍然可以添加，提供或者支持其他的endpoints。举例来说，通过basicHttpBinding运行，之后又添加上netTcpBinding。通过之前文章中用到过得demo，不需要改动任何代码，就能实现这个更改。
本文讨论了绑定，但是还得继续深入诸如security, transactions等东西，但是这些主题都能用单独的篇幅写上一个系列了，那就让我们下个系列分解。
注：要查看原始文章，请看这里的全部索引。
