微软斥巨资打造WCF，在我们看来主要出于下面两个目的：实现其对现有的分布式技术的整合以及顺应SOA的浪潮。在WCF之前，微软已经为了提供了一套完整的基于分布式的技术和产品，这些技术和产品使我们构建一个基于于分布式的互联系统变得异常简单。我们熟悉的技术包括Enterprise Service,.NET Remoting, XML Web Service, MSMQ等等，这些不同的技术和产品为相同的功能提供了不同的实现。对于技术的发展，我觉得“统一”是一个主线：为了让基于Web的开发可以采用我们基于Windows Form的事件驱动、基于控件开发模式，我们有了ASP.NET；为了使具有不同结构的数据（.NET Object, XML, Relational Data etc）采用相同的操作方式，我们有了LINQ。同样，对于一个分布式系统的开发，将不同的分布式技术整合起来，提供一个统一的编程模型是绝对有必要的，WCF就是基于这样的一个目的发展起来的。 

但是，如果你认为WCF仅仅是这些不同的分布式技术简单地组合在一起，那就错了。WCF在对这些技术进行整合的时候，始终有一个指导方针，那就是SOA。SOA，毫无疑问是今后开发互联系统的一个趋势，对于SOA，我想网上充斥着太多的相关的信息，我在这里就不做任何介绍了。SOA的发展离不开一个大家能够一致尊崇的一个标准，而WS-* 就是这个标准。WCF基本上实现了目前所有的WS-* 标准。 

在过去半年之后，我陆陆续续写了一些关于WCF介绍的一些文章，我把它命名为“我的WCF之旅”，目的在于向大家分享我学习WCF这一段旅程。现在把把这个系列做一个阶段性的总结，以飨读者。
[第1篇] 创建一个简单的WCF程序
在Microsoft提出.NET战略以来，先后推出了一系列产品和技术，这些产品和技术为我们在.NET平台下建立企业级的分布式应用提供了很大的 便利。这些技术和产品包括：.NET  Remoting，XML WebSerivce，WSE(2.0,3.0)，Enterprise Service， MSMQ 等等。通过合理利用上面这些分布式的技术完全可以为我们建立的一套适合不同层次需要的分布式构架。但这里面仍然存在一些问题，那就是上面这些技术和产品只能解决某一方面的问题；比如.NET Remoting虽然在.NET平台下是一个很好的依靠，但是考虑到他不能提供不同平台之间的互操作性。另外，这些技术适合用了完全不同的编程方式，使得我们很难从容地从其中一种转移到另一种上来。基于这些原因，　我们需要一套全新的技术整合以上都这些技术，于是我们有了今天的WCF—— Windows Communication Foundation。WCF建立一套框架，是我们通过一致的编程模式，使用不同的技术构建我们的分布式应用。  

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

一开始我们先建立一个简单程序看WCF如何工作。
[第2篇] Endpoint Overview
WCF实际上是构建了一个框架，这个框架实现了在互联系统中各个Application之间如何通信。使得Developers和Architect在构建分布式系统中，无需在考虑如何去实现通信相关的问题，更加关注与系统的业务逻辑本身。而在WCF Infrastructure中，各个Application之间的通信是由Endpoint来实现的。
当我们Host一个WCF Service的时候，我们必须给他定义一个或多个Endpoint，然后service通过这个定义的Endpoint进行监听来自Client端的请求。当我们的Application需要调用这个Service的时候，因为Client 和Service是通过Endpoint的进行通信的，所以我们必须为我们的Application定义Client端的Endpoint。只有当 Client的Endpoint和Service端某个 Endpoint相互匹配（Service端可以为一个Service定义多个Endpoint），Client端的请求才能被Service端监听到。也就是说，我们只有在Client具有一个与Service端完全匹配的Endpoint，我们才能调用这个Service。而这种匹配是比较严格的，比如从匹配Address方面，Client端和Service端的Endpoint Address不仅仅在URI上要完全匹配Service，他们的Headers也需要相互匹配。对于Binding, 一般地，Client需要有一个与Service端完全一样的Binding，他们之间才能通信。 
[第3篇] 在WCF中实现双向通信（Bi-directional Communication） 

