Welcome

首页 / 软件开发 / .NET编程技术 / 我的WCF之旅(1):创建一个简单的WCF程序

我的WCF之旅(1):创建一个简单的WCF程序2010-12-27 cnblogs artech写在前面

在Microsoft提出.NET战略以来, 先后推出了一系列产品和技术, 这些产品和技术为我们在.NET平台下建立企业级的分布式应用提供了很大的 便利。这些技术和产品包括:.NET Remoting,XML WebSerivce,WSE(2.0,3.0),Enterprise Service, MSMQ ......

我们知道,和一个相对独立的应用不同,我们开发一个分布式应用, 尤其是开发一个企业级的分布式应用, 我们需要考虑较多的东西。比如我们要考虑数据在不同的应用之间传递时采取什么样的机制, 这种数据传递是否是安全的,可靠的;如何在分布式的环境下进行异常处理;如何把分别在 不同应用中执行的操作纳入同一个事务……

对于我们上面提到的这些 问题, 这些都是开发分布式应用考虑的典型的问题。值得庆幸的是,Microsoft开发的分布式的产品能够部分的解决这些问题。.NET Remoting 为我们在.NET平台下提供了非常好的解决方案(我个人认为,.NET Remoting是.NET平台下最为成熟的分布式技术。比如相较于另一个使用更为广泛的技术XML Web Service,它具有一些自己独特的特性:可以使用不同的传输层协议进行通信——Http & TCP;可以使用不同的消息编码方式——Bianry & Text (XML);可以寄宿到IIS和任何一种托管的应用下 ——Console Application 、WinForm Application、 Windows Service……;Server端可以通过双向通信回调(Callback)客户端的操作;……)XMLWeb Service为使我们实现跨平台的系统能够集成显得如此简单。随着技术的不断发展,相关的技术规范(WS-* Specification)不断完善, XML Web Service现在已经成为使用最为广泛的分布式技术了。XML Web Service能够得到如此广泛的推广,这得得益于Microsoft先后两次推出的Web Service Enhancement (WSE 2.0 、WSE 3.0)。如果没有WSE, 单纯的asmx下的如此的担保和不可靠。WSE为Web Service解决了几大难题:Security、Reliable Messaging、transaction Handling以及大数据的有效传输。 MSMQ作为一种简单而有效的机制为不同应用之间数据的传递提供了保障。

其实,通过合理利用上面这些分布式的技术完全可以为我们建立的一套适合不同层次需要的分布式构架。但这里面仍然存在一些问题,那就是上面这些技术和产品只能解决某一方面的问题; 比如.NET Remoting虽然在.NET平台下是一个很好的依靠, 但是考虑到他不能提供不同平台之间的互操作性。另外,这些技术适合用了完全不同的编程方式,使得我们很难从容地从其中一种转移到另一种上来。基于这些原因, 我们需要一套全新的技术整合以上都这些技术, 于是我们有了今天的WCF——Windows Communication Foundation。WCF建立一套框架,是我们通过一致的编程模式,使用不同的技术构建我们的分布式应用。

虽然很早开始接触WCF,但所学的总是零零碎碎。现在开始系统地研究WCF,希望与大家一同分享我的一些所得, 同时希望能通过这样的一个机会与大家一些探讨WCF,不对的地方希望大家指正。

一开始我们先建立一个简单程序看WCF如何工作:

1 建立整个应用的简单构架

整个构架如图所示,这个Solution由5个Project组成:Artech.WCFService.Contract; Artech.WCFService.Service;Artech.WCFService.Hosting;Artech.WCFService.Client;http://localhost/WCFService。

Artech.WCFService.Contract: Class Library Project,用来保存Contract(Service Contact、Message Contract、Data Contract), 之所以把Contract独立出来的原因是考虑到他同时被Server端——Service本身和Service Hosting和Client端使用。(现在很多的参考书,包括MSDN都使用ServiceModel Metadata Utility Tool (Svcutil.exe)这样的一个工具来访问Service的Metadata Endpoint来生成我们的客户段代码,这些代码就包括Service Contract(一般是一个Interface),实现了这个Contract的Proxy Class(一个集成自System.ServiceModel.CientBase的一个Class)和相应的Configuration。 这个工具确实给我提供了很大的方便。但我不推荐使用这样的方法(我天生不倾向对于这些代码生成器),因为我觉得, 在Contract可得的情况下-比如Service和Client都是自己开发,让Service和Client实现的Contract是同一个Contract能够保证一致性。这个Project引用System.ServiceModel DLL。

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。