我需要一點關於我面臨的情況的建議。目前我一直致力於改善的安排並不適合我，我覺得有更好的方法去做。我對WCF的瞭解越多，我越覺得它可能是我正在尋找的。我可以使用WCF替換當前的Web Service和Window Service組合嗎？
現在，我有一個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以更好的方式完成當前安排的作業隊列邏輯嗎？一如往常，任何幫助都不勝感激。
異步處理僅限制對第三方應用程序的訪問權限嗎？第三方應用程序處理工作需要多長時間？ – 2010-04-23 05:06:05
是的，我們必須爲第三方應用程序加油。對於小型項目，處理可能需要一兩秒鐘。我們預計未來還需要處理大型項目。 – 2010-04-26 17:04:06