承载和使用WCF服务(一) 简介

前沿

承载和使用WCF服务主要讨论Windows Communication Foundation (WCF)承载方案和WCF服务的使用。传统的ASMX Web服务通常仅由Microsoft Internet信息服务(IIS)承载。在Microsoft .NET Framework 3.0中，WCF服务的承载方案得到了极大的增强。我们将讨论如何将承载模型扩展为包括Windows服务和自承载方案。此外，我们还将详细探讨可用于WCF服务的IIS承载（版本5.1、6.0和7.0）和Windows激活服务 (WAS) 承载方案。

简介

如果企业依赖于面向服务的体系结构，就必须确保服务能够正常可靠的运行。应用程序可靠性背后最重要的动因是在哪里托管服务以及如何托管服务。在考虑托管服务时，您必须事先考虑几个问题：服务有哪些可用性方面的要求？如何管理和部署服务？是否需要提供对旧版本服务的支持？

了解如何满足这些业务要求对于开发成功的服务是至关重要的。在第 3 章中您将了解到，必须自己提供宿主来承载服务。Windows Communication Foundation (WCF) 本身没有附带宿主，而是提供了一个被称为 ServiceHost 的类，该类允许您在自己的应用程序中承载 WCF 服务。您不必考虑任何网络传输方面的细节，即可确保服务能够被访问。只需以编程方式或声明方式对服务的端点进行配置，然后调用 ServiceHost 的 Open 方法即可。ServiceHostBase 和 ServiceHost 中集成了第 3 章要介绍的有关绑定、通道、调度程序和侦听器的所有一般功能。这意味着用于承载服务的应用程序（运行 ServiceHost 的应用程序）的负载将远远低于您之前预期的水平。

本章讨论何种类型的应用程序可以为 ServiceHost 提供宿主环境。此外，您还会对使用不同应用程序内承载的服务时存在的差异有所了解。

读完本章后，您将学到以下知识：

• 适用于您的各种不同的承载方案 
• 每种承载方案有哪些优点和缺点 
• 根据具体情况选择承载方案的指导 
• 有关 Microsoft 如何实现不同承载方案以及每种方案在哪些方面具有可扩展性的体系结构方面的指导

研究承载方案

在 Microsoft .NET 平台上，使用 Microsoft Visual Studio.NET 可以创建几种不同类型的托管 Windows 应用程序：

• WinForms 应用程序 
• 控制台应用程序 
• Windows 服务 
• 承载于 Internet 信息服务 (IIS) 中的 Web 应用程序 (ASP.NET) 
• IIS 7.0 内提供的 WCF 服务以及 Windows Vista 或 Windows Server 2007 中的 WAS 

     如果您仔细研究 Microsoft Visual Studio 2005 附带的项目模板，就会发现还有其他可选方案供您使用。很显然，我们认为没有其他模板可以在服务世界中用作可行的方案。但值得注意的是，只要 WCF 能够提供 .NET 应用程序域，您就可以在其他任何类型的应用程序中运行服务。（如果您不了解 .NET 应用程序域的原理，请参考下面“了解 .NET 应用程序域”一节的有关内容。）实际上这完全取决于您对宿主的要求。总结这些可选方案，我们主要考虑以下三类常见的 WCF 服务宿主：

• 在托管的 .NET 应用程序中进行自承载 
• 在 Windows 服务中进行承载 
• 在不同版本的 IIS 中进行承载

可想而知，如本节之前提到的，所有这些宿主在 Visual Studio 中都有相关联的项目模板，并且都有自己的特征。要想更好地了解在每种情况下哪种宿主是最佳选择，必须了解宿主通常的要求和功能。理解这一点后，我们将分别详细介绍每种承载方案。

了解 .NET 应用程序域

如果您了解 Windows 进程的角色以及如何通过托管代码与它们交互，那么您肯定会对 .NET 应用程序域的概念有所了解。要在进程中运行托管 .NET 代码，就需要创建程序集。这些程序集并不直接承载于 Windows 进程中。而是由公共语言运行库 (CLR) 在进程中创建称为“应用程序域”的单独逻辑分区来对托管代码进行隔离。单个进程可能会包含多个应用程序域，每个域都会承载封装于程序集内的不同代码片断。这种对传统 Windows 进程的划分方式可以通过 .NET Framework 提供几个好处。

主要好处如下所示：

• 由于不涉及可执行文件或库的概念，应用程序域决定了 .NET 平台的与操作系统无关的特性。 
• 您可以根据自身需要控制、卸载和加载应用程序域。 
• 应用程序域在应用程序或多个应用程序域共生的进程中起到隔离的作用。进程中的应用程序域彼此相互独立，虽然一个域出现故障，但其他域仍可正常工作。

