昨天写了一篇Remoting中如何实现双向通信的文章《[原创].NET Remoting: 如何通过Remoting实现双向通信(Bidirectional Communication) 》,作为对比,今天我们来讨论一下WCF的双向通信。
为了使我们能够更好地对比双向通信在Remoting中和WCF中的实现,我们的Sample采用一样的业务逻辑——调用一个数学计算的远程调用,除了传递相应的操作数之外,我们还传递一个对象,这个对象可以在Server端中回调 (Callback) 把运算结果在Client端显示出来。
可以通过下面的URL下载源代码:
http://www.cnblogs.com/files/artech/Artech.WCFService.2007.03.02.zip
Step1:构建整个Solution的整体构架。
整个Solution的架构在我的之前的Blog有了详细的介绍([原创]我的WCF之旅(1):创建一个简单的WCF程序),这里只作一个简单的介绍。
Step 2 在Artech.WCFService.Contract定义Calculator Service 和Callback的Contract
1.IDuplexCalculator.cs
1.在一个分布式的环境中,Client能够调用Service,它必须知道Service的Contract, Contract定义了Service暴露给外界的所有可用的Operation,以及这些Operation的签名(Signature).至于Service中定义的Opertion采用怎样的实现,Client不需要了解。这也是在WCF中把Service Contract与具体的ServiceImplementation相互分离的一个重要原因——我们把Contract单独提取出来,把他暴露给Client,从而可以避免把过多的暴露业务逻辑的实现。
2.在一个分布式的环境中,Serer端和Client并不是一成不变的,他们是可以相互转化的。提供服务的就是Server,消费Service的就是Client。在这个例子中,当Artech.WCFService.Client调用Host在Artech.WCFService.Hosting中的DuplexCalculatorService(定义在Artech.WCFService.Service中),Artech.WCFService.Client是Client,而Server端的执行环境是Artech.WCFService.Hosting。而当Calculator Service回调(Callback)Client的逻辑把运算结果显示出来时候,因为Callback的逻辑是在Artech.WCFService.Client中执行的,所以Artech.WCFService.Client成了Server,而CalculatorCallbackHandler(定义在Artech.WCFService.Client中)成了真正的Service。
3.我们已经说过Client能够调用Service,它必须知道Service的Contract。所以DuplexCalculatorService能过Callback Artech.WCFService.Client,它也必须知道回调操作的Contract。WCF通过在ServiceContractAttribute中的CallbackContrac参数在制定。
1. 必须把并发模式ConcurrencyMode设置为ConcurencyMode. Reentrant或者ConcurencyMode.Multiple。要弄清种种的原因,我们先来看看在本例中的具体的消息交互的情况(假设我们的调用Duplex Calculator Service 和回调都采用Request/Response的MessageExcahnge Pattern,时间上一般这种情况我们应该采用One-way的ME):
首先Client调用Duplex CalculatorService, Service Request从Client到Service,Service开始执行运算,运算完成后Callback Client将运算结构在Client端显示出来,这个过程中Service向Client发送一个Callback Message,等Client完成Callback操作后,会向Service端发送一个Callback Response(实际上是一个空的Message——以为Callback操作没有返回值),Service收到Callback Response之后,会执行后续的操作,等所有的操作执行完毕,会发送ServiceResponse(这里也是一个空的Message)到Client。
现在我们 来看看为什么在建立DuplexService的时候要把并发模式设为ConcurencyMode. Reentrant或者ConcurencyMode.Multiple。在默认的并发模式下(ConcurencyMode.Single),WCF为了保证其线程安全性(ThreadSafety),在整个调用Service的过程中,InstanceContext会被WCF锁住(Lock)。一本Sample为例,从Client向Service发送Service Request 到手的Server发回的Service Resqonse,整个InstanceContext会在Server端被锁住, 由于在Client执行的Callback操作使用的是同一个InstanceContext, 这样形成了一个死锁(DeadLock)——Calculator Service必须等Callback操作完成之后才能执行后续的操作,而Callback操作必须等待InstanceContext被解锁(Unlock)才能执行,然而InstanceContext却被Calculator Service锁住。
当ConcurencyMode为ConcurencyMode. Reentrant或者ConcurencyMode.Multiple的时候。当Serivice向外调用某个操作(outgoing call)的时候,或者说在向外发送一个Outgoing Message的时候,WCF会解锁(Unlock)InstanceContext。以本例为例,Service 回调Client的时候,原来被锁住的InstanceContext会被解锁。这样Callback操作就可以利用InstanceContext来执行。
2. Service可以通过OperationContext.Current.GetCallbackChannel<T>() 来或者Client在调用Calculator Service时指定的Callback Object。其中T一般被指定为Callback Contract对应的Type。
Step 4 在Artech.WCFService.Hosting中Host Duplex Calculator Service
Step 5 在Artech.WCFService.Client定义Callback对象和调用Duplex Calculator Service
DuplexCalculatorClient.cs
App.config
评论