WCF是一个具有极高扩展度的分布式通信框架，无论是在信道层（Channel Layer）还是服务模型层（Service Model），我们都可以自定义相关组件通过相应的扩展注入到WCF运行环境中。在WCF众多可扩展点中，ICallContextInitializer可以帮助我们在服务操作执行前后完成一些额外的功能，这实际上就是一种AOP的实现方式。比如在《通过WCF Extension实现Localization》中，我通过ICallContextInitializer确保了服务操作具有和客户端一样的语言文化；在《通过WCF Extension实现Context信息的传递》中，我通过ICallContextInitializer实现上下文在客户端到服务端的自动传递。ICallContextInitializer的定义如下：
1: public interface ICallContextInitializer
2: {
3: // Methods
4: void AfterInvoke(object correlationState);
5: object BeforeInvoke(InstanceContext instanceContext, IClientChannel channel, Message message);
6: }
昨天，李永京同学问了我一个相关的问题。问题大概是这样的，他采用ICallContextInitializer实现WCF与NHibernate的集成。具体来说是通过ICallContextInitializer实现对事务 的提交，即通过BeforeInvoke方法初始化NHibernate的Session，通过AfterInvoke提交事务。但是，这中间具有一个挺严重的问题：当执行AfterInvoke提交事务的时候，是可能抛出异常的。一旦异常从AfterInvoke抛出，整个服务端都将崩溃。我们现在就来讨论一下这个问题，以及问题产生的根源。
一、问题重现
为了重现这个问题，我写了一个很简单的例子，你可以从这里下载该例子。首先我定义了如下一个实现了ICallContextInitializer接口的自定义CallContextInitializer：MyCallContextInitializer。在AfterInvoke方法中，我直接抛出一个异常。
1: public class MyCallContextInitializer : ICallContextInitializer
2: {
3: public void AfterInvoke(object correlationState)
4: {
5: throw new Exception("调用MyCallContextInitializer.AfterInvoke()出错！");
6: }
7:
8: public object BeforeInvoke(InstanceContext instanceContext, IClientChannel channel, Message message)
9: {
10: return null;
11: }
12: }
然后，我们通过ServiceBehavior的方式来应用上面定义的MyCallContextInitializer。为此，我们定义了如下一个实现了IServiceBehavior接口的服务行为：MyServiceBehaviorAttribute。在ApplyDispatchBehavior方法中，将我们自定义的MyCallContextInitializer对象添加到所有终结点的分发运行时操作的CallContextInitializer列表中。
1: public class MyServiceBehaviorAttribute : Attribute, IServiceBehavior
2: {
3: public void AddBindingParameters(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase, Collection<ServiceEndpoint> endpoints, BindingParameterCollection bindingParameters) { }
4:
5: public void ApplyDispatchBehavior(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase)
6: {
7: foreach (ChannelDispatcher dispatcher in serviceHostBase.ChannelDispatchers)
8: {
9: foreach (EndpointDispatcher endpoint in dispatcher.Endpoints)
10: {
11: foreach (DispatchOperation operation in endpoint.DispatchRuntime.Operations)
12: {
13: operation.CallContextInitializers.Add(new MyCallContextInitializer());
14: }
15: }
16: }
17: }
18:
19: public void Validate(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase) { }
20: }
然后，我们采用我们熟悉的计算服务的例子来验证MyCallContextInitializer对整个服务端运行时的影响。下面是服务契约和服务类型的定义，我们自定义的服务行为MyServiceBehaviorAttribute通过自定义特性的方式应用到CalculatorService上面。
1: namespace Artech.Exception2CallContextInitializer.Contracts
2: {
3: [ServiceContract(Namespace="http://www.artech.com/")]
4: public interface ICalculator
5: {
6: [OperationContract]
7: double Add(double x, double y);
8: }
9: }
1: namespace Artech.Exception2CallContextInitializer.Services
2: {
3: [MyServiceBehavior]
4: public class CalculatorService:ICalculator
5: {
6: public double Add(double x, double y)
7: {
8: return x + y;
9: }
10: }
11: }
后然我们通过Console应用的方式来Host上面定义的CalculatorService，并创建另一个Console应用来模拟客户端对服务进行调用。由于相应的实现比较简单，在这里就不写出来了，对此不清楚的读者可以直接下载例子查看源代码。当你运行程序的时候，作为宿主的Console应用会崩溃，相应的进程也会被终止。如果服务宿主程序正常终止，客户端会抛出如左图所示的一个CommunicationException异常。
如果在调用超时时限内，服务宿主程序没能正常终止，客户端则会抛出如右图所示的TimeoutException异常。
查看Event Log，你会发现两个相关的日志。它们的Source分别是：System.ServiceMode 3.0.0.0和.NET Runtime。两条日志相应的内容如下。如果你足够细心，你还会从中看到WCF一个小小的BUG。日志内容的第二行为“Message: ICallContextInitializer.BeforeInvoke threw an exception of type System.Exception: 调用MyCallContextInitializer.AfterInvoke()出错！”，实际上这里的“ICallContextInitializer.BeforeInvoke”应该改成“ICallContextInitializer.AfterInvoke”。下面一部分中你将会看到这个BUG是如何产生的。
FailFast was invoked.
Message: ICallContextInitializer.BeforeInvoke threw an exception of type System.Exception: 调用MyCallContextInitializer.AfterInvoke()出错！
Stack Trace: at System.ServiceModel.Diagnostics.ExceptionUtility.TraceFailFast(String message, EventLogger logger)
at System.ServiceModel.Diagnostics.ExceptionUtility.TraceFailFast(String message)
at System.ServiceModel.DiagnosticUtility.FailFast(String message)
at System.ServiceModel.Dispatcher.DispatchOperationRuntime.UninitializeCallContextCore(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.DispatchOperationRuntime.UninitializeCallContext(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage4(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage3(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage2(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage1(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.Dispatch(MessageRpc& rpc, Boolean isOperationContextSet)
at System.ServiceModel.Dispatcher.ChannelHandler.DispatchAndReleasePump(RequestContext request, Boolean cleanThread, OperationContext currentOperationContext)
at System.ServiceModel.Dispatcher.ChannelHandler.HandleRequest(RequestContext request, OperationContext currentOperationContext)
at System.ServiceModel.Dispatcher.ChannelHandler.AsyncMessagePump(IAsyncResult result)
at System.ServiceModel.Dispatcher.ChannelHandler.OnAsyncReceiveComplete(IAsyncResult result)
at System.ServiceModel.Diagnostics.Utility.AsyncThunk.UnhandledExceptionFrame(IAsyncResult result)
at System.ServiceModel.AsyncResult.Complete(Boolean completedSynchronously)
at System.ServiceModel.Channels.InputQueue`1.AsyncQueueReader.Set(Item item)
at System.ServiceModel.Channels.InputQueue`1.EnqueueAndDispatch(Item item, Boolean canDispatchOnThisThread)
at System.ServiceModel.Channels.InputQueue`1.EnqueueAndDispatch(T item, ItemDequeuedCallback dequeuedCallback, Boolean canDispatchOnThisThread)
at System.ServiceModel.Channels.InputQueueChannel`1.EnqueueAndDispatch(TDisposable item, ItemDequeuedCallback dequeuedCallback, Boolean canDispatchOnThisThread)
at System.ServiceModel.Channels.SingletonChannelAcceptor`3.Enqueue(QueueItemType item, ItemDequeuedCallback dequeuedCallback, Boolean canDispatchOnThisThread)
at System.ServiceModel.Channels.HttpChannelListener.HttpContextReceived(HttpRequestContext context, ItemDequeuedCallback callback)
at System.ServiceModel.Channels.SharedHttpTransportManager.OnGetContextCore(IAsyncResult result)
at System.ServiceModel.Channels.SharedHttpTransportManager.OnGetContext(IAsyncResult result)
at System.ServiceModel.Diagnostics.Utility.AsyncThunk.UnhandledExceptionFrame(IAsyncResult result)
at System.Net.LazyAsyncResult.Complete(IntPtr userToken)
at System.Net.LazyAsyncResult.ProtectedInvokeCallback(Object result, IntPtr userToken)
at System.Net.ListenerAsyncResult.WaitCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped)
at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)
Process Name: Artech.Exception2CallContextInitializer.Services
Process ID: 7652
如果你想从消息交换得角度进一步剖析问题的本质，你可以采用Fiddler这样的工具。如果你真的这样做的话，你会发现服务端没有任何消息返回到客户端。
二、原因剖析
从上面表现出来的现象，我们可以知道这是一个非常严重的问题，因为它将会终止整个服务宿主进程。那么，是什么导致了这个严重的问题呢？实际上，如果通过Reflector对WCF相关代码进行反射，你将会很容易找到问题的根源。
ICallContextInitializer的AfterInvoke方法的最终是通过定义在DispatchOperationRuntime类型的一个命名为UninitializeCallContextCore的私有方法中被调用的。下面就是该方法的定义：
1: private void UninitializeCallContextCore(ref MessageRpc rpc)
2: {
3: object proxy = rpc.Channel.Proxy;
4: int callContextCorrelationOffset = this.Parent.CallContextCorrelationOffset;
5: try
6: {
7: for (int i = this.CallContextInitializers.Length - 1; i >= 0; i--)
8: {
9: this.CallContextInitializers[i].AfterInvoke(rpc.Correlation[callContextCorrelationOffset + i]);
10: }
11: }
12: catch (Exception exception)
13: {
14: DiagnosticUtility.FailFast(string.Format(CultureInfo.InvariantCulture, "ICallContextInitializer.BeforeInvoke threw an exception of type {0}: {1}", new object[] { exception.GetType(), exception.Message }));
15: }
16: }
17:
18:
19:
20:
通过上面的代码，你会看到对DispatchOperation所有CallContextInitializer的AfterInvoke方法的调用是放在一个Try/Catch中进行的。当异常抛出后，会调用DiagnosticUtility的FailFast方法。传入该方法的是异常消息，你可以看到这里指定的消息是不对的，“ICallContextInitializer.BeforeInvoke”应该是“ICallContextInitializer.AfterInvoke”，这就是为什么你在Event Log看到日志内容是不准确的真正原因。我们进一步来看看FailFast的定义：
1: [MethodImpl(MethodImplOptions.NoInlining)]
2: internal static Exception FailFast(string message)
3: {
4: try
5: {
6: try
7: {
8: ExceptionUtility.TraceFailFast(message);
9: }
10: finally
11: {
12: Environment.FailFast(message);
13: }
14: }
15: catch
16: {
17: }
18: Environment.FailFast(message);
19: return null;
20: }
从上面的代码可以看到，整个过程分为两个步骤：对消息尽心Trace后调用Environment.FailFast方法。对Environment.FailFast方法具有一定了解的人应该之后，该方法执行后会终止掉当前进程。这就是为什么在ICallContextInitializer的AfterInvoke方法执行过程中出现未处理异常会导致宿主程序的非正常崩溃的真正原因。
三、总结
CallContextInitializer的设计可以看成是AOP在WCF中的实现，它可以在服务操作执行前后对方法调用进行拦截。你可以通过自定义CallContextInitializer实现一些服务操作执行前的初始化操作，以及操作执行后的清理工作。但是，当你自定义CallContextInitializer的时候，一定要确保AfterInvoke方法中没有异常抛出来。
出处： http://artech.cnblogs.com
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