承载环境特征

.NET 应用程序需要一个作为宿主的 Windows 进程。该 Windows 进程内部可以承载多个 .NET 应用程序域。应用程序域是 .NET CLR 将托管代码与 Windows 进行隔离所采用的一种手段。CLR 会在每个工作进程中进行初始化，并自动创建一个默认的应用程序域。该默认应用程序域运行于某个进程，并直到该进程结束时才会卸载。默认应用程序域的关闭是由 CLR 来控制的。在大多数宿主中，默认应用程序域内部并不运行任何代码。而是由宿主（或“进程”）来新建应用程序域，以便应用程序域可以独立于进程而关闭。在很多应用程序中，理想的情况是客户端代码和服务器端代码分别在不同应用程序域中执行。通常这种要求是出于安全性和隔离等原因的考虑。

进程和应用程序域之间的关系类似于应用程序和应用程序域与 ServiceHostWCF 之间的关系。如图 5-1 所示，每个进程都至少有一个应用程序域，并且每个应用程序域都可以承载零个或更多的 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 在管理用户界面方面就受到一些限制。）

承载环境特征

Microsoft 在确保服务开发人员无需过分考虑承载环境方面所做的努力是值得肯定的。ServiceHost 排除了所有技术性的难点，使您可以重点关注服务逻辑，而不必过多地考虑如何承载服务。您必须根据自己的具体要求选择一个宿主。WCF 主要是作为编程模型而编写的，其主要设计目的之一是为了实现“宿主的不可知”。ServiceHost 不关心自身在哪里被实例化，只要您希望服务可被访问时它正在运行即可。也就是说，它需要一个运行 .NET 应用程序域的进程。

在选择应用程序类型时，必须考虑某些特定要求（例如，程序属于控制台应用程序还是 WinForms 应用程序等）。ServiceHost 必须被实例化才能提供运行服务所需的承载环境。典型的 .NET 应用程序（例如，控制台应用程序和 WinForms 应用程序）通常运行在用户桌面计算机上。这些环境并非始终运行，它们可以承载您的服务，但却并非典型的适用于企业的宿主。我们认为适用于企业的宿主应该能够支持更大规模的面向服务的体系结构，在这种体系结构中，多个系统需要依赖服务所公开的关键业务功能。这些适用于企业的宿主通常能够满足诸如高可用性的要求。因此，我们不能将控制台或 WinForms 应用程序做为适用于企业的宿主。

通常情况下，服务运行在服务器上，并由操作员进行管理和操作。管理服务器的操作员一般不希望在服务器重新启动时手动启动控制台应用程序或 WinForms 应用程序。为了让服务应用程序能够在数据中心运行，对于企业级面向服务的情况来说，唯一可行的方案就是在 IIS 上承载服务，或将其作为一项 Windows 服务。

有时，您需要在用户的桌面计算机上实现进程间通信。在这种情况下，只有当用户使用应用程序时，服务才是活动的。需要进行进程间通信的典型应用程序就是控制台应用程序和 WinForms 应用程序。这些应用程序适合承载这些类型的服务。

要能够确定哪种宿主最适合您的情况，您应当考虑到非功能性要求。一般来讲，非功能性要求规定了应用程序的技术要求，以确保其达到应用程序要求的质量和可维护性。对于 WCF 应用程序来说，非功能性要求实际涉及以下内容：

• 可用性：希望何时能够访问您的服务？ 
• 可靠性：当服务由于某些原因出现中断时会发生什么问题？这将如何影响服务的其他使用者？ 
• 可管理性：是否需要便捷地了解承载 WCF 服务的宿主上所发生的情况？ 
• 版本控制：是否需要提供对旧版本服务的支持？是否知道谁在使用您的服务？ 
• 部署：要采用何种部署模型？是否要通过 Microsoft Installer 进程和 Visual Studio 部署包进行安装，还是使用 xcopy 就可以满足需要？ 
• 状态：服务是无状态的吗？是否需要会话？

根据这些非功能性要求，您可以确定哪些宿主是符合您的需求的。为了帮助您做出选择，本章后面的内容将介绍不同的承载环境及其优缺点。

注意：由于对自身的运行环境并不了解，因此 WCF 编程模型总是有可能切换到不同宿主，但这并不意味着您必须更改服务实施。首先，您需要在控制台应用程序中进行自承载，以测试并确定服务的原型。