使用web服务的每一种主要语言或平台都把与自身相关的特性集合在一个名字下，java开源开发人员使用axis，php阵营则使用pear，而基于微软工具的开发则使用wcf (windows communication foundation).

　　使用web服务的每一种主要语言或平台都把与自身相关的特性集合在一个名字下，java开源开发人员使用axis，php阵营则使用pear，而基于微软工具的开发则使用wcf (windows communication foundation).

　　wcf曾被称为indigo，实际上不只是一个web服务项目，它的目的是要微所有的分布式系统技术提供一种保护伞，其核心是一套面向服务的api。

　　现在，.net框架是利用微软工具开发应用程序的最先进的方法。它已经为解决一系列c/s交互场景提供了办法。

　　比如，asp.net web services(asmx)提供了通过web服务开发应用程序接口的最简单的形式，而.net remoting则是使.net和.net应用程序交互的核心。

　　但在另一方面，很多系统不是构建得超出了.net框架上下文的范围，就是得通过其它办法来进行特殊处理。

　　对于需要web服务标准支持(ws-*说明书)的那些应用程序，微软则使用了web services enhancements (wse)。而对于那些遗留系统，经常用到的分布式交互技术则是用于异步通讯的microsoft messaging、com+以及microsoft's host integration server。

　　你应该注意到所有这些场景都有一个相同的主题:分布式应用的通信。但是，很显然，每一种技术都用到不同的方法或技术来解决这个问题。而wcf背后的初衷就是针对应用程序中用到的所有通信接口为开发人员提供一步到位的方法。

　　wcf是对.net技术的一个补充，而非现在.net框架的替代品。但当你仔细思考把微软的分布式技术都统一到同一个屋檐下会达到怎样的效果后，你就会领悟到为什么说wcf/indigo是简化创建面向服务设计的重要组成部分，以及它为什么是未来微软的操作系统vista的一个基础。

　　在使用wcf时，你不仅只需要懂得一种方法就足以把很多应用作为服务暴露出来，而且你还可以用同样的方法来对付当前技术本身的底层细节。

　　用wcf服务使能化应用程序的真正概念并非与那些用来运行web服务的概念不同，真正的不同之处我们在下文中会体现出来。

　　假设你已经有一个提供天气预报的应用程序。不管使用的什么接口，浏览器html、无线wml还是web服务soap/wsdl，在结构内部都会有一个interface和class来为获得天气预报提供必要的钩子程序。下面的示例显示了wcf中这个interface和class:

listing 1.1 wcf interface

// interface using wcf
using system.servicemodel;

[servicecontract]
interface iweather
{
 [operationcontract]
 double celsius(string city, int time);

 [operationcontract]
 double farenheit(string city, int time);
}

　　第一个声明表明了wcf的命名空间――using system.servicemodel――而接口和方法声明则描述了应用的行为。这是直接的.net语法，毋庸多言。而另一方面，带括号的声明是我们在.net中熟知的属性，它是wcf的核心。

　　[servicecontract]表明该接口会形成wcf的可服务应用的基础，而在每一个方法前面的[operationcontract]则说明该方法会暴露成一个服务。

　　以服务的观点，[operationcontract]被用来标明哪一个方法会最终成为wsdl描述的操作。这些wcf属性是最基础的，但是你可以指定一个完整的与服务相关的行为，并在最后使它们成为一种服务合约。例如，对于传统支持，一个[operationbehavior(requiretransaction=true, autocompletetransaction=true)]的属性依然可以使用。

　　下面，我们可以使用这个接口，只要设计一个下面这样的实现类即可。

　　listing 1.2 class using wcf interface

// implementation class
class weather : iweather
{
 public double celsius(string city, int time)
 {                           
   // perform logic, return temperature for specific city and time
 }
     
 public double farenheit(string city, int time)
 {
   // perform logic, return temperature for specific city and time
 }

 // private method
 private double farenheittocelsius(double degrees)
 {
   // perform logic, return temperature in celsius
 } 

 // private method
 private double celsiustpfarenheit(double degrees)
 {
   // perform logic, return temperature in farenheit
 } 

}

　　在深入了解实现类使用wcf接口的细节之前，你应该意识到使用该interface/class的组合设计是很简单使用的oo实践。使用wcf和它的属性能尽可能简单的与真实的类直接合成。

　　回到实现类，代码与典型的.net类差别不大，但该类是继承了wcf接口，wcf属性对每个实现方法都会产生影响。

　　现在，再转到实际部署这些代码的地方。wcf可以用两种方法部署，或者通过windows activation service (was)，它与在iis中部署asp.net web services (asmx) i非常类似，而另一种方法则是直接在需要使用服务的任何内部应用类中部署。

　　为了简单，我们采用与asp.net类似的方法。在这种方法中，一个wcf服务可以被整个替换为.svc文件与asp.net web services .asmx文件一起部署，或者wcf类为dll程序集使用代码后类型声明，例如<%@service language=c# class="weather"%>

　　最后，wcf服务需要被绑定到一个特定的地址，这是需要在asp.net应用程序的web.config文件中指定的。listing 1.3显示了该文件:

　　listing 1.3 web.config for wcf service

<?xml version="1.0" encoding="utf-8" ?>
<configuration xmlns="http://schemas.microsoft.com/.netconfiguration/v2.0">
   <system.servicemodel>
      <services>
         <service servicetype="selfhostedservice.weather">
            <endpoint address="http://localhost:8080/weather"
                     bindingsectionname="basicprofilebinding"
                     contracttype="selfhostedservice.iweather"/>
         </service>
      </services>
   </system.servicemodel>
</configuration>

　　通过访问在web.config文件中指定的最终地址，你可以获得由wcf服务提供的天气数据。

　　用类似的办法，对于客户端，wcf也可以让我们从服务合约生成必要的.net骨架来创建一个消费者应用程序，不过我们把具体细节留在另外的文章中讲解。

　　至此，我们来总结一下对windows communication framework的看法，即未来几年在用微软技术构建面向服务的应用程序时，它一定会成为主流的解决方案。