WCF体验之旅（1）：创建一个简单的WCF程序(1)

【引自张逸的博客】在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)客户端的操作；……）XML Web 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。

图1

◆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。

2、创建Service Contract

在这个例子中我们建立一个简单的案例，做一个计算器，假设我们只要求他做简单的加法运算就可以了。在Artech.WCFService.Contract添加一个interface，名称叫做ICalculator。

using System.Collections.Generic;
using System.Text;
using System.ServiceModel;
namespace Artech.WCFService.Contract
{
[ServiceContract]
public interface ICalculator
{
[OperationContract]
double Add(double x, double y);
}
}

使一个Interface成为Service Contract的方法很简单，就是把ServiceContractAttribute应用到这个interface上，并在代表单个Operation的方法上应用OperationContractAttribute。这个使用Custom Attribute的编程模式被称为声明式的编程（Declarative）方式，　他在.NET Framework 1.1以前用到的地方还不是太多，在.NET Framework 2.0，尤其是NET Framework 3.0中，这种方式已经变得随处可见了。

我们可以把Contract定义成一个Interface，也可以把它定义到一个Class中——这个Class中既包涵Service本身又作为一个Contract而存在。但我推荐使用第一种方法——Serive和Contract相分离。

在WCF中，Contract的功能实际上就定义一个Service包含哪些可用的Operation，以及的每个Opertaion的方法签名。从消息交换（Message Exchange）的角度讲，Contract定义了调用相应的Serive采取的消息交换的模式（Message Exchange Pattern - MEP），我们经常使用的MEP包括三种：Oneway，　Request/Response，和Duplex。因为调用Service的过程实际就是消息交换的过程，以常见的Request/Response为例。Client调用某个方面远程访问Service，所有的输入参数被封装到Request Soap Message并被发送到Service端，Service端监听到这个Soap Request，创建相应的Service Object并调用相关的操作，最后将Result（这可以是Return Value，Reference Parameter和Output Parameter）封装成Soap Message发送回Client端。这里需要注意，如果采用的是Request/Response的模式，即使相应的操作没有Return Value，Reference Parameter和Output Parameter（它被标记为void），Service仍然会返回一个空的Soap Message给Client端。