Art of WCF 4，承载服务

服务若要成为活动的，必须承载于创建它并控制其上下文和生存期的运行时环境中。Windows Communication Foundation (WCF) 服务设计为在支持托管代码的任何 Windows 进程中运行。WCF主要有三种不同的服务承载方式，分别是IIS承载，Windows进程激活(WAS)承载和.Net托管服务承载（即自承载）。

IIS承载

IIS 宿主选项与 ASP.NET 集成在一起，并使用这些技术提供的功能，如进程回收、空闲关闭、进程状况监视和基于消息的激活。 在 Windows XP 和 Windows Server 2003 操作系统上，这是作为必须高度可用且高度可伸缩的 Web 服务应用程序宿主的首选解决方案。 IIS 还提供了客户期望企业级服务器产品具有的集成可管理性。 此宿主选项要求正确配置 IIS，但是它不要求作为应用程序的一部分编写任何宿主代码。

如何为 WCF 服务配置 IIS 宿主？首先，请确保WCF Http Activation已经激活（在Handler Mapping中可以找到有关svc的项目），其它配置和部署ASP.net webservice相似。配置好以后，可以在浏览器中顺利的访问到。然后，我们可以利用Svcutil.exe 工具生成客户端的访问代码和配置文件，利用其out参数输出到指定的文件夹中。

请注意，以 IIS 为宿主的服务只能使用 HTTP 传输。 它在 IIS 5.1 中的实现在 Windows XP 中引入了一些限制。 在 Windows XP 上由 IIS 5.1 为 WCF 服务提供的基于消息的激活阻止同一计算机上任何其他自承载的 WCF 服务使用端口 80 进行通信。在 Windows Server 2003 上承载于 IIS 6.0 中时，WCF 服务可以运行在与其他应用程序相同的 AppDomain/应用程序池/工作进程中。 但是，由于 WCF 和 IIS 6.0 都使用内核模式 HTTP 堆栈 (HTTP.sys)，因此 IIS 6.0 可以与在同一计算机上运行的其他自承载 WCF 服务共享端口 80，这与 IIS 5.1 是不同的。

在 WAS 中承载 WCF 服务

WAS承载的特点是使用非 HTTP 传输协议，因此首先我们同样需要确保WCF Non-Http Activation已经激活。

如何：在 WAS 中承载 WCF 服务，请参见：http://msdn.microsoft.com/zh-cn/library/ms733109.aspx

自承载

自承载的方式最为灵活，但也最不安全可靠，因为这种做法在部署时所需的基础结构最少。自承载时，托管的应用程序会自己处理承载工作。WCF服务不能再以类库的形式生成，而应该生成exe文件，可以是WinForm，控制台或Windows服务程序。使用ServiceHost类开加载WCF类，若要开始接收消息，请调用 ServiceHost 上的 Open。 这样即可创建并打开服务的侦听器。 若要关闭服务，请调用在 ServiceHost 上的 CommunicationObject.Close。

下面是WCF自承载的优点：
◆易用性：只需几行代码即可使服务运行。
◆灵活性：通过 ServiceHost<T> 的 Open() 和 Close() 方法，可以轻松控制服务的生存期。
◆易调试性：可以使用熟悉的调试方式对自承载环境中承载的 WCF 服务进行调试，而不必连接到单个应用程序来激活服务。
◆易部署性：通常，部署简单 Windows 应用程序与使用 xcopy 一样容易。您不必在服务器场和类似地方部署复杂的方案，即可部署简单的 Windows 应用程序来充当 WCF ServiceHost。
◆支持所有绑定和传输：自承载并不限制您仅能使用现有的绑定和传输技术。在 Windows XP 和 Windows Server 2003 上，IIS 限制您只能使用 HTTP。

下面WCF自承载的缺点：
◆可用性受到限制：服务只有在应用程序运行时才能被访问。
◆功能受到限制：自承载的应用程序在对高可用性、易管理性、可靠性、可恢复性、版本控制和部署方案的支持方面受到一定限制。至少，现有的 WCF 无法提供这些支持，因此在自承载的情况中，您必须自己实现这些功能；例如，默认情况下 IIS 提供了这些功能中几项。

换句话说，对于企业级方案来说不应考虑自承载方式。自承载适用于企业项目的开发或演示阶段。此外，当您希望用户桌面应用程序进行相互通信或在点对点情况下，可以对服务进行自承载。

《完》