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等东西,但是这些主题都能用单独的篇幅写上一个系列了,那就让我们下个系列分解。
注:要查看原始文章,请看这里的全部索引。