在WCF中实现双工通信.docx
《在WCF中实现双工通信.docx》由会员分享，可在线阅读，更多相关《在WCF中实现双工通信.docx（11页珍藏版）》请在冰豆网上搜索。
在WCF中实现双工通信
在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:
usingSystem.ServiceModel;
2:
namespaceArtech.DuplexServices.Contracts
3:
{
4:
[ServiceContract（Namespace="
5:
CallbackContract=typeof（ICallback））]
6:
publicinterfaceICalculator
7:
{
8:
[OperationContract（IsOneWay=true）]
9:
voidAdd（doublex,doubley）;
10:
}
11:
}
我们试图实现的是通过在服务端回调客户端操作的方式实现运算结果的输出。
客户端调用CalculatorService正常的服务调用，那么在服务执行过程中借助于客户端在服务调用时提供的回调对象对客户端的操作进行回调，从本质上讲是另外一种形式的服务调用。
WCF采用基于服务契约的调用形式，客户端正常的服务调用需要服务契约，同理服务端回调客户端依然需要通过描述回调操作的服务契约，我们把这种服务契约称为回调契约。
回调契约的类型通过ServiceContractAttribute特性的CallbackContract属性进行指定。
上面代码中服务契约ICalculator的回调契约ICallback定义如下。
由于回调契约本质也是一个服务契约，所以定义方式和一般意义上的服务契约基本一样。
有一点不同的是，由于定义ICalculator的时候已经通过[ServiceContract（CallbackContract=typeof（ICallback））]指明ICallback是一个服务契约了，所以ICallback不再需要添加ServiceContractAttribute特性。
ICallback定义了一个服务操作DisplayResult用于显示运算结果（前两个参数为执行加法运算的操作数），由于服务端不需要回调的返回值，索性将回调操作也设为单向方法。
1:
usingSystem.ServiceModel;
2:
namespaceArtech.DuplexServices.Contracts
3:
{
4:
publicinterfaceICallback
5:
{
6:
[OperationContract（IsOneWay=true）]
7:
voidDisplayResult（doublex,doubley,doubleresult）;
8:
}
9:
}
步骤二：
实现服务
在实现了上面定义的服务契约ICalculator的服务CalculatorService中，实现了Add操作，完成运算和结果显示的工作。
结果显示是通过回调的方式实现的，所以需要借助于客户端提供的回调对象（该对象在客户端调用CalculatorService的时候指定，在介绍客户端代码的实现的时候会讲到）。
在WCF中，回调对象通过当前OperationContext的GetCallback方法获得（T代表回调契约的类型）。
1:
usingArtech.DuplexServices.Contracts;
2:
usingSystem.ServiceModel;
3:
namespaceArtech.DuplexServices.Services
4:
{
5:
publicclassCalculatorService:
ICalculator
6:
{
7:
#regionICalculatorMembers
8:
9:
publicvoidAdd（doublex,doubley）
10:
{
11:
doubleresult=x+y;
12:
ICallbackcallback=OperationContext.Current.GetCallbackChannel（）;
13:
callback.DisplayResult（x,y,result）;
14:
}
15:
16:
#endregion
17:
}
18:
}
注：
OperationContext在WCF中是一个非常重要、也是一个十分有用的对象，它代表服务操作执行的上下文。
我们可以通过静态属性Current（OperationContext.Current）得到当前的OperationContext。
借助OperationContext，我们可以在服务端或者客户端获取或设置一些上下文，比如在客户端可以通过它为出栈消息（outgoingmessage）添加SOAP报头，以及HTTP报头（比如Cookie）等。
在服务端，则可以通过OperationContex获取在客户端设置的SOAP报头和HTTP报头。
关于OperationContext的详细信息，可以参阅MSDN在线文档。
步骤三：
服务寄宿
我们通过一个控制台应用程序完成对CalculatorService的寄宿工作，并将所有的服务寄宿的参数定义在配置文件中。
由于双工通信依赖于一个双工的信道栈，即依赖于一个能够支持双工通信的绑定，在此我们选用了NetTcpBinding。
1:
xmlversion="1.0"encoding="utf-8"?
>
2:
3:
4:
5:
6:
7:
//127.0.0.1:
9999/CalculatorService"
8:
binding="netTcpBinding"contract="Artech.DuplexServices.Contracts.ICalculator"/>
9:
10:
11:
12:
注：
在WCF预定义绑定类型中，WSDualHttpBinding和NetTcpBinding均提供了对双工通信的支持，但是两者在对双工通信的实现机制上却有本质的区别。
WSDualHttpBinding是基于HTTP传输协议的；而HTTP协议本身是基于请求-回复的传输协议，基于HTTP的通道本质上都是单向的。
WSDualHttpBinding实际上创建了两个通道，一个用于客户端向服务端的通信，而另一个则用于服务端到客户端的通信，从而间接地提供了双工通信的实现。
而NetTcpBinding完全基于支持双工通信的TCP协议。
1:
usingSystem;
2:
usingSystem.ServiceModel;
3:
usingArtech.DuplexServices.Services;
4:
namespaceArtech.DuplexServices.Hosting
5:
{
6:
classProgram
7:
{
8:
staticvoidMain（string[]args）
9:
{
10:
using（ServiceHosthost=newServiceHost（typeof（CalculatorService）））
11:
{
12:
host.Open（）;
13:
Console.Read（）;
14:
}
15:
}
16:
}
17:
}
步骤四：
实现回调契约
在客户端程序为回调契约提供实现，在下面的代码中CalculateCallback实现了回调契约ICallback，在DisplayResult方法中对运算结果进行输出。
1:
usingSystem;
2:
usingArtech.DuplexServices.Contracts;
3:
namespaceArtech.DuplexServices.Clients
4:
{
5:
classCalculateCallback:
ICallback
6:
{
7:
8:
publicvoidDisplayResult（doublex,doubley,doubleresult）
9:
{
10:
Console.WriteLine（"x+y={2}whenx={0}andy={1}",x,y,result）;
11:
}
12:
}
13:
}
步骤五：
服务调用
接下来实现对双工服务的调用，下面是相关的配置和托管程序。
在服务调用程序中，通过DuplexChannelFactory创建服务代理对象，DuplexChannelFactory和ChannelFactory的功能都是一个服务代理对象的创建工厂，不过DuplexChannelFactory专门用于基于双工通信的服务代理的创建。
在创建DuplexChannelFactory之前，先创建回调对象，并通过InstanceContext对回调对象进行包装。
1:
xmlversion="1.0"encoding="utf-8"?
>
2:
3:
4:
5:
//127.0.0.1:
9999/CalculatorService"binding="netTcpBinding"contract="Artech.DuplexServices.Contracts.ICalculator"/>
6:
7:
8:
1:
usingSystem;
2:
usingArtech.DuplexServices.Contracts;
3:
usingSystem.ServiceModel;
4:
namespaceArtech.DuplexServices.Clients
5:
{
6:
classProgram
7:
{
8:
staticvoidMain（string[]args）
9:
{
10:
InstanceContextinstanceContext=newInstanceContext（newCalculateCallback（））;
11:
using（DuplexChannelFactorychannelFactory=newDuplexChannelFactory（instanceContext,"CalculatorService"））
12:
{
13:
ICalculatorproxy=channelFactory.CreateChannel（）;
14:
using（proxyasIDisposable）
15:
{
16:
proxy.Add（1,2）;
17:
Console.Read（）;
18:
}
19:
}
20:
}
21:
}
22:
}
在服务寄宿程序启用的情况下，运行客户端程序后，通过服务端执行的运算结果会通过回调客户端的操作显示出来，下面是最终输出的结果。
x+y=3whenx=1andy=2
三、特别注意
接下来我们将针对上面这个案例，讨论一些关于双工服务的细节性问题。
问题1：
回调对双工信道的依赖
在本案例中，由于使用的NetTcpBinding，所以我们底层采用的是TCP协议。
由于TCP协议是一个基于连接的传输协议，只有当通信双方的连接被成功创建出来后，他们之间才能进行正常的消息传输。
在上面给出的客户端代码中，在调用了Add方法后添加了这样的语句“Console.Read（）;”，这是为了阻止调用proxy的Dispose方法，因为该方法将会试图关闭底层的TCP连接。
由于服务端的回调操作也会使用该TCP连接，如果在回调操作尚未执行完毕就试图关闭网络连接，将会导致回调无法正常执行。
所以如果我们将该语句去掉，将会抛出如图4所示的ProtocolException异常。
1:
InstanceContextinstanceContext=newInstanceContext（newCalculateCallback（））;
2:
using（DuplexChannelFactorychannelFactory=newDuplexChannelFactory（instanceContext,"CalculatorService"））
3:
{
4:
ICalculatorproxy=channelFactory.CreateChannel（）;
5:
using（proxyasIDisposable）
6:
{
7:
proxy.Add（1,2）;
8:
//Console.Read（）;
9:
}
10:
}
图4关闭服务代理导致的ProtocolException异常
问题2：
回调导致的死锁
第2个问题是关于并发的问题，我们先看表现出来的现象，再分析原因并找出解决方案。
现在我们修改一下回调契约，将OperationContractAttribute的IsOneWay属性去掉，将Add操作由单向操作改成传统意义的请求-回复服务操作。
运行系统，将会抛出如图5所示的InvalidOperationException异常。
1:
usingSystem.ServiceModel;
2:
namespaceArtech.DuplexServices.Contracts
3:
{
4:
publicinterfaceICallback
5:
{
6:
[OperationContract]
7:
voidDisplayResult（doublex,doubley,doubleresult）;
8:
}
9:
}
图5双工通信的并发、死锁
异常的消息已经道出了出错的原因和解决方案，不过可能是由于VisualStudio汉化的原因，显示的出错消息显得有点不知所以。
究其本质，这是一个死锁导致的异常，由于默认的情况是服务的执行按Single并发模式进行，也就是说在服务执行全程，服务对象只能被一个线程访问。
WCF通过加锁机制保证服务对象的独占性使用，也就是说在服务执行开始会对服务对象加锁，该锁在服务操作结束之后释放。
回到我们的例子，在Add操作执行过程中，服务端回调客户端操作进行运算结果的显示工作。
如果回调是采用单向操作，回调请求一经发送便会返回，服务操作可以继续得到执行直到操作正常结束。
但是服务采用请求-回复模式的回调，服务端会一直等待回调操作的返回。
而另一方面，当回调操作在客户端正常执行后，回到服务端试图访问服务操作的时候，发现对象被服务操作执行的线程锁住，所以它会等待服务操作的执行完成后将锁释放。
这样，服务操作需要等待回调操作进行正常返回以便执行后续操作，而回调操作只有等待服务操作执行完毕将锁释放才能得以返回，从而形成了死锁。
解决方法就是通过服务行为改变服务执行的并发模式，在下面的代码中我们在服务类型（CalculatorService）中通过ServiceBehaviorAttribute特性的ConcurrencyMode属性将并发模式设为Reentrant或者Multiple均可以解决这个问题。
关于WCF中的并发是一个重要而且复杂的话题，本书的下卷会对其进行单独的介绍。
1:
[ServiceBehavior（ConcurrencyMode=ConcurrencyMode.Reentrant）]
2:
publicclassCalculatorService:
ICalculator
3:
{
4:
//省略实现
5:
}
1:
[ServiceBehavior（ConcurrencyMode=ConcurrencyMode.Multiple）]
2:
publicclassCalculatorService:
ICalculator
3:
{
4:
//省略实现
5:
}
问题3：
如果采用WsDualHttpBinding？
接下来我们来看关于双工服务的第3个问题。
我们这个案例采用NetTcpBinding作为终结点的绑定类型。
现在我们采用基于HTTP的WSDualHttpBinding看看我们的应用能否正常运行。
我们需要做的仅仅是改变服务端和客户端的配置。
1:
xmlversion="1.0"encoding="utf-8"?
>
2:
3:
4:
5:
6:
7:
//127.0.0.1:
9999/CalculatorService"
8:
binding="wsDualHttpBinding"contract="Artech.DuplexServices.Contracts.ICalculator"/>
9:
10:
11:
12:
1:
xmlversion="1.0"encoding="utf-8"?
>
2:
3:
4:
5:
6:
http:
//127.0.0.1:
9999/CorService"binding="wsDualHttpBinding"contract="Artech.DuplexServices.Contracts.ICalculator"/>
7:
8:
9:
如果你的IIS的版本是V6或者V7，你的程序运行将一切正常。
但是如果还在使用XP操作系统，使用IIS5.X，会抛出如图6所示的AddressAlreadyInUseException异常。
图6II5.x+WsDualHttpBinding导致的AddressAlreadyInUseException异常
该异常的出现和不同版本的IIS监听机制有关。
之所以相同的应用在使用基于TCP传输的NetTcpBinding的时候不会出现问题，那是因为HTTP和TCP它们有一个根本的区别，TCP本身就是一个双工模式的传输协议，而HTTP协议本质只能提供单向通信方式。
WSDualHttpBinding通过创建两个单项信道的方式提供双工通信的实现。
对于一个双工通信的WCF服务来说，回调过程本质上也是一种服务调用，是对寄宿于客户端的回调服务的调用。
为了保证回调的正常运行，在客户端创建通道的时候（比如上面的代码通过DuplexChannelFactory的CreateChannel方法的时候），会进行回调服务的寄宿，并指定回调服务的监听地址。
在默认的情况下该监听地址采用这样的格式：
http:
//ho
升级会员 