异常消息与特定技术有关，.NET异常同样如此，因而WCF并不支持传统的异常处理方式。如果在WCF服务中采用传统的方式处理异常，由于异常消息不能被序列化，因而客户端无法收到服务抛出的异常，例如这样的服务设计：
[ServiceContract(SessionMode = SessionMode.Allowed)]
public interface IDocumentsExplorerService
{
[OperationContract]
DocumentList FetchDocuments(string homeDir);
}
[ServiceBehavior(InstanceContextMode=InstanceContextMode.Single)]
public class DocumentsExplorerService : IDocumentsExplorerService,IDisposable
{
public DocumentList FetchDocuments(string homeDir)
{
//Some Codes
if (Directory.Exists(homeDir))
{
//Fetch documents according to homedir
}
else
{
throw new DirectoryNotFoundException(
string.Format("Directory {0} is not found.",homeDir));
}
}
public void Dispose()
{
Console.WriteLine("The service had been disposed.");
}
}
则客户端在调用如上的服务操作时，如果采用如下的捕获方式是无法获取该异常的：
catch (DirectoryNotFoundException ex)
{
//handle the exception;
}
为了弥补这一缺陷，WCF会将无法识别的异常均当作为FaultException异常对象，因此，客户端可以捕获FaultException或者Exception异常：
catch (FaultException ex)
{
//handle the exception;
}
catch (Exception ex)
{
//handle the exception;
}
然
而，这样捕获的异常，却无法识别DirectoryNotFoundException所传递的错误信息。尤为严重的是这样的异常处理方式还会导致传递消
息的通道出现错误，当客户端继续调用该服务代理对象的服务操作时，会获得一个CommunicationObjectFaultedException异
常，无法继续使用服务。如果服务被设置为PerSession模式或者Single模式，异常还会导致服务对象被释放，终止服务。
WCF为异常处理专门提供了FaultContract特性，它可以被应用到服务操作上，指明操作可能会抛出的异常类型。例如前面的服务契约就可以修改为：
[ServiceContract(SessionMode = SessionMode.Allowed)]
public interface IDocumentsExplorerService
{
[OperationContract]
[FaultContract(typeof(DirectoryNotFoundException))]
DocumentList FetchDocuments(string homeDir);
}
然而，即使通过FaultContract指定了操作要抛出的异常，然而如果服务抛出的异常并非FaultException或者FaultException<T>异常，同样会导致通道发生错误。因此在服务实现中，正确的实现应该如下：
public class DocumentsExplorerService : IDocumentsExplorerService,IDisposable
{
public DocumentList FetchDocuments(string homeDir)
{
//Some Codes
if (Directory.Exists(homeDir))
{
//Fetch documents according to homedir
}
else
{
DirectoryNotFoundException exception = new DirectoryNotFoundException();
throw new FaultException<DirectoryNotFoundException>(exception,
new FaultReason(string.Format("Directory {0} is not found.", homeDir)));
}
}
}
我
们可以将服务所要抛出的异常类型作为FaultException<T>的类型参数，然后创建一个FaultReason对象用以传递错误消
息。客户端在调用服务代理对象时，可以捕获FaultException<
DirectoryNotFoundException>异常，并且该异常不会使得通道发生错误，并且客户端可以继续使用该服务代理对象。即使服务
为PerCall服务，客户端仍然可以继续调用服务操作。如果服务为Session服务或Singleton服务，那么即使发生了异常，服务对象也不会被
终结。
如果只是为了让客户端获得异常消息，即使不施加FaultContract特性，或者抛出非FaultException异常，我
们也可以通过ServiceBehavior特性，将服务的IncludeExceptionDetailInFaults设置为true（默认为
false），此时，客户端可以捕获抛出的非FaultException异常信息，但该异常仍然会导致通道出现错误。
但是，在发布服务与部署服务时，我们应避免将服务的IncludeExceptionDetailInFaults设置为true。
如
果不希望使用FaultContract，同时又要保证服务抛出的异常能够被客户端捕获，并且不会导致通道错误，我们还可以通过错误处理扩展的方式实现。
此时，我们可以将服务本身作为错误处理对象，令其实现System.ServiceModel.Dispatcher.IErrorHandler接口：
public class DocumentsExplorerService : IDocumentsExplorerService,IErrorHandler, IDisposable
{…}
在
该接口的ProvideFault()方法中，可以将非FaultContract异常提升为FaultContract<T>异常，例如将
DirectoryNotFoundException异常提升为FaultExceptino<
DirectoryNotFoundException>异常：
public void ProvideFault(Exception error, MessageVersion version, ref Message fault)
{
if (error is DirectoryNotFoundException)
{
FaultException<DirectoryNotFoundException> faultException = new FaultException<DirectoryNotFoundException>(
new DirectoryNotFoundException(), new FaultReason(error.Message));
MessageFault messageFault = faultException.CreateMessageFault();
fault = Message.CreateMessage(version,messageFault,faultException.Action);
}
}
而在该接口的HandleError()方法中，则可以处理异常错误，例如记录日志。
要使得错误处理扩展生效，还需要向服务通道安装错误处理扩展。方法是让服务类实现System.ServiceModel.Description.IServiceBehavior接口：
public class DocumentsExplorerService : IDocumentsExplorerService,IErrorHandler,IServiceBehavior,IDisposable
{…}
然后在ApplyDispatchBehavior()方法中安装错误处理扩展：
public void ApplyDispatchBehavior(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase)
{
foreach (ChannelDispatcher dispatcher in serviceHostBase.ChannelDispatchers)
{
dispatcher.ErrorHandlers.Add(this);
}
}
通
过这样的处理，即使服务抛出的异常为DirectoryNotFoundException异常，并且在服务契约中没有通过FaultContract特
性指定该异常，客户端同样能够获得异常的错误信息，且该异常不会导致通道发生错误，客户端可以继续调用服务代理对象的操作。
本文已在IT168发表：http://tech.it168.com/msoft/2007-12-03/200712031939709.shtml
请求-应答（Request-Reply）操作“除了NetPeerTcpBinding和NetMsmqBinding绑定，所有的绑定均支持请求-应答操作。”
单向操作单
向操作没有返回值。单向操作不同于异步操作，虽然单向操作只是在发出调用的瞬间阻塞客户端，但如果发出多个单向调用，WCF会将这些调用放入队列。队列存
储调用的个数是有限的，一旦发出的调用个数超出了队列存储调用的设置值，则会发生阻塞现象，因为调用无法放入队列。当队列的请求出列后，产生阻塞的调用就
会放入队列，并解除对客户端的阻塞。
设置单向操作的方法是利用OperationContract特性的IsOneWay属性，例如：
[ServiceContract]
interface IMyContract
{
[OperationContract(IsOneWay = true)]
void MyMethod( );
}
被设置为单向操作的方法不能包含返回值，即它的返回值只能为void，否则会抛出InvalidOperationException异常。
在
会话契约中虽然允许定义单向操作，但由于单向操作无法正确地维持状态，因而，单向操作的最佳适用场景是在单调服务或单例服务中。“如果在会话契约中定义了
单向操作，就必须保证单向操作是终止会话的最后一个操作（该操作必须遵循单向操作的规定，例如返回void类型值）。这可以通过分步操作来实现。”
单向操作如果抛出异常，则视其服务模型以及使用绑定的不同，会产生不同的结果。以下内容假定服务不会抛出FaultException异常或者它的子类。
|
绑定
|
单调服务
|
|
BasicHttpBinding绑定
|
客户端不受影响
|
|
不包含可靠消息传输与安全的WSHttpBinding绑定
|
客户端不受影响
|
|
具有安全性的WSHttpBinding绑定
|
通道错误，客户端无法继续发出调用
|
|
不包含可靠消息传输的NetTcpBinding或NetNamedPipeBinding绑定
|
通道错误，客户端无法继续发出调用
|
|
具有可靠消息传输的WSHttpBinding绑定或NetTcpBinding绑定
|
客户端不受影响
|
如果是在会话服务中，则单向操作抛出的异常都会影响到客户端，只不过如果使用的绑定不相同，则抛出的异常会有所区别。
对于单例服务而言，无会话的单例服务与单调服务相似，具有会话的单例服务则与会话服务相似。
回调回调机制如图所示：
回
调机制尤其适用于事件。在WCF中，BasicHttpBinding或WSHttpBinding绑定并不支持回调，因为它们不支持双向通信。
NetTcpBinding和NetNamedPipeBinding绑定以及WSDualHttpBinding绑定支持回调操作。
定义回调契约
一个服务契约最多只能包含一个回调契约。通过ServiceContract特性，可以指定回调契约：
interface ISomeCallbackContract
{
[OperationContract]
void OnCallback( );
}
[ServiceContract(CallbackContract = typeof(ISomeCallbackContract))]
interface IMyContract
{
[OperationContract]
intDoSomething( );
}
回调契约无须标记ServiceContract特性，但是在回调契约中必须为服务的操作标记OperationContract特性。
在导入回调契约的元数据中，回调契约以Callback结尾。为简便起见，我们在定义回调契约时，最好以Callback为后缀。
为了托管一个回调对象，客户端需要实例化回调对象，然后通过它创建一个上下文对象：
class MyCallback : IMyContractCallback
{
public void OnCallback( )
{...}
}
IMyContractCallback callback = new MyCallback( );
InstanceContext context = new InstanceContext(callback);
假定客户端的代理类为MyContractClient，则在客户端就可以通过上下文对象获得代理对象：
MyContractClient proxy = new MyContractClient(context);
注
意，如果使用了回调契约，则客户端生成的代理类必须继承自DuplexClientBase<T>代理类，这是一个专门的支持双向通信的代理
类。注意，该类的构造函数参数既可以接收InstanceContext类型的上下文对象，也可以接收object类型的回调契约对象。
然而，如果是通过SvcUtil或Visual Studio 2005生成的代理，却不能使用接收object类型对象的构造函数，若要创建代理对象，我们必须先创建上下文对象，如前面的代码所示。
我们可以手动修改代理类，添加对它的支持，如下所示：
partial class MyContractClient : DuplexClientBase<IMyContract>,IMyContract
{
public MyContractClient(object callbackInstance) : base(callbackInstance)
{}
//More constructors
public void DoSomething( )
{
Channel.DoSomething( );
}
}
class MyClient : IMyContractCallback,IDisposable
{
MyContractClient m_Proxy;
public void CallService( )
{
m_Proxy = new MyContractClient(this);
m_Proxy.DoSomething( );
}
public void OnCallback( )
{...}
public void Dispose( )
{
m_Proxy.Close( );
}
}
注意，上述的代码中直接由客户端实现了回调契约，这是一种比较常见的实现方式。
客户端通过回调传递给服务端的消息包含了回调契约终结点的引用。在服务端，可以通过OperationContext类的泛型方法GetCallbackChannel<T>()获得。如下所示：
ISomeCallbackContract
callback =
OperationContext.Current.
GetCallbackChannel<ISomeCallbackContract>( );
服务对回调的调用可能会产
生死锁。例如，当客户端执行服务操作时，向客户端发出的调用会阻塞服务端进程，以等待服务操作执行完毕。而在该服务操作中，又获得了回调契约对象的引用
（或者获得保存的回调契约副本），并执行回调操作。由于服务类被配置为单线程访问，则服务实例是与锁相关联的。如果回调对象也需要返回同一个锁的所有权，
简单的说，就是指当回调的应答消息也需要获得与服务实例关联的相同的锁时，就会导致死锁。因为此时服务线程已经被阻塞，服务操作正在等待回调操作执行完
毕，而回调操作却又在等待服务释放锁，自然会产生锁的争用。
解决死锁的办法有三个，一个是将服务配置为允许多线程访问，但这会增加服务开发者管理多线程的负担。第二个方案是将回调设置为重入（Reentrancy），如下所示：
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]
class MyService : IMyContract
{
public void DoSomething( )
{
IMyContractCallback callback = OperationContext.Current.
GetCallbackChannel<IMyContractCallback>( );
callback.OnCallback( );
}
}
所
谓“重入”，是指对同步域拥有独占访问权的线程A调用了同步域之外对象的方法，此时，另外的线程B若要访问该同步域，则线程A将释放对同步域的锁，允许线
程B进入。直到线程B执行完毕并释放对同步域的锁后，线程A将重新进入该同步域。配置回调为重入时，因为服务对象是与线程关联的，属于同步域的对象，而回
调对象则属于同步域之外的对象。由于服务被配置为重入，则服务调用回调引用时会释放锁。然后将回调返回给客户端，控制权则返回给服务，服务会重入并重新获
取锁。这样就解决了死锁的问题。
第三种方案则是将回调操作设置为单向操作。此时，回调调用不会产生应答消息，服务操作一旦执行了回调操作，就会继续执行，回调对象不会争用与服务实例关联的锁，从而解决了死锁问题。
interface IMyContractCallback
{
[OperationContract(IsOneWay = true)]
void OnCallback( );
}
在
使用回调对象时，需要考虑到客户端代理可能会被关闭，如果此时调用回调，就会引发一个ObjectDisposedException异常。“因此，对于
客户端而言，当它不再需要接收回调或者客户端应用程序已经关闭时，最好能够通知服务。”本书给出了解决这一问题的方法，就是为服务契约增加两个操作
Connect()与Disconnect()。其中，Disconnect()正是起到了通知服务的作用，它在客户端代理关闭的情况下，可以将当前的回
调对象引用从列表中移除。至于Connect()方法则是出于对称的目的而引入，但引入它还有一个好处是，它可以使得客户端能够多次地连接或断开。实现
Connect()与Disconnect()方法的代码如下：
static List<IMyContractCallback> m_Callbacks = new List<IMyContractCallback>( );
public void Connect( )
{
IMyContractCallback callback = OperationContext.Current.
GetCallbackChannel<IMyContractCallback>( );
if(m_Callbacks.Contains(callback) == false)
{
m_Callbacks.Add(callback);
}
}
public void Disconnect( )
{
IMyContractCallback callback = OperationContext.Current.
GetCallbackChannel<IMyContractCallback>( );
if(m_Callbacks.Contains(callback) == true)
{
m_Callbacks.Remove(callback);
}
else
{
throw new InvalidOperationException("Cannot find callback");
}
}
单
调服务与单例服务非常适合使用这种方式维持回调对象引用。会话服务则没有必要。“但是，如果会话服务为了让其它宿主端或跨会话访问，而将它的回调引用保存
在某个全局变量中，就必须添加Disconnect()方法，以达到移除回调引用的目的，因为在调用Dispose()期间不能使用回调引用。”
DuplexClientBase<T>类并没有为回调契约提供类型安全性，也没有对服务契约与回调契约之间的约束关系进行验证。因此，本书还提供了DuplexClientBase<T,C>类，通过反射、泛型等技术对其提供类型安全。
与ChannelFactory<
T>类相似，WCF同样提供了DuplexChannelFactory<T>类，它被用于通过编程方式设置双向代理。同样的，
DuplexChannelFactory<T>类仍然缺乏对回调契约的类型安全。因此，本书提供了
DuplexChannelFactory<T,C>类，可以弥补DuplexChannelFactory<T>类的不足。
回调契约仍然具有继承的层级。书中讲述了很多，其实一言以蔽之，就是要求回调契约的层级与服务契约的层级保持一致。此外，服务自身还可以实现回调契约。
由
于使用WSDualHttpBinding绑定执行回调时，需要开通两个HTTP通道，一个用于服务，一个用于回调。通常，WCF为回调通道选择了默认的
80端口，但如果客户端运行了IIS，则可能会占用80端口，就会导致端口的冲突。实际上，我们可以为回调通道指定任何可用的端口，例如，我们可以通过配
置文件为客户端指定基地址。然而，我们指定的端口仍然可能会被占用，只是这种占用的可能性比80端口小。为了避免潜在的端口冲突，同时简化程序员的工作，
最好的办法是自动分配一个可用的端口。本书定义了WsDualProxyHelper静态辅助类，能够将客户端基地址设置为任意的可用端口。定义如下：
public static class WsDualProxyHelper
{
public static void SetClientBaseAddress<T>(DuplexClientBase<T> proxy,int port)
where T : class
{
WSDualHttpBinding binding = proxy.Endpoint.Binding as WSDualHttpBinding;
Debug.Assert(binding != null);
binding.ClientBaseAddress = new Uri("http://localhost:"+ port + "/");
}
public static void SetClientBaseAddress<T>(DuplexClientBase<T> proxy)
where T : class
{
lock(typeof(WsDualProxyHelper))
{
int portNumber = FindPort( );
SetClientBaseAddress(proxy,portNumber);
proxy.Open( );
}
}
internal static int FindPort( )
{
IPEndPoint endPoint = new IPEndPoint(IPAddress.Any,0);
using(Socket socket = new Socket(AddressFamily.InterNetwork,
SocketType.Stream,
ProtocolType.Tcp))
{
socket.Bind(endPoint);
IPEndPoint local = (IPEndPoint)socket.LocalEndPoint;
return local.Port;
}
}
}
WsDualProxyHelper类的使用如下所示：
class MyClient : IMyContractCallback
{...}
IMyContractCallback callback = new MyClient( );
InstanceContext context = new InstanceContext(callback);
MyContractClient proxy = new MyContractClient(context);
WsDualProxyHelper.SetClientBaseAddress(proxy);
本文已在IT168发表：http://tech.it168.com/msoft/2007-11-19/200711190953995.shtml