作为Remoting中实现双向通信对比，来讨论一下WCF的双向通信。为了使我们能够更好地对比双向通信在 Remoting中和WCF中的实现，我们的Sample采用一样的业务逻辑——调用一个数学计算的远程调用，除了传递相应的操作数之外，我们还传递一个对象，这个对象可以在Server端中回调 (Callback) 把运算结果在Client端显示出来。 

[第4篇] WCF中的序列化（Serialization）
在分布式系统中，一个Application与另一个Application之间进行交互，必然需要携带数据。系统交互完全是应 Message的方式进行的，Message是XML，当然置于Message中的数据也应该是XML（XML Infoset）。如何处理这些交互的数据，我们可能首先想到的就是直接处理XML，我们可以在XML级别通过相关的XML技术——XSD，XPath， XSLT来操作数据。但是要使我们处理后的XML需要和要求的完全一致，这样的工作无疑是非常枯燥乏味而且费时费力的。而我们最擅长的就是使用.NET对象来封装我们的数据。如何使我们创造的对象能够有效地转化成结构化的XML Infoset，就是今天我们要讲的内容——Serialization。
[第5篇] 面向服务架构（SOA）和面向对象编程（OOP）的结合——如何实现Service Contract的重载（Overloading）
给予XML的WCF，并不具有对Overloading的原生支持，但是Overloading是.NET Framework原生支持的。通过Overloading，我们可以使用同名的方法来定义不同的操作，从而使我们的Code显得更加优雅（Elegant）。要是Overloading在WCF中可以使用，WCF必须提供这样的一个Mapping——是被重载的具有相同方法的的方法 Mapping到不同的Operation上。而提供着一个功能的就是ServiceContract。下面我们来结合一个Sample来看如何在WCF 中使用Overloading。
[第6篇] 在Winform Application中调用Duplex Service出现TimeoutException的原因和解决方案

针对一个读者将我的demo从Console Application移植到Windows Form而出现TimeoutException，进一步了解WCF的Messaging。
[第7篇] 面向服务架构（SOA）和面向对象编程（OOP）的结合——如何实现Service Contract的继承 

而在编程模型层面，OO仍然是不可替代的编程模式。所以OO应用于Programming，而SO则更多地运用在Architecture。既然是这样，我们必须有一种调和剂来调和这两个运用不同原理的两个层面的差异，实现他们之间的无缝的结合。比如如何来对继承，多态，重载等基于OO行为的支持。在这方面，WCF为我们提供了很好的解决方案。所以我说WCF不但是为基于SOA的应用架构提供了技术支持，还通过相关的机制完成我们提出的这个“调和剂”的使命。 

