|
为了使我们能够更好地对比双向通信在Remoting中和WCF中的实现,我们的Sample采用一样的业务逻辑——调用一个数学计算的远程调用,除了传递相应的操作数之外,我们还传递一个对象,这个对象可以在Server端中回调 (Callback) 把运算结果在Client端显示出来。
可以通过下面的URL下载源代码:http://www.cnblogs.com/files/artech/Artech.WCFService.2007.03.02.zip 。
Step1:构建整个Solution的整体构架
整个Solution的架构在WCF体验之旅(1):创建一个简单的WCF程序,这里只作一个简单的介绍。 Artech.WCFService.Contract:Class Library Project,用来保存Contract(Service Contact、Message Contract、Data Contract),之所以把Contract独立出来的原因是考虑到他同时被Server端——Service本身和Service Hosting和Client端使用
Artech.WCFService.Service:Class Library Project,Service的业务逻辑,这个Project引用Artech.WCFService.Contract Project和System.ServiceModel DLL。 Artech.WCFService.Hosting:Console Application,用于以Self-Hosting的方式Host Service。这个Project引用Artech.WCFService.Contract和Artech. Project WCFService.Service。Project和System.ServiceModel DLL。 Artech.WCFService.Client:Console Application,用以模拟现实中的调用Service的Clinet。这个Project引用Artech.WCFService.Contract Project 和System.ServiceModel DLL。 http://localhost/WCFService: Web Site Project,用于模拟如何把Service Host到IIS中。这个Project引用Artech.WCFService.Contract、Artech.WCFService.Service和System.ServiceModel DLL。 Step 2:在Artech.WCFService.Contract定义Calculator Service 和Callback的Contract
1、IDuplexCalculator.cs
2、ICalculatorCallback.cs using System
这里有以下几点需要注意的: 1、在一个分布式的环境中,Client能够调用Service,它必须知道Service的Contract, Contract定义了Service暴露给外界的所有可用的Operation,以及这些Operation的签名(Signature).至于Service中定义的Opertion采用怎样的实现,Client不需要了解。这也是在WCF中把Service Contract与具体的Service Implementation相互分离的一个重要原因——我们把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。
|