Windows 进程激活服务（WAS）管理包含托管 Windows Communication Foundation （WCF） 服务的应用程序的工作进程的激活和生存期。 WAS 进程模型通过删除对 HTTP 的依赖项来通用化 HTTP 服务器的 IIS 6.0 进程模型。 这允许 WCF 服务在支持基于消息的激活的宿主环境中同时使用 HTTP 和非 HTTP 协议，例如 net.msmq 和 msmq.formatname，并提供在给定计算机上托管大量应用程序的功能。
WAS 包括一个消息队列（MSMQ）激活服务，当一个或多个消息放置在应用程序使用的队列中时，该服务将激活排队的应用程序。 MSMQ 激活服务是默认自动启动的 NT 服务。
有关 WAS 及其优点的详细信息，请参阅 Windows 进程激活服务中的托管。 有关 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 激活服务必须监视其消息的队列。 MSMQ 激活服务启动时，它将枚举配置为从其中接收消息的计算机上所有的公共队列和专用队列，以及监视消息的公共队列和专用队列。 MSMQ 激活服务每隔 10 分钟刷新要监视的队列列表。 在队列中找到消息时，激活服务会将队列名称与 net.msmq 绑定的最长匹配应用程序 URI 匹配，并激活应用程序。
注释
被激活的应用程序必须与队列名称的前缀匹配（最长的匹配）。
例如，队列名称为：msmqWebHost/orderProcessing/service.svc。 如果 Application 1 具有包含 service.svc 的虚拟目录 /msmqWebHost/orderProcessing，并且 Application 2 具有虚拟目录 /msmqWebHost，其下有 orderProcessing.svc，则应用程序 1 将激活。 如果删除了应用程序 1，则激活应用程序 2。
注释
创建队列后，发送到队列的任何消息不会激活应用程序，直到 MSMQ 激活服务刷新队列列表，这最多会在队列创建后10分钟发生。 重启激活服务也会刷新队列列表。
专用队列和公共队列对寻址的影响
MSMQ 激活服务不区分队列监视是专用的还是公共的。 因此，不能有具有相同名称的公共队列和专用队列。 如果有，则 Web 承载的应用程序可能被激活，从这两个队列之一中进行读取。
用于激活的队列配置
MSMQ 激活服务作为网络服务运行。 它是监视队列以激活应用程序的服务。 若要从队列激活应用程序，队列必须提供网络服务访问权限，才能查看其访问控制列表中的消息（ACL）。
病毒消息
WCF 中的有害消息处理由通道处理，该通道不仅检测到消息已中毒，而且根据用户配置选择处置。 因此，队列中仅有一条消息。 Web 承载的应用程序可连续多次中止并将该消息移到重试队列中。 在重试周期延迟决定的某个时间点，消息将从重试队列移动到主队列以重试。 但是这要求排队通道应是活动的。 如果应用程序由 WAS 回收，则消息将保留在重试队列中，直到另一条消息到达主队列以激活排队的应用程序。 在这种情况下，解决方法是将消息手动从重试队列移回主队列以重新激活应用程序。
子队列和系统队列注意事项
不能基于系统队列（如系统级死信队列）或子队列（如病毒子队列）中的消息激活 WAS 承载的应用程序。 这是此版本的产品的一个限制。