我的WCF之旅（8）：WCF中的Session和Instancing Management

WCF中的Session

我们知道，WCF是MS基于SOA建立的一套在分布式环境中各个相对独立的Application进行Communication的构架。他实现了最新的基于WS-*规范。按照SOA的原则，相对独自的业务逻辑以service的形式封装，调用者通过Messaging的方式调用Service。对于承载着某个业务功能的实现的Service应该具有Context无关性、甚至是Solution无关性，也就是说个构成Service的operation不应该绑定到具体的调用上下文，对于任何调用，具有什么样的输入，就会有与之对应的输出。因为SOA的一个最大的目标就是尽可能地实现重用，只有具有Context无关性/Solution无关性，Service才能实现最大限度的重用。此外Service的Context无关性/Solution无关性还促进了另一个重要的面向服务的特征的实现：可组合性，把若干相关细粒度的Service封装成一个整体业务流程的Service。

在一个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来唯一标识。

WCF中的Session和ASP.NET的Session

在WCF中，Session属于Service Contract的范畴，是一个相对抽象的概念，并在Service Contract定义中通过SessionModel参数来实现。他具有以下几个重要特征：

Session的创建和结束都有来自Client端的调用来实现

我们知道，在WCF中Client通过创建的Proxy对象来和service的交互，在默认的支持Session的情况下，Session和具体的Proxy对象绑定在一起，当Client通过调用Proxy的某个方法来访问Service的时候，Session被初始化，直到Proxy被关闭，Session被终止，我们可以通过下面两种方式来关闭Proxy：

调用System.ServiceModel. ICommunicationObject对象（我们一般通过System.ServiceModel. ChannelFactory对象的CreateChannel方法获得）的Close方法。
调用System.ServiceModel. ClientBase对象（我们一半通过继承它来实现我们为某个特定的Service创建Proxy类）的Close方法。

此外，我们也可以人为地指定通过调用Service的某个operation来初始化、或者终止Session。我们一般通过System.ServiceModel. OperationContractAttribute的IsInitiating和IsTerminating参数来指定初始化和终止Session的Operation。

WCF保证处于某个Session中传递的Message按照他发送的次序被接收
WCF并没有为Session的支持而保存相关的状态数据。

说道WCF中的Session，我们很自然地联想到ASP.NET中的Session。实际上，他们之间具有很大的差异：

ASP.NET的Session总是在Server端初始化的。
ASP.NET并不提供Ordered Message Delivery的担保。
ASP.NET是通过在Serer以某种方式保存State来实现对Session的支持的，比如保存在Web Server的内存中，保存在State Server甚至是SQL Server中。

WCF中的Session的实现和Instancing Management

在上面我们说了，虽然WCF支持Session，但是并没有相关的状态信息被保存在某种介质中。WCF是通过怎样的方式来支持Session的呢？这就是我们本节要讲的Instancing Management。

对于Client来说，它实际上不能和Service进行直接交互，它只能通过客户端创建的Proxy来间接地实现和service的交互。Session的表现体现在以下两种方式：

Session的周期和Proxy的周期绑定，这种方式体现为默认的Session支持。
Session的周期绑定到开始和终止Session的方法调用之间的时间内，这种方式体现在我们在定义Operation Contract时通过IsInitiating和IsTerminating显式指定开始和终止Session的Operatoin。

我们很清楚，真正的逻辑实现是通过调用真正的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表现。在WCF中，支持以下3中不同级别的Instance Context Mode：

PerCall：WCF为每个Serivce调用创建一个Service Instance，调用完成后回收该Instance。这种方式和Remoting中的SingleCall相似。
PerSession：在Session期间的所有Service调用绑定到某一个Service Instance，Session被终止后，Service Instance被回收。所以在Session结束后使用同一个Proxy进行调用，会抛出Exception。这种方式和Remoting中的CAO相似。
Singleton：这种方式和Remoting的Singelton相似。不过它的激活方式又有点特别。当为对应的Service type进行Host的时候，与之对应的Service Instance就被创建出来，此后所有的Service调用都被forward到该Instance。

WCF的默认的Instance Context Mode为PerSession，但是对于是否对Session的支持，Instancing的机制有所不同。如果通过以下的方式定义ServiceContract使之不支持Session，或者使用不支持Session的Binding（顺便说一下，Session的支持是通过建立Sessionful Channel来实现的，但是并不是所有的Binding都支持Session，比如BasicHttpBinding就不支持Session），WCF实际上会为每个Service调用创建一个Service Instance，这实质上就是PerCall的Instance Context Mode，但我为什么会说默认的是PerSession呢？我个人觉得我们可以这样地来看看Session：Session按照本意就是Client和Service之间建立的一个持续的会话状态，不过这个Session状态的持续时间有长有短，可以和Client的生命周期一样，也可以存在于某两个特定的Operation调用之间，最短的则可以看成是每次Service的调用，所以按照我的观点，PerCall也可以看成是一种特殊的Session（我知道会有很多人不认同我的这种看法。）

[ServiceContract(SessionMode = SessionMode.NotAllowed)]

Simple

接下来我们来看看一个简单的Sample，相信大家会对Session和Instancing Management会有一个深入的认识。这个Sample沿用我们Calculator的例子，Solution的结构如下，4个Project分别用于定义SeviceContract、Service Implementation、Hosting和Client。

补充：综合编程 , 其他综合 ,