当前位置: 首页 > 编程语言 > .NET综合 > 正文

承载和使用WCF服务

时间:2010-04-19 Msdn Dennis Mulder ,Chris Peiris

简介

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

了解如何满足这些业务要求对于开发成功的服务是至关重要的。在第 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进程内部至少要承载一个应用程序域。

图 5-1:进程、应用程序域和 WCF ServiceHost 关系

注意:尽管可以实例化多个 ServiceHost 实例,但每个应用程序域内保留一个 ServiceHost 实例更便于操作。您可以在一个宿主内使用多个端点公开多个服务接口。更高级的宿主(例如,IIS和WAS)确实可以实例化多个 ServiceHost 实例,以提供隔离和不同的安全上下文。

因此,宿主的主要任务是向WCF ServiceHost 提供 Windows 工作进程和应用程序域。此外,WCF 依赖于应用程序域提供的安全和配置功能。Windows进程始终使用默认标识运行,WCF服务可随时使用这个现成的标识。但是,WCF 提供了几个级别的模拟用户的功能(详见本书第 7 章)。如果您不使用这些功能,则由运行服务的Windows进程提供安全上下文。前面几章提到过,默认情况下 WCF 依赖于 .NET Framework中的配置功能,您可以通过应用程序域对其进行访问。

某些宿主还具有管理所运行的应用程序的其他功能。最为突出的是,IIS 还具备自动进程回收、资源限制、日志记录、运行状况指示器等其他功能。您可以通过整个章节的学习了解有关这些主题的详细内容。(不同 IIS 版本具有受 WCF 支持的不同的可管理性功能。最为明显的,Windows XP中的IIS 5.1 在管理用户界面方面就受到一些限制。)