上一个系列主要讲述WCF中的序列化与编码，包括不同编码/序列化器选择原则，大数据流操作等等。本篇主要讲述WCF中的服务是如何寄宿的，寄宿环境等等。包括IIS, WAS, NT Service, 桌面应用程序，控制台应用程序。
[第1篇] 基础
一个服务宿主就是用来管理一个WCF服务的生命周期和上下文服务的一个操作系统进程。服务宿主，或者仅称为”宿主”，负责启动和停止WCF服务并提供一些基本的管理函数来控制WCF服务。除了这方面，宿主对运行在它的内存空间里的WCF服务知道的很少。
[第2篇] 在Windows 进程激活服务中寄宿服务
Windows进程激活服务(WAS)是Vista和Windows Server 2008 自带的寄宿基础。先前的特性只在IIS中才有，比如进程激活，回收和身份标识管理，已经加入到WAS中而且支持所有的协议除了HTTP。
WAS允许你在一个不依赖HTTP协议的鲁棒环境中寄宿服务。HTTP协议被广泛部署和理解，但是有一些情况它并不是最好的选择。
[第3篇] 在IIS7中寄宿服务
IIS6在Windows 2003和Windows XP SP2中存在，应用程序池作为一个运行时容器来寄宿应用程序。这允许对启动和关闭的控制，在每一个进程的基础上进行身份认证和回收服务。它原本就提供了跨应用程序的进程隔离功能，这个功能带来了很大的可信赖性。总的来说进程管理是由应用程序池架构处理的。
IIS7在Windows Vista和Windows Server 2008 中存在，进程管理已经实现对多种协议支持并移植到WAS中。ASP.NET也扩展来支持进程激活和WAS中的服务寄宿。
[第4篇]在一个IIS寄宿服务中开启ASMX特性
在WCF之前，ASMX是ASP.NET Web 服务中一个公共处理方式。它对公共Web服务需求提供了出色的支持并通过ASP.NET HTTP管道提供了鲁棒性扩展能力。在WCF中，服务被设计为不需了解它们的寄宿模且独立传输。所以WCF服务不能依赖于HTTP管道内部的实现，比如HTTP.SYS。
[第5篇] 自我寄宿
寄宿WCF服务最常用的环境是IIS或者WAS。在一个公共架构上创建，它们都提供鲁棒性进程控制和生命周期回收服务，还有一个熟悉的管理接口。当IIS架构已经在使用时这是对大多数场景来说最合适的解决方案。
[第6篇]在一个进程中寄宿多个服务
将应用程序功能聚集到正确的服务层次是系统设计的一个必须元素。创建一个有很多接口的系统，这个系统也会变得很令人迷惑。创建只有很多接口的一个系统，这个系统会是变成一个很难改变的整体。
[第7篇] 定义服务和终结点地址
一个WCF服务是一系列终结点集合，每个终结点有一个独一无二的地址。终结点地址和绑定确定了终结点在哪里以及如何监听进入请求。除了终结点地址，服务本身也有地址，称为基地址。
一个服务的基地址用来作为可能在终结点中定义的相对地址的基地址。使用相对地址，而不是绝对地址，终结点地址让在一个服务中管理终结点变得更加容易。通过相对地址，你可以在一个服务中仅通过改变服务基地址就改变所有终结点地址。
[第8篇] 总结
当使用WCF寄宿时它能带来很大的灵活性。特别的，WCF服务可以在任何操作系统进程中寄宿。服务宿主，或者仅仅成为"宿主"， 负责启动和关闭服务并为控制服务提供基本的管理函数。为一个基于操作性能要求比如可用性，可信赖性和可管理性的服务选择正确的寄宿环境。