在WCF中实现双工通信.doc

在WCF中实现双工通信 双工（Duplex）模式的消息交换方式体现在消息交换过程中，参与的双方均可以向对方发送消息。基于双工MEP消息交换可以看成是多个基本模式下（比如请求-回复模式和单项模式）消息交换的组合。双工MEP又具有一些变体，比如典型的订阅-发布模式就可以看成是双工模式的一种表现形式。双工消息交换模式使服务端回调（Callback）客户端操作成为可能。 一、两种典型的双工MEP 1．请求过程中的回调 这是一种比较典型的双工消息交换模式的表现形式，客户端在进行服务调用的时候，附加上一个回调对象；服务在对处理该处理中，通过客户端附加的回调对象（实际上是调用回调服务的代理对象）回调客户端的操作（该操作在客户端执行）。整个消息交换的过程实际上由两个基本的消息交换构成，其一是客户端正常的服务请求，其二则是服务端对客户端的回调。两者可以采用请求-回复模式，也可以采用单向（One-way）的MEP进行消息交换。图1描述了这样的过程，服务调用和回调都采用请求-回复MEP。 图1 请求过程中的回调 2．订阅-发布 订阅-发布模式是双工模式的一个典型的变体。在这个模式下，消息交换的双方变成了订阅者和发布者，若干订阅者就某个主题向发布者申请订阅，发布者将所有的订阅者保存在一个订阅者列表中，在某个时刻将主题发送给该主题的所有订阅者。实际上基于订阅-发布模式的消息交换也可以看成是两个基本模式下消息交换的组合，申请订阅是一个单向模式的消息交换（如果订阅者行为得到订阅的回馈，该消息交换也可以采用请求-回复模式）；而主题发布也是一个基于单向模式的消息交换过程。订阅-发布消息交换模式如图2所示。 图2 订阅-发布 二、实例演示：创建基于双工通信的WCF应用 接下来我们通过一个的案例演示基于双工通信的WCF应用。为简单起见，我们沿用计算服务的例子。在这之前，我们都是调用CalculuateService直接得到计算结果，并将计算结果通过控制台输出。在本例中我们将采用另外一种截然不同的方式调用服务并进行结果的输出：我们通过单向（One-way）的模式调用CalculuateService（也就是客户端不可能通过回复消息得到计算结果），服务端在完成运算结果后，通过回调（Callback）的方式在客户端将计算结果打印出来。整个应用的层次仍然采用我们一贯的4层结构：Contracts、Services、Hosting和Clients，如图3所示。 图3 双工通信案例应用结构 步骤一：定义服务契约和回调契约 首先进行服务契约的定义，我们照例通过接口（ICalculator）的方式定义服务契约，作用于指定加法运算的Add操作，我们通过OperationContractAttribute特性的IsOneway属性将操作定义成单向的操作，这意味着客户端仅仅是向服务端发送一个运算的请求，并不会通过回复消息得到任何运算结果。 1: using System.ServiceModel; 2: namespace Artech.DuplexServices.Contracts 3: { 4: [ServiceContract(Namespace=/, 5: CallbackContract=typeof(ICallback))] 6: public interface ICalculator 7: { 8: [OperationContract(IsOneWay=true)] 9: void Add(double x, double y); 10: } 11: } 我们试图实现的是通过在服务端回调客户端操作的方式实现运算结果的输出。客户端调用CalculatorService正常的服务调用，那么在服务执行过程中借助于客户端在服务调用时提供的回调对象对客户端的操作进行回调，从本质上讲是另外一种形式的服务调用。WCF采用基于服务契约的调用形式，客户端正常的服务调用需要服务契约，同理服务端回调客户端依然需要通过描述回调操作的服务契约，我们把这种服务契约称为回调契约。回调契约的类型通过ServiceContractAttribute特性的CallbackContract属性进行指定。 上面代码中服务契约ICalculator的回调契约ICallback定义如下。由于回调契约本质也是一个服务契约，所以定义方式和一般意义上的服务契约基本一样。有一点不同的是，由于定义ICalculator的时候已经通过[ServiceContract(CallbackContract=typeof