在这里我们通过一个Sample来讨论WCF对继承的支持。这个Sample中，我们通过一个WCF Service实现了提供天气信息的功能，或者说，我们实现了一个用作天气预报的WCF Service。
[第8篇] WCF中的Session和Instancing Management
在一个C/S（Client/Service）场景中，Context无关性体现在Client对Service的每次调用都是完全不相关的。但是在有些情况下，我们却希望系统为我们创建一个Session来保留某个Client和Service的进行交互的状态。所以，像Web Service一样，WCF也提供了对Session的支持。对于WCF来说，Client和Service之间的交互都通过Soap Message来实现的，每次交互的过程就是一次简单的Message Exchange。所以从Messaging的角度来讲，WCF的Session就是把某个把相关的Message Exchange纳入同一个Conversation。每个Session用一个Session ID来唯一标识。
真正的逻辑实现是通过调用真正的Service instance中。在一个分布式环境中，我们把通过Client的调用来创建最终的Service Instance的过程叫做Activation。在Remoting中我们有两种Activation方式：Server Activation（Singleton和SingleCall），Client Activation。实际上对WCF也具有相似的Activation。不过WCF不仅仅创建对应的Service Instance，而且还构建相关的Context, 我们把这些统称为Instance Context。不同的Activation方式在WCF中体现为的Instance context model。不同的Instance Context Mode体现为Proxy、Service 调用和Service Instance之间的对应关系。可以这么说，Instance Context Mode决定着不同的Session表现。
[第9篇] 如何在WCF中使用tcpTrace来进行Soap Trace
无论对于Web Service还是WCF，Client和Service之间交互的唯一形式是通过发送和接收Soap Message。在我们对Web Service和WCF进行深入学习的时候，借助一些Soap Trace 工具对Soap Message进行深入剖析是非常有必要的。在这些工具之中，我觉得最好用的就是Microsoft Soap Toolkit中的Soap Trace Utility和tcpTrace。我们今天就来讲讲如何在WCF中使用tcpTrace这个工具。
[第10篇] 如何在WCF进行Exception Handling
在任何Application的开发中，对不可预知的异常进行troubleshooting时，异常处理显得尤为重要。对于一般的.NET系统来说，我们简单地借助try/catch可以很容易地实现这一功能。但是对于一个分布式的环境来说，异常处理就没有那么简单了。按照面向服务的原则，我们把一些可复用的业务逻辑以Service的形式实现，各个Service处于一个自治的环境中，一个Service需要和另一个Service进行交互，只需要获得该Service的描述（Description）就可以了（比如 WSDL，Schema和Strategy）。借助标准的、平台无关的通信构架，各个Service之间通过标准的Soap Message进行交互。Service Description、Standard Communication Infrastructure、Soap Message based Communication促使各Service以松耦合的方式结合在一起。但是由于各个Service是自治的，如果一个Service调用另一个 Service，在服务提供方抛出的Exception必须被封装在Soap Message中，方能被处于另一方的服务的使用者获得、从而进行合理的处理。下面我们结合一个简单的Sample来简单地介绍我们可以通过哪些方式在 WCF中进行Exception Handling。
[第11篇] 再谈WCF的双向通讯-基于Http的双向通讯 V.S. 基于TCP的双向通讯
在一个基于面向服务的分布式环境中，借助一个标准的、平台无关的Communication Infrastructure，各个Service通过SOAP Message实现相互之间的交互。这个交互的过程实际上就是Message Exchange的过程。WCF支持不同形式的Message Exchange，我们把这称之为Message Exchange Pattern（MEP）, 常见的MEP包括: Request/Reply，Request/Forget（One-way）和Duplex。通过采用Duplex MEP，我们可以实现在Service端Callback Client的操作。虽然WCF为我们实现底层的通信细节，使得我们把精力转移到业务逻辑的实现，进行Transport无关的编程，但是对底层 Transport的理解有利于我们根据所处的具体环境选择一个合适的Transport。说到Transport， WCF 经常使用的是以下4个：Http，TCP，Named Pipe，MSMQ。由于不同协议自身的差异，他们对具体MEP的支持方式也会不同，我们今天就来谈谈Http和TCP对Duplex的支持。
[第12篇] 使用MSMQ进行Reliable Messaging
在一个分布式的环境中，我们往往需要根据具体的情况采用不同的方式进行数据的传输。比如在一个Intranet内，我们一般通过TCP进行高效的数据通信；而在一个Internet的环境中，我们则通常使用Http进行跨平台的数据交换。而这些通信方式具有一个显著的特点，那就是他们是基于 Connection的，也就是说，交互双方在进行通信的时候必须保证有一个可用的Connection存在于他们之间。而在某些时候，比如那些使用拨号连接的用户、以及使用便携式计算机的用户，我们不能保证在他们和需要访问的Server之间有一个的可靠的连接，在这种情况下，基于Messaging Queue的连接就显得尤为重要了。我们今天就来谈谈在WCF中如何使用MSMQ。
[第13篇] 创建基于MSMQ的Responsive Service
我们知道MSMQ天生就具有异步的特性，它只能以One-way的MEP（Message Exchange Pattern）进行通信。Client和Service之间采用One-way MEP的话就意味着Client调用Service之后立即返回，它无法获得Service的执行结果，也无法捕捉Service运行的 Exception。
但是在有些场景 中，这是无法容忍的。再拿我在上一篇文章的Order Delivery的例子来说。Client向Service提交了Order，却无法确认该Order是否被Service正确处理，这显然是不能接受的。我们今天就来讨论一下，如何创建一个Responsive Service来解决这个问题：Client不再是对Service的执行情况一无所知，它可以获知Order是否被Service正确处理了。