WCF技术剖析之二十二: 深入剖析WCF底层异常处理框架实现原理[中篇]

Fault和FaultException异常。在服务执行过程中，我们手工抛出FaultException异常，WCF服务端框架会对该异常对象进行序列化病最终生成Fault消息。当WCF客户端框架介绍到该Fault消息之后，会做一项相反的操作：对Fault消息中进行解析和反序列化，重新生成并抛出FaultException异常。WCF框架自动为我们作了这么多“幕后”工作，使得开发人员可以完全采用编写一般的.NET应用程序的模式进行异常的处理：在错误的地方抛出相应异常，对于潜在出错的方法调用进行相应的异常捕获和处理。所以，WCF的异常处理框架的核心功能就是实现FaultException异常和Fault消息之间的转换，接下来我们着重来讨论这个话题。

一、FaultException异常和Fault消息之间的纽带：MessageFault

对于WCF的异常处理框架，其本身并不直接进行FaultException异常和Fault消息之间的转换，而是通过另外一个作为中介的对象来完成的，这个对象就是这一小节我们讲述的重点：MessageFault。Message（Fault）、MessageFault和FaultException通过如图1描述的“三角”关系实现了相互之间的转化。

<a target="_blank" href="http://images.cnblogs.com/cnblogs_com/artech/WindowsLiveWriter/WCFWCF_1175C/clip_image002_2.jpg"></a>

图1 Message（Fault）、Message和FaultException“三角”转换关系

在消息介绍MessageFault之前，我们先来看看MessageFault的定义。MessageFault定义在命名空间System.ServiceModel.Channels下，下面的代码是MessageFault的定义。

从上面给出的对MessageFault并不复杂的定义可以看出，它的属性成员和FaultException，以及SOAP

Fault的5个子元素是想匹配的：Code、Reason、Node、Actor（对于SOAP 1.2规范中SOAP

Fault的Role元素，在SOAP

1.1中的名称为Actor）。而另一个元素Detail则可以通过两个泛型方法GetDetail&lt;T&gt;获得。由于此操作需要对错误明细对象进行反序列化，所以需要指定错误明细类型对应的序列化器，默认情况下采用的是DataContractSerializer。而属性IsMustUnderstandFault表述此错误是否是由于识别

SOAP

标头失败而造成的，实际上，它和FaultCode的IsPredefinedFault向对应，主要具有预定义的Code，IsMustUnderstandFault就返回True。

通过MessageFault众多的CreateFault静态方法，我们可以以不同的组合方式指定构成SOAP

Fault的5个元素。如果指定了错误明细对象，需要指定与之匹配的序列化器以实现对其的序列化和反序列化。两个重载的WirteTo方法实行对MessageFault进行序列化，并将序列化后的XML通过XmlDictionaryWriter或者XmlWriter写入掉相应的“流”中。

由于不同的SOAP规范的版本（SOAP 1.1和SOAP 1.2）对Message

Fault的结构进行了不同的规定，所有在调用WirteTo的时候需要显式地指定基于那个版本进行写入（SOAP的版本通过EnvelopeVersion表示）。下面的示例代码中，我们创建了一个MessageFault对象，分别针对SOAP

1.1和SOAP 1.2写到两个不同的XML文件中。读者可以仔细辨别最终生成的Message Fault到底有多大的差别。

基于SOAP 1.1（fault.soap11.xml）：

基于SOAP 1.2（fault.soap12.xml）：

二、 如何实现Message（Fault）和MessageFault之间的转换

MessageFault可以作为Message（Fault）和FaultException异常之间进行转换的中介，而且WCF定义个相应的API实现Message和MessageFault，以及MessageFault和FaultException异常之间的转化。我们先来关注一下如果实现Message和MessageFault两种之间的转化。

由于MessageFault定义与Fault消息中主体部分的Fault元素，即SOAP

Fault，所以对于一个给定的表示Fault消息的Message对象，我们可以通过提取SOAP

Fault对应，从而创建相应的MessageFault对象。MessageFault提供了下面一个CreateFault静态方法，使我们能过传入一个Message对象创建MessageFault（参数maxBufferSize为做大消息缓冲区最大缓冲区大小）。

在下面的代码中，借助于Message的静态方法CreateMessage，通过逐个指定FaultCode、FaultReason、Detail和Action的方式创建了一个Fault消息。然后将其传入上述的CreateFault静态方法，从而创建出相应的MessageFault对象。最后通过MessageFault的GetDetail&lt;T&gt;方法得到错误明细对象，通过输出的信息可以证实该MessageFault中的错误明信息和创建消息指定指定的是一致的。

输出的结果：

既然我们可以通过提取Fault消息的SOAP

Fault进而创建相应的MessageFault，我们同样可以通过给定的MessageFault对象，基于某种消息版本和Action报头，创建一个Fault消息。Message类型中定义的下面一个静态的CreateMessage方法可以帮我们实现这样的操作。

下面的例子中，我通过MessageFault的CreateFault方法创建了一个MessageFault对象。然后将其传入上述的CreateMessage静态方法，并指定不同的MessageVersion（MessageVersion.Soap11WSAddressingAugust2004和MessageVersion.Soap12WSAddressing10），创建了不同的Fault消息。有兴趣的读者可以仔细分析一下：基于不同的消息版本，针对同一个MessageFault对象创建的Fault消息都有哪些差异（最后能够针对SOAP

1.1、SOAP 1.2、WS-Addressing 2004和WS-Addressing 1.0规范进行比较）。

