.net 我可以使用WCF替换当前的Web服务和窗口服务组合吗？

关于我所面临的情况，我需要一些建议。目前的安排，我一直致力于改善只是不适合我，我觉得有一个更好的方式来做到这一点。我读的关于WCF的书越多，我就越觉得它可能就是我想要的

现在，我有一个asp.net客户端、一个.net web服务、一个windows服务、一个ms sql数据库和一个用于将一组“项目”文件处理为最终文件的第三方应用程序。由于第三方应用程序一次只能处理一个“项目”，因此已安排web服务、窗口服务和数据库的组合来为第三方应用程序创建作业队列管理器

客户端向web服务发送包含多个子文件的zip“项目”文件。web服务向数据库添加一个新的“项目”行，生成一个唯一的作业id。使用作业id作为文件夹名称，将zip文件扩展到服务器上的文件夹位置。然后，web服务将作业id返回给客户端。客户端将使用此id轮询web服务，以了解提交的作业的状态。作业完成后，客户端将请求处理后的文件

windows服务每x分钟轮询一次数据库。如果存在新作业，服务将提取最旧的作业并将其发送给第三方应用程序进行处理。如果处理成功，窗口服务将更新数据库中的项目行，并标记作业已完成。窗口服务将继续处理数据库中任何未完成的作业，直到没有其他作业为止。当它停止查找任何作业时，它将休眠x分钟，然后再次轮询数据库

---

我不喜欢窗口服务必须轮询数据库这一事实。如果只提交了一个作业，客户端将必须等待窗口服务轮询，然后在处理“项目”时等待。似乎WCF可以通过InstanceContextMode.Single和ConcurrencyMode.Multiple的组合来组合web和窗口服务。到目前为止，我还找不到任何文章或例子能为我指明正确的方向。是否可以利用WCF更好地完成当前安排的作业队列逻辑？一如既往，我们非常感谢您的帮助。

我知道，这并不能回答您的问题，但如果您对当前解决方案唯一关心的是处理单个作业之前的延迟，那么为什么不简单地将轮询间隔缩短到10秒

---

轮询是否有问题，或者只是您不喜欢此解决方案？

我对该解决方案不满意。我一直在考虑用wcf服务取代web服务，以便在大型文件传输中使用通道分块。我希望我可以重新设计窗口服务，并在这个过程中删除它的轮询。目前，当前的体系结构仅由当前的web客户端使用。随着未来系统的上线，它将得到更多的使用。异步处理只是为了限制对第三方应用程序的访问吗？第三方应用程序处理作业需要多长时间？是的，我们必须限制第三方应用程序。对于小型项目，处理过程可能需要一两秒钟。我们预计，未来还需要处理大型项目。