`
varsoft
  • 浏览: 2430290 次
  • 性别: Icon_minigender_1
  • 来自: 上海
文章分类
社区版块
存档分类
最新评论

[原创]WCF后续之旅(3): WCF Service Mode Layer 的中枢—Dispatcher

阅读更多

在本系列的第一部分第二部分中,我们对WCF的channel layer进行了深入的讨论。我们接下来继续讨论WCF的service mode layer。本篇文章着重介绍service 端的ServiceMode。写作此篇文章旨在达到以下两个目的:

  • 希望读者对ServiceMode有一个大致的了解,结合前面介绍的channel layer的相关知识,帮助读者了解WCF的整个实现机制和执行的流程。
  • 介绍ServiceMode涉及到的绝大部分extension point,让读者在具体的项目开发中能够根据实际的需要灵活、自由地对WCF进行扩展。

较之channel layer,ServiceMode要复杂得多,其内部隐藏了太多MS没有公布出来的实现细节。由于到目前为止,还不曾出现过关于此方面详细的官方介绍,以下所有的介绍来源于以下几个方面:

  • 对MSDN的查阅
  • 对相关WCF著作的查阅,比如《Programming WCF Service》、《Inside Microsoft Windows Communication Foundation》等等。
  • 通过Reflector反射出来的代码的理解,本片文章的绝大部分内容来源于此。

所以,对于文中的某些表述,由于个人能力所限,可能有失偏颇。如有不当之处,还望各位朋友及时指正。

1. Dispatcher为我们做了什么?

由于应用WCF的是一个分布式环境,按照所处的环境的不同,可以将ServiceMode分成client端的ServiceMode和service端的ServiceMode。就其实现的复杂度而言,service端的ServiceMode要比client端的复杂很多。对于Service端来讲,WCF的ServiceMode需要解决的是:

  • 如何根据不同的listening URI创建ChannelListener并进行监听;
  • 当request抵达,如何创建适合的Channel接收request message;
  • 如何将Message分发到对应的Endpoint进行处理;
  • 如何进一步将Message分发到对应的service instance
  • 以及如何进一步地分发的具体的service instance的匹配的method call

由于“分发(Dispatch)”是其根本的功能和任务,所以Dispatcher是整个Service端ServiceMode的核心。正如标题所述,Dispatcher是整个WCF service mode layer的中枢,本篇文章讲着重围绕着Dispatcher来展开介绍。

Dispatcher并不是指的某一个对象,而是指完成整个dispatch功能的一组相关对象的总称。这包括3个核心的对象:ChannelListenerChannelDispatcherEndpointDispatcher,和一些辅助的对象。

ChannelListener在本系列的前面两个部分已经进行了详细的介绍,我们知道其主要功能在于:绑定到一个固定的Listening URI,监听来自外界的请求。一旦请求抵达,创建对应的Channel接收Request message。但是我们的业务逻辑定义在一个个的service类中,所以WCF必须提供一种机制通过我们接收到的message去激活对应service instance并调用对应的方法。对于的激活(Activation)包含两种:创建一个新的service instance(PerCall instancing mode)和复用一个已经存在的service Instance(PerSession和Singleton instancing mode)。ChannelDispatcher的核心功能就是提供了这样一种功能(尽管它还提供了其他的有用的功能,为了是内容不至于太散,在这里就不再作相关的介绍)。ChannelDispatcher通常和一个ChannelListener关联,而ChannelListener又对应着一个固定的listening URI。对于一个被host的service来讲,可能定义了不同的listening address,所以一个service一般对应着一到多个ChannelDispatcher。更进一步说,当我们host一个service的时候,WCF会为之创建一个ServiceHostBase对象(ServiceHost或者是你自定义的继承自ServiceHostBase的对象),所以一个ServiceHostBase对象对应一到多个ChannelDispatcher对象

对于接收到的request message,ChannelDispatcher不会自己对其进行处理,而是将其分发到与之相匹配为的EndpointDispatcher上,所以处理message的的绝大部分功能实际上是由EndpointDispatcher来实现的。对于同一个listening address,我们一般会不止一个endpoint,所以一个ChannelDispatcher拥有不止一个EndpointDispatcher。对于EndpointDispatcher来讲,有一个绝对绝对值得特别介绍的是DispatchRumtime。DispatchRumtime和一个特定的EndpointDispatcher匹配,通过定制DispatchRumtime,你可以很容易地按照你具体的需要改变整个service或者某个具体的Operation相关的运行时行为。对于WCF一门重要的课题, WCF extensions来讲,你的绝大部分BehaviorExtesionElment,都是通过具体的Behavior对DispatchRumtime进行定制而实现的

2. WCF Dispatching System的执行流程

有了上面对于ChannelDispatcher和ChannelDispatcher的了解,我们来简单介绍一下WCF的Dispatching System得执行流程:

Step 1:ServiceHost和ServiceDescription的创建

WCF service不能独立地执行,必须Host到一个可执行程序中,可以使一般的managed application、IIS、WAS和Windows service等等。Hosting的工作一般分两个步骤,为service创建ServiceHost打开ServiceHost开始监听请求

注:确实地讲,完成Hosting的不一定是ServiceHost,任何继承自SerivceHostBase的都可以用于service的hosting。ServiceHost继承自ServiceHostBase,我们一般用它来完成Hosting的工作;为了简单,这里的ServiceHost可以看成是任何继承自己ServiceHostBase的Service Host type。

ServiceHost提供了两个重载的constructor:

public ServiceHost(object singletonInstance, params Uri[] baseAddresses); 
public ServiceHost(Type serviceType, params Uri[] baseAddresses);

第一个constructor接收一个service instance,采用Singleton的instancing mode进行Host;而另一个传入service type进行hosting,instancing mode有ServiceBehavior的InstanceContextMode决定。

构造serviceHost,最重要的任务是通过reflection或者解析configuration的方式创建ServiceDescription。这个创建出来的ServiceDescition将是所有后续工作的根本依据。我们来简单了解一下ServiceDescription的属性定义:

public class ServiceDescription
{
// Properties
public KeyedByTypeCollection<IServiceBehavior> Behaviors { get; }
public string ConfigurationName { get; set; }
public ServiceEndpointCollection Endpoints { get; }
public string Name { get; set; }
public string Namespace { get; set; }
public Type ServiceType { get; set; }
}

这里最重要的两个属性是Behaviors 和Endpoints:

  • Behaviors :和service相关的所有service behavior的集合,这里的service behavior仅包含你通过ServiceBehaviorAttribute指定的service behavior,也包含一些自定义的custom service behavior(自定义service behavior在WCF extension中十分常见)。由于该属性的类型是KeyedByTypeCollection<IServiceBehavior> ,所以很容易通过具体的service behavior type得到对应的behavior。
  • Endpoints:service相关联的所有ServiceEndpoint的集合。下面是ServiceEndpoint的属性定义:
public class ServiceEndpoint
{
public EndpointAddress Address { get; set; }
public KeyedByTypeCollection<IEndpointBehavior> Behaviors { get; }
public Binding Binding { get; set; }
public ContractDescription Contract { get; }
public Uri ListenUri { get; set; }
public ListenUriMode ListenUriMode { get; set; }
public string Name { get; set; }
}

除了构成Endpoint的ABC:AddressBindingContract之外还有重要的属性Behaviors,一个包含所有EndpointBehavior的集合。ServiceBehavior、EndpointBehavior、ContractBehavior以及OperationBehavior是我们用户WCF extension的“四大”behavior。这里再额外提一下Contract对应的类型ContractDescription 的定义:

public class ContractDescription
{
public KeyedByTypeCollection<IContractBehavior> Behaviors { get; }
public Type CallbackContractType { get; set; }
public string ConfigurationName { get; set; }
public Type ContractType { get; set; }
public bool HasProtectionLevel { get; }
public string Name { get; set; }
public string Namespace { get; set; }
public OperationDescriptionCollection Operations { get; }
public ProtectionLevel ProtectionLevel { get; set; }
public SessionMode SessionMode { get; set; }
}
  • Behaviors :所有ContractBehavior的集合。
  • ContractType :Contract的类型,返回标注了ServiceContractAttribute的class对应的type,可能是interface也可能是class。
  • Operations :Contract中所有Operation的描述,每个元素与应用了OperationAttribute的method一一匹配。 OperationDescriptionCollection 的定义也相当重要,至于具体的定义,可以参考MSDN,限于篇幅,在这里就不多作介绍了。
  • SessionMode:Session的模式:Allowed、Required、NotAllowed。

注:当通过实例化ServiceHost创建的ServiceDescription可以通过SeriviceHost对象的Description属性获得,你还可以代码的方式对其进行添加、删除和修改。

Step 2:ServiceHost.Open()和Channel Listener & ChannelDipatcher的创建

当调用ServiceHost instance的Open方法后。WCF遍历ServiceHost的Endpoints属性中的每个ServiceEndpoint,对于每个不同的不同的ListenUri和ListenUriMode的不同,通过ServiceEndpoint对象的Binding创建ChennelListener(关于通过Binding创建ChannelListener本系列的第一部分作了详细的介绍)。举个例子,假设一个ServiceHost有4个Endpoint:

Endpoint Listen URI Listen URI Mode
endpoint I http://artech/serviceA Explicit
endpoint II http://artech/serviceA Explicit
endpoint III http://artech/serviceA Unique
endpoint IV http://artech/serviceB Explicit

注:上面的例子仅仅是用于说明endpoint和Channel Listener的关系,和真实的情况有些出入。

那么此service最终的listening address包含3个,endpoint I和endpointII具有一样的listening address,其他的都不一样。那么会分别利用3个ServiceEndpoint的Binding属性获取对应的Binding对象,调用Binding对象的BuildChannelListener方法创建3个ChannelListener。然后将此ChannelListener传入ChannelDispatcher的构造函数,创建3个对应的ChannelDispatcher对象。对于每个ChannelDispatcher,由于有不止一个的Endpoint,比如其中一个ChannelDispatcher就具有endpoint I和endpoint II两个ServiceEndpoint,所以一个ChannelDispatcher可能有不止一个EndpointDispatcher。在创建EndpointDispatcher的同时,另一个非常重要的对象一并被创建出来:DispatchRuntime。DispatchRuntime反应了绝大部分ChannelDispatcher和EndpointDispatcher运行时的信息。通过对DispatchRuntime的定制,你可以很方面地改变整个Dispatching的行为。

Step 3:请求接听和消息接收

ChannelDispatcher创建之后,其Open方法会调用。随之ChannelDispatcher对应的ChannelListener会被打开,并绑定到对应的listening URI进行监听来自外界的request。当request抵达并被检测到,ChannelListener会调用AcceptChannel方法创建一个适合的Channel,该Channel将用作接收request message。

Step 4:获取匹配的EndpointDispatcher,并分发request message

当request message被成功接收,ChannelDispatcher本身并不负责处理该message,而是将其分发到匹配的EndpointDispatcher。我们在上面已经说过了,一个ChannelDispatcher可以同时拥有不止一个EndpointDispatcher,但是最终接收并处理message的EndpointDispatcher却只能有一个。ChannelDispatcher如何选择所需的EndpointDispatcher呢?

具体实现是这样的:每个EndpointDispatcher都定义了两个特殊的属性:AddressFilterContractFilter,它们的类型都是:System.ServiceModel.Dispatcher.MessageFilter

public abstract class MessageFilter
{
// Methods
protected MessageFilter();
protected internal virtual IMessageFilterTable<FilterData> CreateFilterTable<FilterData>();
public abstract bool Match(Message message);
public abstract bool Match(MessageBuffer buffer);
}

MessageFilter定义了两个Match重载,所以子类实现该重载实现自定义的匹配规则。在具体实现的时候,会解析request message或者MessageBuffer (message 的memory buffer表示)(一般是message header),来判断该request是否和对应的EndpointDispatcher相互匹配。

WCF为我们提供了一下6类Message Filter:

  • System.ServiceModel.Dispatcher.ActionMessageFilter:通过message Action header进行匹配。
  • System.ServiceModel.Dispatcher.MatchAllMessageFilter:匹配所有的message,也就是直接返回true。
  • System.ServiceModel.Dispatcher.EndpointAddressMessageFilter:根据message的To header 进行匹配。
  • System.ServiceModel.Dispatcher.MatchNoneMessageFilter:不会和任何的message匹配,也就是直接返回false。
  • System.ServiceModel.Dispatcher.PrefixEndpointAddressMessageFilter:和EndpointAddressMessageFilter相似,不过这次匹配的不是整个message的To header ,而是To header 的前缀
  • System.ServiceModel.Dispatcher.XPathMessageFilter:基于Xpath expression的匹配方式。

那么EndpointDispatcher的ContractFilter和AddressFilter采用的又是那种类型的MessageFilter呢?通过Reflector看看EndpointDispatcher的构造函数就会知道,AddressFilter采用的是EndpointAddressMessageFilter,而ContractFilter采用的则是MatchAllMessageFilter。也就是说,当ChannelDispather在为接收到的request message选择合适的EndpointDispatcher的时候,会根据message To header上的address进行匹配。

你也许会问,如何有不止一个EndpointDispatcher满足条件怎么办呢?答案是ChannelDispatcher会选择一个Filter优先级最高的一个,该优先级由EndpointDispather的FilterPriority属性来决定

Step 5:InstanceContext的获取

在WCF infrastructure中, InstanceContext是以一个很重要的概念。InstanceContext是什么呢?简言之,InstanceContext就是对service instance的封装(service instance wrapper),对于每一个service instance来讲,WCF都会通过一些context信息对其进行包装。这些contextual information存在的目的在于让不同的request关联到对应的service instance上。对于不同的Instancing Mode(PerCall、PerSession和Singleton),我们往往具有不同的InstanceContext。而对于PerSession方式的instancing mode,InstanceContext显得尤为重要,原因很简单,我们必须保证来自同一个Session的request被分发到同一个service instance,不然很难维护其session的信息

InstanceContext的获取通过InstanceContextProvider来实现。在WCF中所有的InstanceContextProvider均实现了System.ServiceModel.Dispatcher.IInstanceContextProvider interface。

public interface IInstanceContextProvider
{
// Methods
InstanceContext GetExistingInstanceContext(Message message, IContextChannel channel);
void InitializeInstanceContext(InstanceContext instanceContext, Message message, IContextChannel channel);
bool IsIdle(InstanceContext instanceContext);
void NotifyIdle(InstanceContextIdleCallback callback, InstanceContext instanceContext);
}
  • GetExistingInstanceContext:当message由ChannelDispather交付到EndpointDispatcher的时候,该方法会被调用,试图获取一个已经存在的InstanceContext。比如PerSession模式下,如何sesssion已经开始,那个会或其绑定到当前session的InstanceContext,否则return null;对于Singleton模式,由于使用一个service instance来处理所有的request,所以一旦service instance被创建,后续的request都将返回同一个InstanceContext,否则return null;而对于PerCall来说,由于对于每个request来说,都需要创建一个新的service instance来处理,所以它永远是return null。
  • InitializeInstanceContext:如何GetExistingInstanceContext返回null,将通过这个方法来创建和初始化一个新的InstanceContext.
  • IsIdle:当所有的InstanceContext操作完成以后,该方法会被调用,返回的bool类型的结果将用作是否对InstanceContext进行清理和回收的依据。如何你不希望对创建的InstanceContext进行回收,那么你可以将此方法返回为false。比如Singleton和PerSession模式下就直接return false;而PerCall则return true。
  • NotifyIdle:当对InstanceContext进行真正的清理和回收时,此方法会被回调。

具体的做法是:通过DispatchRuntime的InstanceContextProvider属性获取与instancing mode相匹配的InstanceContextProvider对象,调用GetExistingInstanceContext方法获取existing InstanceContext。

和3种instancing mode向匹配, WCF定义了3种InstanceContextProvider:

  • System.ServiceModel.Dispatcher.PerCallInstanceContextProvider
  • System.ServiceModel.Dispatcher.PerSessionInstanceContextProvider
  • System.ServiceModel.Dispatcher.SingletonInstanceContextProvider

Step 6:选择DispatchOperation

每个request message是基于某个固定operation的,因为它反映的是基于某个service operation的调用。Dispatching system通过DispatchOperation来表示一个具体的service operation。DispatchRuntime定义了一个Operations属性,该属性表示所有DispatchOperation的集合。现在的问题是如何从众多的DispatchOperation选择一个和当前request message向匹配的DispatchOperation。

DispatchOperation的选择通过DispatchRuntime的另一个属性OperationSelector来完成。OperationSelector是一个System.ServiceModel.Dispatcher.IDispatchOperationSelector对象:

public interface IDispatchOperationSelector
{
string SelectOperation(ref Message message);
}

对DispatchOperation的选择既是同调用DispatchOperationSelector的SelectOperation方法,通过解析request message得到最终operation的名称,根据获得的这个名称在DispatchRuntime的Operations集合中找到对应的DispatchOperation,并将request message分发个该DispatchOperation

WCF只定义了一个实现了IDispatchOperationSelector的OperationSelector:System.ServiceModel.Channels.OperationSelector,一般情况下,他返回的是message Action header的值。

Step 7:初始化当前的OperationContext

WCF通过System.ServiceModel.OperationContext来表示Operation相关的Context信息。Step 7会设置current OperationContext(OperationContext.Current)。

Step 8: 验证Addressing信息

如果EndpointDispatcher的ManualAddressing属性为false(表示采用默认的WS-Addressing方式进行Addressing),会按照WS-Addressing的标准对Addressing相关的message header进行检验。将的具体点,会验证message header中的Reply address、FaultTo address和From address。

Step 9:对request message进行检验或修改

在DispatchRuntime中有一个MessageInspectors集合属性,其中的每一个元素是一个个的MessageInspector对象。MessageInspector存在于client端和service端,client端较做ClientMessageInspector,实现System.ServiceModel.Dispatcher.IClientMessageInspector interface,而service端叫做 DispatchMessageInspector, 实现了System.ServiceModel.Dispatcher.IDispatchMessageInspector interface。DispatchMessageInspector允许你在request message交付到具体的DispatchOperation付诸执行之前或者reply message返回client之前对incoming message/outgoing message进行检验、修改或者其他一些基于message的操作。

IDispatchMessageInspector的定义很简单:

public interface IDispatchMessageInspector
{
// Methods
object AfterReceiveRequest(ref Message request, IClientChannel channel, InstanceContext instanceContext);
void BeforeSendReply(ref Message reply, object correlationState);
}

具体的做法是:遍历DispatchRuntime的MessageInspectors集合的每一个IDispatchMessageInspector对象,调用AfterReceiveRequest方法对request message进行检验或者修改。

Step 10:对现有的service instance进行释放和回收

如果DispatchOperation的ReleaseInstanceBeforeCall 为true, 调用DispatchRuntime的InstanceProviderReleaseInstance方法对现有的Service Instance(如果存在)进行释放和清理。

顾名思义,InstanceProvider就是用于创建或者提供service instance的。除了提供service instance的创建者或者提供者的身份外,InstanceProvider还用于service instance的释放和回收。所有的IntanceProvider实现了System.ServiceModel.Dispatcher.IInstanceProvider interface。

public interface IInstanceProvider
{
// Methods
object GetInstance(InstanceContext instanceContext);
object GetInstance(InstanceContext instanceContext, Message message);
void ReleaseInstance(InstanceContext instanceContext, object instance);
}

如果InstanceProvider对应的DispatchOperation.ReleaseInstanceBeforeCall 为true的话,IntanceProvider将通过DispatchRuntime的InstanceProvide属性提取出来,通过调用ReleaseInstance()方法释放掉现有的instance。

Step 11:获取或者创建service instance

service instance的获取或者创建是通过InstanceProvider的GetInstance()方法完成。

Step 12: 对当前线程的Context进行初始化

在真正执行我们的service operation方法的时候,可以会依赖一些当前线程的Context信息。WCF dispatching system 通过一个叫做CallContextInitializer的对象进行thread context的初始化或者清理工作。每个DispatchOperation都具有一个CallContextInitializers的集合属性,其中每个元素为与此operation相关的CallContextInitializer对象。

提到CallContextInitializer,我想有一部分人会马上想到System.Runtime.Remoting.Messaging.CallContext。CallContext为我们创建基于当前线程的Ambient context,提供了便利。通过CallConext,我们和容易地将一些contextual information至于TLS(Thread Local Storage)中。

与之相似的,DispatchOperation的CallContextInitializers提供了一个CallContextInitializer的集合,这些CallContextInitializer可以帮助我们对TLS进行初始化和释放回收的工作。比如在某个service 方法被真正之前,我们希望设置一些Context的数据,这些数据可能使业务有关,但大部分是和具体的业务逻辑没有关系的,比如一些Auditing的数据。在方式执行完成后,对这些context数据进行清理和回收。 WCF下的所有CallContextInitializer实现了System.ServiceModel.Dispatcher.ICallContextInitializer interface:

public interface ICallContextInitializer
{
// Methods
void AfterInvoke(object correlationState);
object BeforeInvoke(InstanceContext instanceContext, IClientChannel channel, Message message);
}

具体的做法是:遍历当前DispatchOperation的CallContextInitializers集合属性的每个CallContextInitializer对象,调用其BeforeInvoke()方法进行thread context的初始化工作。

Step 13:反序列化输入参数列表

对整个WCF infrastructure,我们可以将其分成两个世界,其中一个是基于message的世界;而另一个则是object的世界。对于前者来讲,所有的数据通过message进行封装,后者则同一个个具体的object来呈现。要实现具体的service功能,毫无疑问,需要调用具体的方法,传入具体的参数,而这些输入参数是一个个的对象,方法执行完成生成的结果也是一个个的对象。但是我们最初接受的request确实一个message,方法执行的参数也一infoset的形式封装在message中;我们最重终生成的结果也不能以object的形式返回来client。所以我们需要一个这样的中介:将输入参数从message中提出,并转化成object;同是将返回值从object形式转化成message。这样的中介就是:MessageFormatter。

和MessageInspector一样,client端和service的Formatter是不同的。client端叫做ClientMessageFormatter ,实现了System.ServiceModel.Dispatcher.IClientMessageFormatter interface;service端叫做DispatchMessageFormatter, 实现了System.ServiceModel.Dispatcher.IDispatchMessageFormatter interface.

public interface IDispatchMessageFormatter
{
// Methods
void DeserializeRequest(Message message, object[] parameters);
Message SerializeReply(MessageVersion messageVersion, object[] parameters, object result);
}

DispatchOperation中定义了一个DeserializeRequest的属性,用于判断是否需要反序列化request message声称一个输入参数对象列表。为什么需要有此属性呢?因为有些情况下,我们是不需要对此反序列化步骤的,比如:我们的Operation直接将message作为参数。

在Step 13中,先根据DispatchOperation的DeserializeRequest属性判断是否需要进行凡序列化操作,如何需要,则通过DispatchOperation的Formatter属性获取IDispatchMessageInspector对象,调用DeserializeRequest解析request message,通过反序列化声称一个输入参数的对象数组。

Step 14:对输入参数进行验证

Security有这样的一个原则:不能完全信任来自用户或者访问者的输入。就像Asp.NET通过一个个validator control来保证用户输入的合法性一样,WCF也需要有这样的机制。而这样的功能是通过ClientOperation或者DispatchOperation的ParameterInspectors集合实现的。

当执行具体的service method之前,会遍历DispatchOperation ParameterInspectors集合中的每个ParameterInspector,并调用BeforeCall对输入参数进行验证;而当service method被真正执行后,会生成返回值或者输出参数,在这个时候对ParameterInspectors的遍历再次进行,不果这次调用的是AfterCall方法,AfterCall方法旨在对返回值或者输出参数进行验证。

所有的ParameterInspector均实现了System.ServiceModel.Dispatcher.IParameterInspector interface。

public interface IParameterInspector
{
// Methods
void AfterCall(string operationName, object[] outputs, object returnValue, object correlationState);
object BeforeCall(string operationName, object[] inputs);
}

注: 大家可能已经注意到了,BeforeCall有一个返回值。这个返回值得目的在于同AfterCall进行批评。在调用AfterCall是,这个返回值将会传入第三个参数:correlationState。

在Step 14中,会遍历DispatchOperation的ParameterInspectors集合属性中的每一个

IParameterInspector对象,调用其BeforeCall对输入参数进行验证。

Step 15:执行service operation方法

知道这一步,整个的service operation method才真正被执行。具体的做法是通过DispatchOperation的Invoker属性得到一个System.ServiceModel.Dispatcher.IOperationInvoker的对象,IOperationInvoker得定义如下:

public interface IOperationInvoker
{
// Methods
object[] AllocateInputs();
object Invoke(object instance, object[] inputs, out object[] outputs);
IAsyncResult InvokeBegin(object instance, object[] inputs, AsyncCallback callback, object state);
object InvokeEnd(object instance, out object[] outputs, IAsyncResult result);

// Properties
bool IsSynchronous { get; }
}

如果以同步的方式执行操作的话则执行Invoke() 方法,倘若以异步的方式则调用InvokeBegin/InvokeEnd方法。具体的实现很简单,我们已同步的方式为例:首先通过当前表示当前Operation描述信息的OperationDescription对象,通过该对象的SyncMethod属性得到具体的方法名称,通过service type得到MethodInfo对象,然后调用MethodInfo对象的Invoke方法,传入service instance对象和输入参数。执行的结果会生成返回值或者输出参数列表。

Step 16:对返回值或输出参数进行检验

在Step 14,上面我们提到通过DispatchOperation的PameteterInpectors集合中的PameteterInpector对输入参数进行验证,现在我们利用它来对返回值或者输出参数进行验证。

具体的做法是,遍历PameteterInpectors集合中的每个PameteterInpector对象,调用AfterCall()方法,从而实现对返回值和输出参数的验证。

Step 17: 序列化返回值或者输出参数

正如要调用具体的service method,需要将request message反序列化生成一串输入参数对象列表(Step 13),同样地,要将返回值或者输出参数返回给访问者,需要将它们进行序列化。

具体的做法是:通过DispatchOperation的SerializeReply属性判断是否需要对返回值和输出参数进行序列化,如何需要,则通过Formatter属性获取具体的IDispatchMessageFormatter对象,调用SerializeReply方法对返回值和输出参数进行序列化。

Step 18:清理thread context

在Step 12 中,我们通过DispatchOperation的CallContextInitializers集合实现对当前线程的context进行初始化工作,与之相对地,当service operation执行完成,我们同样可以通过他们对thread context进行清理操作。

具体的做法是:遍历CallContextInitializers中的每一个CallContextInitializer,调用其AfterCall()方法实现对thread context的清理和释放。

Step 19:Error Handling

无论是对于具体的项目开发也好,还是对Framework的开发也罢,对异常、错误的处理都是必须的。在WCF,通过ErrorHandler对象,你可以很容易地实现对异常的处理。ChannelDispatcher中将一个ErrorHandler的集合定义在ErrorHandlers属性中。当出现exception的时候,会遍历这个ErrorHandlers集合中的每个ErrorHandler。调用HandleError方法和ProvideFault方法。

所有的ErrorHandler都实现了System.ServiceModel.Dispatcher.IErrorHandler interface:

public interface IErrorHandler
{
// Methods
bool HandleError(Exception error);
void ProvideFault(Exception error, MessageVersion version, ref Message fault);
}

具体的做法是:遍历ChannelDispatcher的ErrorHandlers集合中的每一个ErrorHandler,调用其HandleError方法,如何其中有一个返回true,将推出迭代。

Step 20:最后作一些资源的释放和清理工作

WCF后续之旅:
[原创]WCF后续之旅(1): WCF是如何通过Binding进行通信的
[原创]WCF后续之旅(2): 如何对Channel Layer进行扩展——创建自定义Channel
[原创]WCF后续之旅(3): WCF Service Mode Layer 的中枢—Dispatcher
[原创]WCF后续之旅(4):WCF Extension Point 概览
[原创]WCF后续之旅(5): 通过WCF Extension实现Localization
[原创]WCF后续之旅(6): 通过WCF Extension实现Context信息的传递
[原创]WCF后续之旅(7):通过WCF Extension实现和Enterprise Library Unity Container的集成
[原创]WCF后续之旅(8):通过WCF Extension 实现与MS Enterprise Library Policy Injection Application Block 的集成
[原创]WCF后续之旅(9):通过WCF的双向通信实现Session管理[Part I]
[原创]WCF后续之旅(9): 通过WCF双向通信实现Session管理[Part II]
[原创]WCF后续之旅(10): 通过WCF Extension实现以对象池的方式创建Service Instance

我的WCF之旅:
[原创]我的WCF之旅(1):创建一个简单的WCF程序
[原创]我的WCF之旅(2):Endpoint Overview
[原创]我的WCF之旅(3):在WCF中实现双向通信(Bi-directional Communication)
[原创]我的WCF之旅(4):WCF中的序列化(Serialization)- Part I
[原创]我的WCF之旅(4):WCF中的序列化(Serialization)- Part II
[原创]我的WCF之旅(5):Service Contract中的重载(Overloading)
[原创]我的WCF之旅(6):在Winform Application中调用Duplex Service出现TimeoutException的原因和解决方案
[原创]我的WCF之旅(7):面向服务架构(SOA)和面向对象编程(OOP)的结合——如何实现Service Contract的继承
[原创]我的WCF之旅(8):WCF中的Session和Instancing Management
[原创]我的WCF之旅(9):如何在WCF中使用tcpTrace来进行Soap Trace
[原创]我的WCF之旅(10): 如何在WCF进行Exception Handling
[原创]我的WCF之旅(11):再谈WCF的双向通讯-基于Http的双向通讯 V.S. 基于TCP的双向通讯
[原创]我的WCF之旅(12):使用MSMQ进行Reliable Messaging
[原创]我的WCF之旅(13):创建基于MSMQ的Responsive Service

分享到:
评论

相关推荐

    Apress Pro WCF 4

    ■Chapter 3: Exploring the WCF Programming Model Part II: Programming with WCF ■Chapter 4: Installing and Creating WCF Services ■Chapter 5: Hosting and Consuming WCF Services ■Chapter 6: ...

    WCF之旅:一个简单的WCF程序(vs2010源码)

    WCF之旅:一个简单的WCF程序(vs2010源码) 文章 + 源码 入门首选文章,折腾了好久才折腾出第一个wcf程序。 对准备学习wcf的人员绝对有意义

    我的WCF之旅:计算器 WCF样例源代码

    我的WCF之旅- 创建一个简单的WCF程序 - Artech WCF入门之选绝佳的例子 代源源于:《WCF全面解析 上》 编程工具:VS2010 语言:C# blog 《IIS站点中部署 WCF项目》

    我的WCF之旅源代码_创建一个简单的WCF程序

    我的WCF之旅源代码_创建一个简单的WCF程序

    我的WCF之旅源代码 IIS寄宿

    我的WCF之旅(1)配套代码,IIS寄宿 泛型 序列化

    WCF 我的WCF之旅示例代码

    在学习WCF之旅的时候自己写得一些代码,不同的版本展示了逐渐深入的过程,有文字说明,很经典。

    我的WCF之旅后续篇

    我的WCF之旅后续篇,呀,要大于20字符啊,废话一下

    WCF Service编程源代码

    WCF Service 源代码 作者:Lowy WCF Service 源代码

    wcfservice示例

    wcfservice示例wcfservice示例wcfservice示例wcfservice示例wcfservice示例

    WCF 学习之旅

    本课件包含课件,及对应源部分,为本人所做课件,可以对照文档一步步实现代码,本课件对WebService 进行了简单的介绍,WCF简单的应用 ,可以布置到各种寄宿平台上,

    WCF开发实战

    WCF开发实战系列一:创建第一个WCF服务 WCF开发实战系列二:使用IIS发布WCF服务 WCF开发实战系列三:自运行WCF服务 WCF开发实战系列四:使用Windows服务发布WCF服务 WCF开发实战系列五:创建WCF客户端程序

    wcf服务window service

    wcf 服务寄宿到windows service上

    我的wcf之旅1-13

    Artech的博客文章,我把它转成chm的格式给大家分享

    我的WCF之旅(合集)

    我把WCF之旅制作了个电子书,为WCF做点贡献吧

    WCF之旅 WCF学习的相关资料

    WCF之旅 1. 创建一个简单的WCF程序 3.在WCF中实现双向通信(Bi-directional Communication) 5. 通过WCF Extension实现Localization ......

    WCF技术剖析,wcf教程+.pdf

    蒋金楠老师的wcf教程,个人看了,觉得写的很不错,对刚入门和深入了解wcf都适用,有需要的同学可下载学习

    WCFService可以通过web调用和WCF服务访问

    WCF服务,配置可同时支持web调用和WCF调用,可以用于C#程序服务访问,也支持java等程序访问。java通过web调用,C#可以通过wcf访问。

    WCF-Messaging-Service:C# .NET 4.5.1 WCF 消息服务和客户端

    WCF-消息服务 C# .NET 4.5.1 WCF 消息服务和客户端 介绍该项目是我仅使用代码(不使用配置或 wsdl 文件)演示 WCF 服务器和客户端应用程序 控制台服务器正是这样:一个运行简单 WCF 消息服务的 C# 控制台应用程序。 ...

    WCF技术专题:WCF入门与进阶

    讲解WCF技术的,适合各种阶段的学习。从入门到进阶。

    WCF实例 webservice

    WCF 概括地说,WCF具有如下的优势: 1、统一性 前面已经叙述,WCF是对于ASMX,.Net Remoting,Enterprise Service,WSE,MSMQ等技术的整合。由于WCF完全是由托管代码编写,因此开发WCF的应用程序与开发其它的...

Global site tag (gtag.js) - Google Analytics