WCF与Web Service不同的是,当我们定义了服务契约的操作时,不管是通过ChannelFactory创建服务代理对象,还是通过SvcUtil的默认方式生成服务代理对象,客户端在调用这些代理对象时,都无法直接实现异步方式的调用。例如,对于如下的服务操作定义:
在调用代理对象的方法时,我们无法找到对应于TransferDocument()操作的BeginTransferDocument()和EndTransferDocument()异步方法。
这样的设计使得我们无法通过编程方式异步地调用服务的操作,除非我们在定义服务接口时,直接加入相关操作的异步方法。然而,这又直接导致了服务的设计与方法调用方式之间的耦合。一个好的框架设计要素在于,不管客户端的调用方式(同步或者异步),服务的设计与实现应该是一致的。对于服务的设计者而言,在设计之初,就不应该去考虑服务的调用者调用的方式。换言之,服务操作究竟是否采用异步方式,应该由客户端的调用者决定。因此,所有与异步调用相关的内容应该只与客户端相关。WCF遵循了这一规则。
在我编写的应用程序中,会暴露一个传送文档文件的服务操作。我并不知道也并不关心调用该操作的客户端是否采用异步方式。因此,如上所述的服务操作定义是完全正确的。
那么,客户端究竟应该如何执行异步调用呢?如果采用编程方式获得服务代理对象,这一问题会变得比较糟糕。因为我将服务契约的定义单独形成了一个程序集,并在客户端直接引用了它。然而,在这样的服务契约程序集中,是没有包含异步方法的定义的。因此,我需要修改在客户端的服务定义,增加操作的异步方法。这无疑为服务契约的重用带来障碍。至少,我们需要在客户端维持一份具有异步方法的服务契约。
所幸,在客户端决定采用异步方式调用我所设计的服务操作时,虽然需要修改客户端的服务契约接口,但并不会影响服务端的契约定义。因此,服务端的契约定义可以保持不变,而在客户端则修改接口定义如下:
注意,在 BeginTransferDocument()方法上,必须在OperationContractAttribute中将AsyncPattern属性值设置为true,因为它的默认值为false。
调用方式如下:
如果采用SvcUtil生成客户端代理文件,可以有更好的方式实现异步,也就是使用SvcUtil的/async开关,例如:
唯一不足的是,它会不分青红皂白,为所有服务操作都生成对应的异步方法。这样的做法未免过于武断。
合理地利用服务的异步调用,可以有效地提高系统性能,合理分配任务的执行。特别对于UI应用程序而言,可以提高UI的响应速度,改善用户体验。在我编写的应用程序中,下载的文件如果很大,就有必要采用异步方式。
对于异步调用的完成,虽然WCF提供了诸如阻塞、 等待 和 轮询 等机制,但最好的方式还是使用回调。也就是利用Begin方法参数中的AsyncCallback对象。这是一个委托对象,它的定义如下所示:
利用异步方式执行服务操作,使得服务在执行过程中不会阻塞主线程,当方法执行完成后,通过AsyncCallback回调对应的方法,可以通知客户端服务执行完毕。例如:
在调用 BeginTransferDocument()方法之后,主线程不会被阻塞,仍然可以继续执行其它工作。而当服务方法执行完毕之后,会自动调用回调方法,执行方法中的内容。
上述实现存在一个问题,就是对于lbMessage控件的操作。由于回调方法并非运行在主线程中,如果回调方法需要更新与异步调用结果相关的界面,例如本例中的lbMessage控件,则需要将回调的调用封送(Marshal)到当前主程序界面的同步上下文中。我们可以使用SynchronizationContext以及它的SendOrPostCallback委托,对调用进行封送:
则回调方法修改为:
在调用异步方法时,由于对Begin TransferDocument() 和End TransferDocument() 方法的调用可能会在不同的方法体中,因而我将服务代理对象定义为private字段。如果希望将服务对象定义为一个局部变量,可以在调用 Begin TransferDocument()方法时,将代理对象传递到方法的asyncState参数中,然后在调用 End TransferDocument()方法之前,通过IAsyncResult获得准确的服务代理对象:
将m_service作为asyncState对象传入之后,在调用 End TransferDocument()方法之前,就可以根据它先获得服务代理对象:
(转自博客园:张逸的博客,http://www.cnblogs.com/wayfarer/archive/2007/11/09/954256.html)
[OperationContract]
Stream TransferDocument(Document document);
Stream TransferDocument(Document document);
在调用代理对象的方法时,我们无法找到对应于TransferDocument()操作的BeginTransferDocument()和EndTransferDocument()异步方法。
这样的设计使得我们无法通过编程方式异步地调用服务的操作,除非我们在定义服务接口时,直接加入相关操作的异步方法。然而,这又直接导致了服务的设计与方法调用方式之间的耦合。一个好的框架设计要素在于,不管客户端的调用方式(同步或者异步),服务的设计与实现应该是一致的。对于服务的设计者而言,在设计之初,就不应该去考虑服务的调用者调用的方式。换言之,服务操作究竟是否采用异步方式,应该由客户端的调用者决定。因此,所有与异步调用相关的内容应该只与客户端相关。WCF遵循了这一规则。
在我编写的应用程序中,会暴露一个传送文档文件的服务操作。我并不知道也并不关心调用该操作的客户端是否采用异步方式。因此,如上所述的服务操作定义是完全正确的。
那么,客户端究竟应该如何执行异步调用呢?如果采用编程方式获得服务代理对象,这一问题会变得比较糟糕。因为我将服务契约的定义单独形成了一个程序集,并在客户端直接引用了它。然而,在这样的服务契约程序集中,是没有包含异步方法的定义的。因此,我需要修改在客户端的服务定义,增加操作的异步方法。这无疑为服务契约的重用带来障碍。至少,我们需要在客户端维持一份具有异步方法的服务契约。
所幸,在客户端决定采用异步方式调用我所设计的服务操作时,虽然需要修改客户端的服务契约接口,但并不会影响服务端的契约定义。因此,服务端的契约定义可以保持不变,而在客户端则修改接口定义如下:
[ServiceContract]
public interface IDocumentsExplorerService
{
[OperationContract]
Stream TransferDocument(Document document);
[OperationContract(AsyncPattern = true )]
IAsyncResult BeginTransferDocument(Document document,
AsyncCallback callback, object asyncState);
Stream EndTransferDocument(IAsyncResult result);
}
public interface IDocumentsExplorerService
{
[OperationContract]
Stream TransferDocument(Document document);
[OperationContract(AsyncPattern = true )]
IAsyncResult BeginTransferDocument(Document document,
AsyncCallback callback, object asyncState);
Stream EndTransferDocument(IAsyncResult result);
}
注意,在 BeginTransferDocument()方法上,必须在OperationContractAttribute中将AsyncPattern属性值设置为true,因为它的默认值为false。
调用方式如下:
BasicHttpBinding binding
=
new
BasicHttpBinding();
binding.SendTimeout = TimeSpan.FromMinutes( 10 );
binding.TransferMode = TransferMode.Streamed;
binding.MaxReceivedMessageSize = 9223372036854775807 ;
EndpointAddress address = new EndpointAddress
( " http://localhost:8008/DocumentExplorerService " );
ChannelFactory < IDocumentsExplorerService > factory =
new ChannelFactory < IDocumentsExplorerService > (binding,address);
m_service = factory.CreateChannel();
……
IAsyncResult result = m_service.BeginTransferDocument(doc, null , null );
result.AsyncWaitHandle.WaitOne();
Stream stream = m_service.EndTransferDocument(result);
binding.SendTimeout = TimeSpan.FromMinutes( 10 );
binding.TransferMode = TransferMode.Streamed;
binding.MaxReceivedMessageSize = 9223372036854775807 ;
EndpointAddress address = new EndpointAddress
( " http://localhost:8008/DocumentExplorerService " );
ChannelFactory < IDocumentsExplorerService > factory =
new ChannelFactory < IDocumentsExplorerService > (binding,address);
m_service = factory.CreateChannel();
……
IAsyncResult result = m_service.BeginTransferDocument(doc, null , null );
result.AsyncWaitHandle.WaitOne();
Stream stream = m_service.EndTransferDocument(result);
如果采用SvcUtil生成客户端代理文件,可以有更好的方式实现异步,也就是使用SvcUtil的/async开关,例如:
svcutil
/
async http:
//
localhost:8008/DocumentExplorerService
唯一不足的是,它会不分青红皂白,为所有服务操作都生成对应的异步方法。这样的做法未免过于武断。
合理地利用服务的异步调用,可以有效地提高系统性能,合理分配任务的执行。特别对于UI应用程序而言,可以提高UI的响应速度,改善用户体验。在我编写的应用程序中,下载的文件如果很大,就有必要采用异步方式。
对于异步调用的完成,虽然WCF提供了诸如阻塞、 等待 和 轮询 等机制,但最好的方式还是使用回调。也就是利用Begin方法参数中的AsyncCallback对象。这是一个委托对象,它的定义如下所示:
public
delegate
void
AsyncCallback(IAsyncResult ar);
利用异步方式执行服务操作,使得服务在执行过程中不会阻塞主线程,当方法执行完成后,通过AsyncCallback回调对应的方法,可以通知客户端服务执行完毕。例如:
//
Invoke it Asynchronously
m_service.BeginTransferDocument(m_doc,OnTransferCompleted, null );
// Do some work;
// callback method
void OnTransferCompleted(IAsyncResult result)
{
Stream stream = m_service.EndTransferDocument(result);
result.AsyncWaitHandle.Close();
lbMessage.Text = string .Format( " The file {0} had been transfered sucessfully. " ,
m_doc.FileName);
}
m_service.BeginTransferDocument(m_doc,OnTransferCompleted, null );
// Do some work;
// callback method
void OnTransferCompleted(IAsyncResult result)
{
Stream stream = m_service.EndTransferDocument(result);
result.AsyncWaitHandle.Close();
lbMessage.Text = string .Format( " The file {0} had been transfered sucessfully. " ,
m_doc.FileName);
}
在调用 BeginTransferDocument()方法之后,主线程不会被阻塞,仍然可以继续执行其它工作。而当服务方法执行完毕之后,会自动调用回调方法,执行方法中的内容。
上述实现存在一个问题,就是对于lbMessage控件的操作。由于回调方法并非运行在主线程中,如果回调方法需要更新与异步调用结果相关的界面,例如本例中的lbMessage控件,则需要将回调的调用封送(Marshal)到当前主程序界面的同步上下文中。我们可以使用SynchronizationContext以及它的SendOrPostCallback委托,对调用进行封送:
public
ExplorerClientForm()
{
InitializeComponent();
m_synchronizationContext = SynchronizationContext.Current;
}
private SynchronizationContext m_synchronizationContext;
{
InitializeComponent();
m_synchronizationContext = SynchronizationContext.Current;
}
private SynchronizationContext m_synchronizationContext;
则回调方法修改为:
//
callback method
void OnTransferCompleted(IAsyncResult result)
{
Stream stream = m_service.EndTransferDocument(result);
result.AsyncWaitHandle.Close();
SendOrPostCallback callback = delegate
{
lbMessage.Text = string .Format( " The file {0} had been transfered sucessfully. " ,
m_doc.FileName);
};
m_synchronizationContext.Send(callback, null );
}
void OnTransferCompleted(IAsyncResult result)
{
Stream stream = m_service.EndTransferDocument(result);
result.AsyncWaitHandle.Close();
SendOrPostCallback callback = delegate
{
lbMessage.Text = string .Format( " The file {0} had been transfered sucessfully. " ,
m_doc.FileName);
};
m_synchronizationContext.Send(callback, null );
}
在调用异步方法时,由于对Begin TransferDocument() 和End TransferDocument() 方法的调用可能会在不同的方法体中,因而我将服务代理对象定义为private字段。如果希望将服务对象定义为一个局部变量,可以在调用 Begin TransferDocument()方法时,将代理对象传递到方法的asyncState参数中,然后在调用 End TransferDocument()方法之前,通过IAsyncResult获得准确的服务代理对象:
m_service.BeginTransferDocument(m_doc,OnTransferCompleted,m_service);
将m_service作为asyncState对象传入之后,在调用 End TransferDocument()方法之前,就可以根据它先获得服务代理对象:
IDocumentsExplorerService m_service
=
result.AsyncState
as
IDocumentsExplorerService;
Stream stream = m_service.EndTransferDocument(result);
// rest codes
Stream stream = m_service.EndTransferDocument(result);
// rest codes
(转自博客园:张逸的博客,http://www.cnblogs.com/wayfarer/archive/2007/11/09/954256.html)