在 Windows 进程激活服务中承载
Windows 进程激活服务（WAS）管理包含托管 Windows Communication Foundation （WCF） 服务的应用程序的工作进程的激活和生存期。 WAS 进程模型通过删除对 HTTP 的依赖项来通用化 HTTP 服务器的 IIS 6.0 进程模型。 这允许 WCF 服务在支持基于消息的激活的托管环境中同时使用 HTTP 和非 HTTP 协议（如 Net.TCP），并提供在给定计算机上托管大量应用程序的功能。
有关生成在 WAS 托管环境中运行的 WCF 服务的详细信息，请参阅 如何：在 WAS 中托管 WCF 服务。
WAS 进程模型提供了多种功能，使应用程序能够以更可靠、更易于管理的方式进行托管，并有效地使用资源：
基于消息的应用程序激活和辅助进程应用程序会动态地启动和停止，以响应使用 HTTP 和非 HTTP 网络协议送达的传入工作项。
可靠的应用程序和辅助进程回收可以使应用程序保持良好的运行状况。
集中式应用程序配置和管理。
允许应用程序利用 IIS 进程模型，而无需完整 IIS 安装的部署占用空间。 Windows Server AppFabric 与 IIS 7.0 和 Windows 进程激活服务（WAS）配合使用，为 NET4 WCF 和 WF 服务提供丰富的应用程序托管环境。 这些优势包括进程生命周期管理、进程回收、共享托管、快速故障保护、进程孤立、按需激活和运行状况监视。 有关详细信息，请参阅 AppFabric 托管功能 和 AppFabric 托管概念。
WAS 寻址模型的元素
应用程序具有统一资源标识符（URI）地址，这些地址是服务器管理的生存期和执行环境的代码单元。 单个 WAS 服务器实例可以驻留在许多不同的应用程序中。 服务器将应用程序组织成称为 站点的组。 在站点中，应用程序以分层方式排列，以反映充当其外部地址的 URI 的结构。
应用程序地址有两个部分：基本 URI 前缀和特定于应用程序的相对地址（路径），在联接在一起时为应用程序提供外部地址。 基本 URI 前缀是从站点绑定构造的，用于站点下的所有应用程序。 然后，通过采用特定于应用程序的路径片段（例如“/applicationOne”）并将其追加到基本 URI 前缀（例如“net.tcp：//localhost”）来构造应用程序地址，以到达完整的应用程序 URI。
下表演示了具有 HTTP 和非 HTTP 站点绑定的 WAS 站点的几种可能寻址方案。
| 场景 | 网站绑定 | 应用程序路径 | 基应用程序 URI |
|---|---|---|---|
| 仅限 HTTP | http： *：80：* | /appTwo | http://localhost/appTwo/ |
| HTTP 和非 HTTP | http： *：80：* net.tcp: 808:* |
/appTwo | http://localhost/appTwo/net.tcp://localhost/appTwo/ |
| 仅非 HTTP | net.pipe: * | /appThree | net.pipe://appThree/ |
还可以处理应用程序中的服务和资源。 在应用程序中，应用程序资源相对于基本应用程序路径进行寻址。 例如，假设在名为 contoso.com 的机器上有一个站点，该站点针对 HTTP 和 Net.TCP 协议进行了绑定。 此外，假设站点包含一个位于 /Billing 的应用程序，该应用程序在 GetOrders.svc 中公开服务。 然后，如果 GetOrders.svc 服务公开了一个相对地址为 SecureEndpoint 的终结点，那么该服务终结点将会通过以下两个 URI 公开：
http://contoso.com/Billing/GetOrders.svc/SecureEndpointnet.tcp://contoso.com/Billing/GetOrders.svc/SecureEndpoint
WAS 运行库
应用程序组织到站点，以便进行寻址和管理。 在运行时，应用程序也会分组到应用程序池中。 应用程序池可以容纳来自不同站点的许多不同应用程序。 应用程序池中的所有应用程序共享一组常见的运行时特征。 例如，它们都在同一版本的公共语言运行时（CLR）下运行，它们都共享一个通用进程标识。 每个应用程序池对应于工作进程实例（w3wp.exe）。 在共享应用程序池内运行的每个托管应用程序都通过 CLR AppDomain 与其他应用程序隔离。