八、消息交换模式
WCF服务的实现是基于消息交换的，消息交换模式一共有三种：请求回复模式、单向模式与双工模式。
请求回复模式很好理解，比如int Add(int num1, int num2)这种方法定义就是典型的请求回复模式，请求者发送两个数字，服务回复一个结果数字。如果采用ref或者out参数，那么在xsd当中，ref参数会作为输入和输出参数，out参数只作为输出参数。在WCF当中void返回值的操作契约其实也是请求响应模式的，因为将返回值改为void，影响的只是回复消息的xsd结构，void返回的是一个空xml元素（P141）。
对于一些调用服务记录日志等不要求有响应（即便抛异常也不需要客户端知道）的行为，应该采用单向模式，单向模式只需要在操作契约上添加单向的属性：
[OperationContract(IsOneWay=true] void WriteLog(string msg);
单向模式的操作在对应的wsdl当中没有输出节点，这样的操作必须使用void作为返回值，其参数也不能够使用ref和out参数（P144）。
最后一类是双工模式，双工模式是在服务端定义接口，由客户端实现这个方法，服务端“回调”客户端的这个方法。这里直接扒书加法的例子，因为这个例子又简单又能说明问题，这个例子当中客户端调用服务端的加法，服务端回调客户端的显示函数。
首先定义服务契约：
[ServiceContract(Namespace = "http://www.artech.com/", CallbackContract = typeof(ICalculatorCallback))] public interface ICalculator { [OperationContract(IsOneWay = true)] void Add(double x, double y); }
这里定义了CallbackContract属性，需要传入一个接口的名字，这个接口名字就是回调操作契约，既然在这里指明了它是个契约，就无需服务契约标签了，这里之所以采用单向，是为了防止死锁：
public interface ICalculatorCallback { [OperationContract(IsOneWay = true)] void DisplayResult(double result, double x, double y); }
契约实现如下：
public class CalculatorService : ICalculator { public void Add(double x, double y) { double result = x + y; ICalculatorCallback callback = OperationContext.Current.GetCallbackChannel<ICalculatorCallback>(); callback.DisplayResult(result, x, y); } }
注意实现的第二行，先从当前操作上下文当中拿到了回调信道，之后调用它的回调方法。
客户端实现如下：
public class CalculatorService : ICalculator { public void Add(double x, double y) { double result = x + y; ICalculatorCallback callback = OperationContext.Current.GetCallbackChannel<ICalculatorCallback>(); callback.DisplayResult(result, x, y); } }
首先是一个回调函数的实现类，它实现了回调契约，不过老A的例子有些不雅，这里直接引了契约的dll。
然后是客户端的主体：
class Program { static void Main(string[] args) { InstanceContext callback = new InstanceContext(new CalculatorCallbackService()); using (DuplexChannelFactory<ICalculator> channelFactory = new DuplexChannelFactory<ICalculator>(callback, "calculatorservice")) { ICalculator calculator = channelFactory.CreateChannel(); calculator.Add(1, 2); } Console.Read(); } }
这里首先创建了实例上下文，用它和终结点的配置一起创建了双工信道工厂，之后通过这个工厂创建信道来实现双工调用（这里不雅同上）。
服务端的配置如下：
<?xml version="1.0" encoding="utf-8" ?> <configuration> <system.serviceModel> <behaviors> <serviceBehaviors> <behavior name="exposeExceptionDetail"> <serviceDebug includeExceptionDetailInFaults="true"/> </behavior> </serviceBehaviors> </behaviors> <services> <service name="Artech.WcfServices.Service.CalculatorService" behaviorConfiguration="exposeExceptionDetail"> <endpoint address="http://127.0.0.1:3721/calculatorservice" binding="wsDualHttpBinding" contract="Artech.WcfServices.Service.Interface.ICalculator"/> </service> </services> </system.serviceModel> </configuration>
这里采用了支持双工通信的wsDualHttpBinding绑定，客户端配置如下：
<?xml version="1.0" encoding="utf-8" ?> <configuration> <system.serviceModel> <client> <endpoint name ="calculatorservice" address="http://127.0.0.1:3721/calculatorservice" binding="wsDualHttpBinding" contract="Artech.WcfServices.Service.Interface.ICalculator"/> </client> </system.serviceModel> </configuration>
九、实例与会话
上面了例子里有一个InstanceContext对象， 这个对象就是实例上下文，它是对服务实例的封装，对于一个调用服务的请求，WCF会首先反射服务类型来创建服务实例，并用实例上下文对其进行封装（当然这个实例是带“缓存”的），我们可以配置一定的规则来释放上下文（P396）。
实例上下文分为三种模式：单调模式、会话模式和单例模式。上下文的模式是服务的行为，与客户端无关，以[ServiceBehavior]的InstanceContextMode属性来设置。下面分别来看一看这三种模式。
单调模式，表示每一次调用服务都会创建一个全新的服务实例和上下文，上下文的生命周期与服务调用本身绑定在一起（P402），这种方式能最大限度地发挥资源利用率，避免了资源的闲置和竞争，因此单调模式适合处理大量并发的客户端（P406）。
实现单调模式需要在服务的实现类上增加反射标记：
[ServiceBehavior(InstanceContextMode=InstanceContextMode.PerCall)] public class CalculatorService : ICalculator
从这里也能看出，服务的实现类并不代表业务逻辑，而是位于业务逻辑之上的一个“隔离层”，它显然属于服务层。
单例模式则走了另一个极端，这种模式让整个服务器上自始至终只存在一个上下文，它的反射标签是：
[ServiceBehavior(InstanceContextMode=InstanceContextMode.Single)]
既然只有一个上下文，那么说明同时只能处理一个请求，剩下的请求去排队或者超时。这种模式只能应付很少的客户端，而且仅限于做全局计数这样的操作。如果需要让这个服务异步执行，需要这样写反射标签：
[ServiceBehavior(InstanceContextMode=InstanceContextMode.Single,ConcurrencyMode=ConcurrencyMode.Multiple)]
会话模式则将为每一个服务代理生成一个上下文，会话使服务具有识别客户端的能力，所以一定要选用支持会话的绑定（P420），这种模式适合于客户端数量很少的应用。
这种模式的服务契约上面有SessionMode标签，Required对服务的整个调用必须是一个会话，默认值为Allowed，会在适当时机采用会话模式。服务契约含有IsInitiating和IsTerminating两个属性，在客户端调用服务时，必须先调用IsInitiating为true和IsTerminating为false的，作为起始，最终要调用IsInitiating为false而IsTerminating为true的，作为终结，在两者之间可以调用全为false的操作。如果不这样调用会报错。
[ServiceContract(SessionMode=SessionMode.Required)] public interface ICalculator { [OperationContract(IsInitiating=true, IsTerminating=false)] void Reset(); [OperationContract(IsInitiating = false, IsTerminating = false)] void Add(int num); [OperationContract(IsInitiating = false, IsTerminating = true)] int GetResult(); }
服务实现如下，首先服务行为加上了InstanceContextMode=InstanceContextMode.PerSession，并在服务的内部保存了一个叫做result的非静态变量：
[ServiceBehavior(InstanceContextMode=InstanceContextMode.PerSession)] public class CalculatorService : ICalculator { private int result; public void Reset() { result = 0; } public void Add(int num) { result += num; } public int GetResult() { return result; } }
上面一共提到了InstanceContextMode和SessionMode两个枚举，当采用PerCall单调服务时，不论SessionMode如何，中间结果都不会被保存；采取Single单例服务时，不论SessionMode如何中间结果都会被保存，因为上下文是单例的；采取PerSession会话服务时，只有会话模式为Required和Allowed时，中间结果才会被保存。（P427）一张图说明问题：
十、并发
服务行为的InstanceContextMode表示的是对于一个请求，在服务端搞出几个实例上下文来，那么，ConcurrencyMode则表示同一个服务实例如何同时处理多个并行到来的请求，这些请求可能来自同一个服务代理的并行调用，也可能来自多个服务代理的同时调用。
不过在使用ConcurrencyMode之前，需要先给服务/回调服务加上如下标记：
[ServiceBehavior(UseSynchronizationContext=false)] [CallbackBehavior(UseSynchronizationContext=false)]
这是因为服务操作会自动绑定服务的寄宿线程，为了打破这种线程的亲和性需要禁用同步上下文，否则服务就将是串行执行的，并且是采用同一个线程执行的，就没有什么“并发”可言了。（下P197）
对于并发模式，WCF同样提供了三个可选模式。
Single模式表示一个实例上下文在某时刻只能处理单一请求，也就是说针对某个服务上下文的并发请求会串行执行。
在这种模式下，当并发请求到来时，WCF会对实力上下文进行上锁。
Multiple模式表示一个实力上下文可以同时处理多个请求。
Reentrant（可重入）模式和Single类似，只能同时处理一个请求，然而一旦这个请求处理着一半就去回调客户端了，那么在客户端响应之前，其他的并行请求还是可以被它处理的。举个不雅的例子，男人和老婆亲热着一半，老婆出去拿东西了，这时在外排队的小三就可以进来，等老婆回来了，需要先等小三出来，自己再进去……
在这种模式下，如果需要服务端对客户端进行回调，那么要么采用OneWay的形式回调，要么就要把服务的并发模式设置为非Single，否则会造成死锁的异常，因为“小三”是会占有“原配”的锁的。（下P182）
要让服务支持并发，需要给服务打上服务行为标签，默认值是Single，同样也可以给CallbackBehavior标签设置并发模式：
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Single)]
同样，前面提到的实力上下文模式和并发模式也是有3*3=9种组合的。
对于单调模式（PerCall），由于每个服务调用都使用一个实例上下文，所以根本不存在并发情况，无需设置并发模式，但是对于同一个服务代理，如果需要并行发送请求，则需要手动开启服务代理，否则服务是会串行调用的（P189）。
对于会话模式（PerSession），并发将按照ConcurrencyMode所配置的方式进行处理。
对于单例模式（Single），不论并发请求来自一个还是多个客户端，若ConcurrencyMode是Single则串行，是Multiple则并行，对Reentrant在回调发生时也是并行的（下P195）。
十一、限流
为了防止请求数量过多导致服务器资源耗尽，需要在消息接收和处理系统之间建立一道闸门来限制流量，可以通过服务器端配置给服务添加行为来进行流量控制：
<behavior name="throttlingBehavior"> <serviceThrottling maxConcurrentCalls="16" maxConcurrentInstances="116" maxConcurrentSessions="100"/> </behavior>
三个属性分别为能处理的最大并发消息数量、服务实例上下文最大数量和最大并发会话数量，16、116、100分别是它们的默认值，在WCF4.0后，这些值是针对单个CPU而言的（下P204）。