基于SOAP 1.1 + WS-Addressing 2004的Fault消息（faultmessage.soap11.addressing2004.xml）：

基于SOAP 1.2 + WS-Addressing 1.0的Fault消息（faultmessage.soap12.addressing10.xml）：

三、如何实现MessageFault和FaultException之间的转换

上面介绍的是MessageFault和Message（Fault）之间的转化关系，现在我们来介绍Message、Message和FaultException“三角”关系中的另一组转换关系：MessageFault和FaultException之间的转换关系。

WCF将实现MessageFault和FaultException之间的转化的API定义在FaultException类中。其中两个静态CreateFault方法实现将MessageFault向FaultException的转换，而实例方法CreateMessageFault则将FaultException对象转化成相应的MessageFault对象。三个方法定义如下，其中faultDetailTypes代表错误明细类型列表，这是为对FaultException&lt;TDetail&gt;对象的反序列化服务的。

在下面的实例代码中，先通过调用MessageFault的静态方法CreateFault方法，传入组成一个完整MessageFault相关的参数，创建了一个MesageFault对象。然后调用上面介绍的静态方法CreateFault，创建FaultException对象。由于我们构建MessageFault的时候查传入一个CalculationError作为错误明细，所以返回的异常类型应该是FaultException&lt;CalculationError&gt;对象。最后，我们将该异常对象的相关信息在控制台上输出。

上面给出的是如果将一个MessageFault对象转换成一个FaultException异常的例子,如果要进行相干的操作,只需要直接调用FaultException异常实例的CreateMessageFault方法即可。清楚了应该调用怎样的API进行MessageFault和FaultException之间的转换，我们现在来进一步深入了解其内部的实现原理。在自身的异常处理框架内容，WCF实际上是通过一个特殊的对象实现两者之间的转换的，这个对象就是我们下面要介绍的FaultFormatter。

四、FaultException与MessageFault转换的核心：FaultFormatter

在《WCF技术剖析（卷1）》的第5章关于序列化和数据契约的介绍中，我们谈到：WCF借助于一个特殊的对象——MessageFormatter，实现方法调用和消息之间的转换。具体来说，客户端通过ClientMessageFormatter将服务操作方法调用转换成请求消息（其中主要涉及对参数对象的序列化），以及将接收到的回复消息转换成服务操作方法对应的返回值或者输出/引用参数（其中只要涉及对返回值或者输出/引用参数的反序列化）；服务端则通过DispatchMessageFormatter实现与此相反的操作。

MessageFormatter实现了在正常的服务调用过程中方法调用和消息之间的转换，但是，当异常（这里指的是FaultException异常）从服务端抛出，WCF通过需要一个相似的组件实现类似的功能：在服务端对异常对象进行序列化并生成回复消息（Fault消息），在客户端对接收到的回复消息进行反序列化重建并抛出异常。这样的一个使命由FaultFormatter担当，不过，由于MessageFault是FaultException和Fault消息进行转换的中介，所以FaultFormatter并不直接进行两者之间的转换，而是实现FaultException和MessageFault之间的转换。

严格地说来，FaultFormatter仅仅是WCF一个内部对象，但是对该对象的深刻认识将非常有助于我们有效的理解WCF整个异常处理机制。FaultFormatter在客户端和服务端所扮演的角色是不同的：客户端将通过解析回复Fault消息生成的MessageFault转换成FaultException异常，以便后续的步骤建起抛出；服务端在将抛出的FaultException异常转换成MessageFault，以便后续的步骤生成相应的Fault消息。客户端和服务端这种职责的不同可以通过下面两个接口的定义看出来：

内部（Internal）接口IClientFaultFormatter和IDispatchFaultFormatter分别定义了FaultFormatter在客户端和服务端的职能，即它们分别实现对FaultException对象的反序列化和序列化。在对FaultException对象进行序列化需要提取Action属性作为Fault消息的Action报头；而将MessageFault进行反序列化生成FaultException对象的时候需要从外部指定Action属性的值，所以两个方法各有一个action参数。

WCF定义了一个内部类System.ServiceModel.Dispatcher.FaultFormatter实现了这两个接口，并将其作为服务端和客户端的FaultFormatter。下面是FaultFormatter类型的定义：

由于WCF将绝大部分序列化和反序列化的工作都交付给两个序列化器：DataContractSerializer和XmlSerializerObjectSerializer，对于FaultException异常对象的序列化自然也不例外。为此，WCF定义了两个具体的类型System.ServiceModel.Dispatcher.DataContractSerializerFaultFormatter和System.ServiceModel.Dispatcher.XmlSerializerFaultFormatter。它们直接继承自FaultFormatter，分别采用DataContractSerializer和XmlSerializerObjectSerializer作为相应的序列化器。IClientFaultFormatter、IDispatchFaultFormatter、FaultFormatter、DataContractSerializerFaultFormatter和XmlSerializerFaultFormatter之间的关系可以简单地通过图2所示的类图表示。

<a target="_blank" href="http://images.cnblogs.com/cnblogs_com/artech/WindowsLiveWriter/WCFWCF_1175C/clip_image004_2.jpg"></a>

图2 FaultFormatter体系结构

作者：蒋金楠

微信公众账号：大内老A

如果你想及时得到个人撰写文章以及著作的消息推送，或者想看看个人推荐的技术资料，可以扫描左边二维码（或者长按识别二维码）关注个人公众号（原来公众帐号蒋金楠的自媒体将会停用）。

本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。

<a href="http://www.cnblogs.com/artech/archive/2009/10/29/1592517.html" target="_blank">原文链接</a>