WCF还是比较常用的，于是我研究了一下WCF ServiceHost，在这里拿出来和大家分享一下，希望对大家有用。.NET 应用程序需要一个作为宿主的 Windows 进程。该 Windows 进程内部可以承载多个 .NET 应用程序域。应用程序域是 .NET CLR 将托管代码与 Windows 进行隔离所采用的一种手段。CLR 会在每个工作进程中进行初始化，并自动创建一个默认的应用程序域。该默认应用程序域运行于某个进程，并直到该进程结束时才会卸载。默认应用程序域的关闭是由 CLR 来控制的。
为了调用服务上的操作，客户端首先需要把服务合同导入到客户端的本地描述中。这意味着，该服务需要客户端暴露一个标准方法以检索它的元数据-这是通过让服务暴露一个元数据交换(MEX)端点来实现的。只要服务在宿主上注册至少一个TCP、HTTP或IPC基地址，那么，这个基于WCF的服务就能够自动地暴露一个MEX端点。
#T#在大多数宿主中，默认应用程序域内部并不运行任何代码。而是由宿主（或“进程”）来新建应用程序域，以便应用程序域可以独立于进程而关闭。在很多应用程序中，理想的情况是客户端代码和服务器端代码分别在不同应用程序域中执行。通常这种要求是出于安全性和隔离等原因的考虑。进程和应用程序域之间的关系类似于应用程序和应用程序域与 ServiceHostWCF 之间的关系。如图所示，每个进程都至少有一个应用程序域，并且每个应用程序域都可以承载零个或更多的WCF ServiceHost 实例。WCF 需要一个 Windows 进程内部至少要承载一个应用程序域。
注意 尽管可以实例化多个 ServiceHost 实例，但每个应用程序域内保留一个 ServiceHost 实例更便于操作。您可以在一个宿主内使用多个端点公开多个服务接口。更高级的宿主（例如，IIS 和 WAS）确实可以实例化多个 ServiceHost 实例，以提供隔离和不同的安全上下文。
因此，宿主的主要任务是向 WCF ServiceHost 提供 Windows 工作进程和应用程序域。此外，WCF 依赖于应用程序域提供的安全和配置功能。Windows 进程始终使用默认标识运行，WCF 服务可随时使用这个现成的标识。但是，WCF 提供了几个级别的模拟用户的功能。如果您不使用这些功能，则由运行服务的 Windows 进程提供安全上下文。前面几章提到过，默认情况下 WCF 依赖于 .NET Framework 中的配置功能，您可以通过应用程序域对其进行访问。
某些宿主还具有管理所运行的应用程序的其他功能。最为突出的是，IIS 还具备自动进程回收、资源限制、日志记录、运行状况指示器等其他功能。您可以通过整个章节的学习了解有关这些主题的详细内容。（不同 IIS 版本具有受 WCF 支持的不同的可管理性功能。最为明显的，Windows XP 中的 IIS 5.1 在管理用户界面方面就受到一些限制。）
