我們計劃在Windows/.NET 3.5有許多需要在後臺運行的「服務」上運行的系統。有些將始終保持活躍，但有些只會偶爾被調用，並且可以根據需要進行調整。最佳主機UI少工藝
據我所看到的，我的選擇是： - （？）
分佈式事務不是必需的，它們主要是計算引擎，而不是事務處理器。
有沒有人有所有這些，什麼利弊進一步缺點&可以宣稱對每種技術的工作經驗嗎？
編輯
是假設有在IIS託管代碼，Web服務，WCF（如下指出的）的多種方式，任何其他方面？相對優點/缺點？
WCF感覺就像正確的路要走。還有很多選擇。 WCF提供了許多通信機制和主機環境： WCF在一組API下結合了以下技術： ASMX; WSE; 遠程處理; COM +; MSMQ。 因此，例如，您可以將來自MSMQ的持久性消息用於occassionaly連接的客戶機或通過HTTP傳輸層對SOAP消息進行標準XML編碼。您還可以使用3.5中的新功能，如XML的二進制編碼或HTTP上的JSON編碼。
託管環境包括： 控制檯應用程序 的Windows服務中的IIS 7.0 和Windows Vista或Windows Server 2008上，您可以使用WAS（Windows激活服務） WCF服務託管WCF服務。
不同的託管環境有優點和缺點。我建議你看看MSDN的更多細節（例如http://msdn.microsoft.com/en-us/library/bb332338.aspx）。
因爲WCF涵蓋了很多功能更難以學習比它所取代的技術中的任何一個。從長遠來看，我仍然認爲它是值得的。
這取決於什麼軟件會做什麼，以及如何（如果）用戶或系統需要與它進行交互。根據這些情況，可能會有一個常常被忽視的選項：將其設置爲計劃任務。如果軟件具有某種時間間隔（例如，檢查數據庫中的更改，處理已更改的數據並將其發送到某個地方），那麼這通常是Windows服務的一個非常好的選擇。
如果你有其他系統直接說你的軟件，我會想象在IIS託管的WCF應用程序將是一個相當簡單明瞭的方式。我在當前任務中使用這兩種方法;用於查找和存儲數據的WCF服務以及定期運行數據計算的計劃任務。
計劃任務已上攻一個比別人在一個特定的領域;它僅在運行時使用系統資源。
您提到啓動一個「按需」流程。 WAS - Windows激活服務（有時也稱爲Windows進程激活服務，儘管它永遠不會縮寫爲「WPAS」）是Windows內部提供按需過程激活的東西。它的工作方式 - 當消息到達時，WAS可以啓動一個工作進程來處理消息。在IIS7之前，WAS相當緊密地集成到了IIS中。它主要用於激活進行網絡工作的流程 - 例如ASP.NET工作流程。對於IIS7，WAS是通用的，因此它可以基於非HTTP和HTTP消息激活工作進程。如果您編寫應用程序以通過WCF接收消息，則可以基本上「免費」獲得激活。這適用於HTTP，TCP，MSMQ; SOAP或其他。
與此點播啓動，雖然關鍵的一點是，它是聯繫在一起的通信。事實上，WAS的流程生命週期模型也與通信息息相關。默認情況下，如果一段時間後沒有傳入消息，該進程將被WAS關閉。這可能是也可能不是你想要的。
至於過程託管 - COM +提供了一個託管環境，但其主要目的是用作通信的過程的主機。這可能不適合你。
如果你有計算引擎，你可能只是想運行一個Windows服務。像這樣的服務可以以管理方式或編程方式啓動和停止。在後一種情況下，您可以想象一個WAS激活的工作進程以編程方式啓動一個Windows服務。
您也可以想象編寫一個簡單的Windows服務來監視消息的位置（文件系統，消息隊列等），以及當該文件或消息到達時，Windows服務啓動一個計算引擎進程，它本身就是不是Windows服務，但只是一個過程。
說到MSMQ的 - 這基本上是相同的模型MSMQ觸發器。當消息到達特定隊列時，您可以配置MSMQ以啓動進程。
有很多選擇。
計劃任務可能不會在我們的案例中真正適用的處理將在需求，而不是在一個特定的時間，每天進行，但由於在這裏撫養他們。 – 2009-07-13 13:32:48