Windows Process Activation Service（WAS）會管理承載 Windows Communication Foundation（WCF）服務的工作進程的啟用和生命週期。 WAS 進程模型藉由移除 HTTP 上的相依性，將 HTTP 伺服器的 IIS 6.0 進程模型一般化。 這可讓 WCF 服務在支援訊息型啟用的裝載環境中同時使用 HTTP 和非 HTTP 通訊協定，例如 net.msmq 和 msmq.formatname，並提供在指定電腦上裝載大量應用程式的能力。
WAS 包含消息佇列 （MSMQ） 啟用服務，會在應用程式所使用的其中一個佇列中放置一或多個訊息時啟動佇列應用程式。 MSMQ 啟用服務是預設自動啟動的NT服務。
如需 WAS 及其優點的詳細資訊，請參閱 在 Windows Process Activation Service 中裝載。 如需 MSMQ 的詳細資訊，請參閱 佇列概觀。
WAS 中的佇列位址處理
WAS 應用程式具有統一資源識別碼 （URI） 位址。 應用程式位址有兩個部分：基底 URI 前置詞和應用程式特定的相對位址（路徑）。 這兩個部分會在聯結在一起時為應用程式提供外部位址。 基底 URI 前置詞是從網站系結建構而用於網站下的所有應用程式，例如“net.msmq：//localhost”、“msmq.formatname：//localhost”或 “net.tcp：//localhost”。 接著，應用程式位址會採用應用程式特定的路徑片段（例如 “/applicationOne”），並將其附加至基底 URI 前置詞，以抵達完整的應用程式 URI，例如“net.msmq：//localhost/applicationOne”。
MSMQ 啟用服務使用應用程式 URI 來匹配其必須監視訊息的佇列。 當 MSMQ 啟用服務啟動時，它會列舉已在電腦上設定的所有公用和私人佇列，以接收並監視這些佇列中的訊息。 每10分鐘，MSMQ 啟用服務會重新整理要監視的佇列清單。 在佇列中找到訊息時，啟用服務會將佇列名稱與 net.msmq 系結最長相符的應用程式 URI 相符，並啟動應用程式。
備註
正在啟動的應用程式必須與佇列名稱的前綴最長匹配。
例如，佇列名稱為：msmqWebHost/orderProcessing/service.svc。 如果 Application 1 具有具有 service.svc 的虛擬目錄 /msmqWebHost/orderProcessing，而 Application 2 具有虛擬目錄 /msmqWebHost，且其下有 orderProcessing.svc，則會啟動 Application 1。 如果刪除應用程式 1，則會啟動應用程式 2。
備註
建立佇列後，傳送到該佇列的任何訊息暫時不會啟動應用程式。只有在 MSMQ 啟動服務重新整理佇列清單後，才會啟動應用程式，這個過程最多需要 10 分鐘。 重新啟動啟用服務也會重新整理佇列清單。
私人和公用佇列對網路尋址的影響
MSMQ 啟用服務不會區分私人和公用佇列監視。 因此，您無法使用相同名稱建立公用和私人佇列。 如果您這麼做，Web 裝載的應用程式可能會從任一個佇列中啟動讀取。
啟用的佇列組態
MSMQ 啟用服務會以網路服務的形式執行。 這是監視佇列以啟動應用程式的服務。 若要從佇列啟動應用程式，佇列必須提供網路服務存取權，才能查看其訪問控制清單中的訊息（ACL）。
有害傳訊
WCF 中的有害訊息處理是由通道處理，它不僅偵測到訊息已有害，而且會根據使用者設定選取處置。 因此，佇列中有單一訊息。 網路託管的應用程式會多次中止，並將訊息移至重試佇列中。 在重試周期延遲指定的時間點，訊息會從重試佇列移至主要佇列，然後再試一次。 但這需要佇列通道處於作用中狀態。 如果 WAS 回收應用程式，則訊息會保留在重試佇列中，直到另一則訊息到達主要佇列以啟動佇列應用程式為止。 在此情況下，因應措施是手動將訊息從重試佇列移回主要佇列，以重新啟用應用程式。
子佇列和系統佇列注意事項
無法根據系統佇列中的訊息來啟動 WAS 裝載的應用程式，例如全系統寄不出的信件佇列或子佇列，例如有害子佇列。 這是此產品版本的限制。