我有一个Windows服务，需要一堆文件的名称，做业务对他们（压缩/解压缩，更新数据库等）。根据大小和发送到服务文件数的操作需要时间。

I have a Windows Service that takes the name of a bunch of files and do operations on them (zip/unzip, updating db etc). The operations can take time depending on size and number of files sent to the service.

（1），其将请求发送到该服务的模块会一直等到文件进行处理。我想知道是否有一种方法可以提供当处理完文件将通知调用模块服务的回调。请注意，多个模块可以同时处理文件调用的服务，这样的服务需要提供某种TASKID我猜的。

(1) The module that is sending a request to this service waits until the files are processed. I want to know if there is a way to provide a callback in the service that will notify the calling module when it is finished processing the files. Please note that multiple modules can call the service at a time to process files so the service will need to provide some kind of a TaskId I guess.

（2）如果服务方法被调用，并正在运行，另外调用了相同的服务，那么这将如何呼叫处理（我觉得只有一个线程asociated的服务）。我已经看到，当服务需要时间在处理的方法，与该服务相关联的线程开始增加。

(2) If a service method is called and is running and another call is made to the same service, then how will that call be processed(I think there is only one thread asociated with the service). I have seen that when the service is taking time in processing a method, the threads associated with the service begin to increase.

推荐答案

WCF确实提供双工绑定，让你可以指定一个回调的合同，因此该服务可以回调到调用客户端通知。

WCF does indeed offer duplex bindings which allow you to specify a callback contract, so that the service can call back to the calling client to notify.

不过，在我看来，这种机制是相当片状，并没有真正被推荐。

However, in my opinion, this mechanism is rather flaky and not really to be recommended.

在这种情况下，当调用会导致一个相当长的运行操作的情况发生，我会做这样的事情：

In such a case, when the call causes a fairly long running operation to happen, I would do something like this:

如果你想坚持到HTTP / NetTcp绑定，我想：

If you want to stick to HTTP/NetTcp bindings, I would:

落的服务请求，然后再放手 - 这将是一个单向通话，你只要落你想都做了​​什么，然后你的客户做 有一个状态调用客户端可以在给定的时间后，打电话找了请求的结果是否是准备现在 ，如果他们是，应该有第三个服务呼叫以检索结果

因此​​，在你的情况，你可以下车的要求，压缩一些文件。该服务将熄灭，并做其工作，并由此产生ZIP存储在一个临时位置。再后来在客户端可以检查以查看的邮政编码是否准备好了，如果是，则检索它。

So in your case, you could drop off the request to zip some files. The service would go off and do its work and store the resulting ZIP in a temporary location. Then later on the client could check to see whether the ZIP is ready, and if so, retrieve it.

这工作更好过一个消息队列（MSMQ），这是每个Windows服务器计算机present（但不是很多人似乎知道它或使用它）：

This works even better over a message queue (MSMQ) which is present in every Windows server machine (but not a lot of people seem to know about it or use it):

您的客户端脱落在请求队列请求 的服务侦听的请求队列，并请求后获取请求并执行它的工作原理 在轮到你来电者正在侦听该服务可以再后的结果，以结果队列，

看看如何做到这一切有效地通过阅读优秀的MSDN文章 Foudnations：建立一个队列WCF响应服务 - ！强烈推荐

Check out how to do all of this efficiently by reading the excellent MSDN article Foudnations: Build a queue WCF Response Service - highly recommended!

一个消息队列基础的系统趋于更加稳定，不易出错，一个duplex- /回调合同为基础的系统，在我看来。

A message-queue based systems tends to be much more stable and less error-prone that a duplex-/callback-contract based system, in my opinion.