承载和使用WCF服务(三) 使用 Internet 信息服务进行承载

最新推荐文章于 2025-08-18 13:38:21 发布

趁着年轻去旅行

最新推荐文章于 2025-08-18 13:38:21 发布

阅读量837

点赞数

分类专栏： Siliverlight 文章标签： wcf internet iis asp.net windows microsoft

Siliverlight 专栏收录该内容

7 篇文章

订阅专栏

本文探讨了在不同版本的Internet信息服务(IIS)中承载Windows Communication Foundation(WCF)服务的方法和技术细节，包括IIS5.1、IIS6.0及IIS7.0的特点与配置。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

使用 Internet 信息服务进行承载

在 IIS 上的 Web 服务开发长期以来一直是 ASP.NET 的领地。ASP.NET 1.0 发布后，Web 服务框架成为它的一部分。Microsoft 利用 ASP.NET HTTP 管道使 Web 服务在 Windows 平台上成为现实。遗憾的是，ASP.NET 和 Web 服务之间的这种紧密耦合在面向服务的世界中产生了几个限制，对 HTTP 的依赖性是主要原因。在不同宿主上运行 ASP.NET HTTP 管道很困难，因此很少采用这种方案。甚至在此后，ASP.NET Web 服务（也称为 ASMX 服务）在部署方案和配置依赖性方面一直是非常面向 Web 的。Microsoft 最初发布了几个版本的 Web 服务增强 (WSE)，以弥补 ASP.NET Web 服务的某些局限，尤其是消除在实现 WS-* 协议方面的限制。但是，WSE 非常依赖于 ASP.NET Web 服务实现。

在以前几章中介绍过，WCF 服务采用了完全不同的途径来实现面向服务。WCF 的统一编程模型基于严格分层的模型，以分解面向 Web 的范例，并使服务模型和通道层与受支持的传输方式断开连接。此模型允许 WCF 支持几个不同的宿主，其中 IIS 是最重要的。

构建 WCF 是为了支持 Windows XP、Windows Server 2003、Windows Vista 和 Windows Server 2007。自从 IIS 5.1（与 Windows XP 一起发布）以来，有了很多变化。但是，Microsoft 仍然继续支持旧版上的 WCF。这可能是因为 Microsoft .NET Framework 和 CLR 提供的功能所导致的，该功能是构建 WCF 的基础。在以下几节中，将介绍不同 IIS 版本的进程模型之间的差异和 WCF 服务的结果。

IIS 5.1 和 IIS 6.0 核心功能

为了能够解释这些差异，我们首先必须解释 IIS 的核心功能。IIS 长期以来一直支持在一个计算机上运行多个站点和多个应用程序。为了做到这一点，IIS 引入了公用地址模型，该模型分为三个主要区域：

◆站点（注意：与 Windows XP 一起发布的 IIS 5.1 只支持一个站点。）

◆应用程序

◆虚拟目录

站点绑定到特定方案、网络地址和端口组合。IIS 不仅支持 HTTP，而且依据版本还支持 FTP、NNTP 和 SMTP。可以在相同站点下和在相同方案、网络和端口组合下运行多个应用程序。应用程序的典型 URI 是 http://localhost/MyApplication。虚拟目录只是映射到站点网络空间的文件夹，它可以是文件系统中的其他某处。这样，就可以使应用程序的实际内容或代码与作为相同站点组成部分的其他应用程序分隔开来。

在 IIS 6.0 中，Microsoft 对 IIS 进程模型做了一些重要更改。IIS 进程模型被拆分成可以由站点和应用程序共享的应用程序池，在这里，每个应用程序都运行在它自己的应用程序域中。“应用程序池”是称为 W3wp.exe 的单独 Windows 工作进程，并且只在它需要启动时才会启动。换句话说，IIS 带有应用程序激活模型，它允许 IIS 在它收到与应用程序池绑定的特定应用程序的请求时启动该应用程序池。这样，IIS 就能在一个服务器上承载数千个应用程序，而不必一直运行数千个进程。IIS 的激活体系结构在服务世界中是有趣的模型，本章的“Windows 激活服务”节将对此进行介绍。

图 5-9 显示在 HTTP 协议堆栈底部的 IIS 6.0 核心体系结构以及在其顶部的至少四个不同进程。

图 5-9：IIS 6.0 核心体系结构

◆Lsass.exe: 负责 IIS 的安全功能：实现 Windows 身份验证和安全套接字层 (SSL)。

◆Inetinfo.exe: 承载非 HTTP 服务和 IIS Admin 服务（包括元数据库）的进程。

◆SvcHost.exe: 可以承载操作系统服务的进程；在使用 IIS 的情况下，它承载 Web (HTTP) 服务。

◆W3wp.exe: 工作进程。IIS 可以有多个 W3wp.exe 进程，每个应用程序池一个。若要支持在单独进程中拆分一个应用程序的 Web 园方案，则有多个相同工作进程的实例。这可以提供额外的可伸缩性和性能优势。

注意：我们要在这里描述 IIS 6.0 体系结构，因为它是发布 WCF 之前最广泛使用的 IIS 版本。此外，WCF 支持 IIS 6.0，并且该模型与使用 IIS 7.0 和 Windows 激活服务时选择的实现非常类似，本章后面将对此进行介绍。IIS 5.1 和 IIS 6.0 之间的主要差异是站点和应用程序池的数量受到限制。IIS 5.1 只支持绑定到一个应用程序池的一个站点。

在 IIS 中承载 WCF 服务

若要在 IIS 中承载 WCF 服务，需要有一个扩展名为 .svc 的新物理文件。该文件将服务与其实现相关联，并且是 IIS 自动创建 ServiceHost 的手段。IIS 将接管服务与 ServiceHost 之间的交互，不必再由您自己实例化和启动 ServiceHost。.svc 文件的第一行包含一条夹在 ASP.NET <% Page %>指令内的指令，用于告诉承载环境此文件指向哪个服务。然后，服务代码可以驻留在内嵌代码行内（如列表 5-3 所示）、在注册于 GAC 的单独程序集中、在驻留于应用程序的 Bin 文件夹内的程序集中、或者在驻留于应用程序的 App_Code 文件夹下的 C# 文件中。最常见方案是在配置文件中定义端点。在 IIS 中，必须在 Web.config 文件中定义端点，下一节将对此进行解释。

列表 5-3 显示一个基于前面的 TradeService 服务的示例 .svc 文件。它有内嵌于代码行内的服务代码。列表 5-4 显示一个示例 .svc 文件，其中，代码驻留于 App_Code 文件夹内。

列表 5-3：包含内嵌代码的 ExchangeServiceInline.svc 文件

<%@ServiceHost Language="C#"
Service="QuickReturns.StockTrading.ExchangeService.TradeServiceInline" 
%>
using System;
using System.Collections;
using System.ServiceModel;
using QuickReturns.StockTrading.ExchangeService.Contracts;
using QuickReturns.StockTrading.ExchangeService.DataContracts;
namespace QuickReturns.StockTrading.ExchangeService
{
[ServiceBehavior(InstanceContextMode=InstanceContextMode.Single,
IncludeExceptionDetailInFaults=true)]
public class TradeServiceInline : ITradeService
{
public Quote GetQuote(string ticker)
{
...
}
public void PublishQuote(Quote quote)
{
...
}
}
}

列表 5-4. 包含外部代码的 ExchangeService.svc 文件

<% @ServiceHost language="C#"
Service=" QuickReturns.StockTrading.ExchangeService.TradeService"
CodeBehind="~/App_Code/TradeService.cs" %>

<% @ServiceHost language="C#" Service=" QuickReturns.StockTrading.ExchangeService.TradeService" CodeBehind="~/App_Code/TradeService.cs" %>

在 IIS 中配置 WCF 服务

在 IIS 中进行承载意味着您必须在要承载服务的应用程序的 Web.config 文件中设置 WCF 配置。Web.config 文件中的服务配置类似于自承载服务。列表 5-5 显示一个 TradeService 服务的 Web.config 示例文件。

列表 5-5：用于配置 IIS 中承载服务的 Web.config

<?xml version="1.0"?>
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
   <system.serviceModel>
      <services>
         <service 
name="QuickReturns.StockTrading.ExchangeService.TradeService"
                  behaviorConfiguration="tradeServiceBehavior">
         <endpoint name="basicHttpBinding"
                   address=""
                   binding="basicHttpBinding"
                   contract="QuickReturns.StockTrading.ExchangeService.?
                             Contracts.ITradeService"/>
         <endpoint name="mexHttpBinding"
                   contract="IMetadataExchange"
                   binding="mexHttpBinding"
                   address="mex" />
      </service>
      <service 
name="QuickReturns.StockTrading.ExchangeService.TradeServiceInline"
               behaviorConfiguration="tradeServiceBehavior">
            <endpoint name="basicHttpBinding"
                      address=""
                      binding="basicHttpBinding"
                      contract="QuickReturns.StockTrading.ExchangeService.?
                                Contracts.ITradeService"/>
            <endpoint name="mexHttpbinding"
                      contract="IMetadataExchange"
                      binding="mexHttpBinding"
                      address="mex" />
         </service>
      </services>
      <behaviors>
         <serviceBehaviors>
            <behavior name="tradeServiceBehavior" >
               <serviceMetadata httpGetEnabled="true" />
            </behavior>
            <behavior name="returnFaults"
                      returnUnknownExceptionsAsFaults="true"/>
         </serviceBehaviors>
      </behaviors>
   </system.serviceModel>
</configuration>

请注意，服务的 address 属性为空。.svc 文件确定服务的 base 地址。但是，可以提供其他字符串用于设置相对于 .svc 文件的端点地址。例如，可以使用以下格式：

http://localhost:8080/QuickReturns/Exchange.svc/ExchangeService

在配置文件中指定的服务 name 属性充当了对应于 ExchangeService.svc 的查找键，它告诉承载环境此配置属于哪个服务。端点级别的其他属性与前面的解释相同。

在 IIS 中，Web 配置文件可以嵌套在站点、应用程序和虚拟目录内。WCF 将接受所有配置文件，并将服务及其端点合并在一起。这意味着，嵌套的 Web.config 文件将相互叠加，在层次结构的底部读取的最后一个文件优先于在层次结构中更高的文件。

在 IIS 中访问 ServiceHost

在 IIS 中承载 WCF 服务的默认行为是该 IIS 控制 ServiceHost 的实例化。这将使您无法在消息到达服务之前有启动和关闭代码。当然，无启动和关闭代码的优点是可以减少可能引起错误的代码。IIS 为您提供了在代码行方面比控制台应用程序更容易的承载环境。但是，有时仍然需要有避免此限制的手段。要在实例化 ServiceHost 时这样做并影响 IIS，可以建立您自己的工厂，用于创建自定义宿主。这样，就可以访问任何事件或改写任何方法。

为了支持自定义 ServiceHost 激活，应当实现自己的 Factory，它继承自 ServiceHostFactory，这是可以实例化自定义宿主的工厂类。提供该类是为了关联 ServiceHost 的事件。您可以使用该类并将该类型作为 Factory 属性放在 .svc 文件中，如列表 5-6 所示。通过改写 ServiceHostFactory 类的 CreateServiceHost 方法，可以执行与在自承载方案中相似的任务，第 3 章对此进行了介绍。在其他方面，这将使您能够抽象逻辑，以便从外部配置建立说明，或为要使用的基础库、项目、部门或公司创建更合适的基类。

列表 5-7 显示用于创建宿主的 TradeServiceCustomHost 和 TradeServiceCustomHostFactory 的代码。

列表 5-6：包含 CustomServiceHostFactory 的 .svc 文件

<% @ServiceHost Language="C#" Debug="true"
   Service="QuickReturns.StockTrading.ExchangeService.TradeService"
   Factory="QuickReturns.StockTrading.ExchangeService.
TradeServiceCustomHostFactory" %>

<% @ServiceHost Language="C#" Debug="true" Service="QuickReturns.StockTrading.ExchangeService.TradeService" Factory="QuickReturns.StockTrading.ExchangeService.
TradeServiceCustomHostFactory" %>

列表 5-7：TradeServiceCustomHostFactory 和 TradeServiceCustomHost

using System;
using System.ServiceModel;
using System.ServiceModel.Activation;
namespace QuickReturns.StockTrading.ExchangeService
{
public class TradeServiceCustomHostFactory : ServiceHostFactory
{
protected override ServiceHost CreateServiceHost(
Type serviceType, Uri[] baseAddresses)
{
TradeServiceCustomHost customServiceHost =
new TradeServiceCustomHost(serviceType, baseAddresses);
return customServiceHost;
}
}
public class TradeServiceCustomHost : ServiceHost
{
public TradeServiceCustomHost(Type serviceType, params Uri[] 
baseAddresses)
: base(serviceType, baseAddresses)
{
}
protected override void ApplyConfiguration()
{
base.ApplyConfiguration();
}
}
}

回收

在 IIS 中承载 WCF 服务时，WCF 服务可以使用 ASP.NET 应用程序的所有功能。您必须知道这些功能，因为它们会在服务世界中导致意外的行为。主要功能之一是应用程序回收，包括应用程序域回收和进程回收。通过 IIS 管理控制台，可以在希望发生回收时配置不同的规则。可以为内存、时间和请求处理数量设置某些阈值，如图 5-10 所示。当 IIS 回收工作进程时，还将回收工作进程中的所有应用程序域。通常，当基于 ASP.NET 的 Web 应用程序中的关键文件更改时，应用程序域也将回收。例如，在更改 Web.config 文件或 Bin 文件夹中的程序集时，将发生该操作。

图 5-10：应用程序池回收设置

注意：此处描述的进程回收包括 Windows Server 2003 中的回收。若要在 Windows XP 和 IIS 5.1 中启用进程回收，可以从 Microsoft 网站下载 IIS 5.0 进程回收工具。进程回收工具作为服务在运行 IIS 5.0 或 IIS 5.1 的计算机上运行。

修改 .svc 文件之后，还将回收应用程序域。承载环境将尝试按时正常关闭所有 WCF 服务的打开连接。如果由于某种原因使服务无法按时关闭，系统将强制中止它们。通过 HostingEnvironmentSettings 配置设置，可以影响回收的行为，如列表 5-8 所示。idleTimeout 设置确定应用程序域在回收前的空闲时间长度（秒）。shutdowntimeout 设置确定正常关闭应用程序前的时间长度（秒）。发生此超时后，它将强制应用程序关闭。

列表 5-8：包含回收设置的 hostingenvironment 节的 Web.config

<system.web>
    <hostingEnvironment idleTimeout="20"
                        shutdownTimeout="30"/>
</system.web>

使用 WCF 会话时，理解这些回收功能很重要。通常，在安全和可靠消息方案中有这种情况，本书的第 6 章和第 8 章将对此进行介绍。默认情况下，WCF 将会话状态存储在内存中。这是与 ASP.NET 会话状态不同的实现，它没有需要切换到持久会话状态存储的配置。但在安全和可靠消息方案中，您可以并且应当受益于 ASP.NET 实现。通过使用 WCF 的 ASP.NET 兼容性功能，可以获得 ASP.NET 会话状态的 SQL Server 和状态服务器实现，以支持企业可用的方案。在下一节中，将介绍如何受益于 WCF ASP.NET 兼容性模式。

ASP.NET 兼容性模型

如果在负载平衡或者甚至 Web 园的环境中承载 WCF 服务，并且在该环境中后续的会话请求可以被此环境内的不同宿主或进程处理，则需要对会话状态进行进程外持久存储。最新的 WCF 不支持会话状态的持久存储。相反，WCF 将它的所有会话状态存储在内存中。如果在 IIS 中承载 WCF 服务，最后可以使用回收方案，上一节对此进行了描述。WCF 依赖于会话状态的 ASP.NET 实现，而不是为会话全部再次建立持久存储。此方式有一个严重的限制：使服务仅限于 HTTP。

ASP.NET 会话状态不是受 ASP.NET 兼容性模式支持的唯一功能。它还支持诸如 HttpContext、globalization 和模拟等功能，就像用于 ASP.NET Web 服务 (ASMX) 一样。有关启用进程外会话状态的特定于 ASP.NET 的功能，请参考 MSDN 帮助。

若要查看 ASP.NET 兼容性模式的限制，必须用 AspNetCompatibilityRequirements 属性显式标记服务，如列表 5-9 所示。

列表 5-9：AspNetCompatibilityRequirements 属性

namespace QuickReturns.StockTrading.ExchangeService
{
[ServiceBehavior(InstanceContextMode=InstanceContextMode.Single,
ReturnUnknownExceptionsAsFaults=true)]
[AspNetCompatibilityRequirements(
RequirementsMode=AspNetCompatibilityRequirementsMode.Allowed)]
public class TradeService : ITradeService
{
...
}
}

AspNetCompatibilityRequirementsMode 属性有以下允许值。

表 5-1. AspNetCompatibilityRequirementsMode 属性的值

值	说明
NotAllowed	指示服务可能“永远不能”运行在 ASP.NET 兼容性模式中。如果在方案中服务实现不能在 ASP.NET 兼容性模式中工作（例如，在服务不是为 HTTP 生成的方案中），则必须设置此项。
Allowed	指示服务“可能”运行在 ASP.NET 兼容性模式中。只有当您知道服务可能在此模式中工作时，才能选取此值。
Required	指示服务“必须”运行在 ASP.NET 兼容性模式中。如果服务需要进行持久会话存储，请选取此值。

选择“Required”选项时，WCF 将验证服务的所有受支持的端点都是 HTTP 端点，并且，如果它们不是，则会在 ServiceHost 初始化期间产生异常。除了 AspNetCompatibilityRequirements 属性以外，还必须设置 aspNetCompatibilityEnabled，如列表 5-10 所示。

列表 5-10：启用了 ASP.NET 兼容性的配置<configuration

<?xml version="1.0"?>
<configuration 
xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>
<services>
...
</services>
<behaviors>
...
</behaviors>
</system.serviceModel>
</configuration>

注意：本书附带的示例代码包含在 ExchangeServiceInline.svc 文件中承载的 TradeService 服务，它被配置为在 ASP.NET 兼容性模式中运行。您可以在第 5 章的解决方案文件（请参考示例代码下载链接）中找到它。

Windows XP 和 IIS 5.1

Windows 2000 附带的 IIS 5.0 拆分了 IIS 进程模型，并引入了工作进程。此更改的主要原因是为了隔绝应用程序，以便 IIS 可以承载相互依赖较少的不同应用程序。IIS 5.0 与 Windows 2000 一起发布，而 IIS 5.1 与 Windows XP 一起发布。WCF 不支持在带 IIS 5.0 的 Windows 2000 上承载服务；因此，我们将只详细考查 IIS 5.1。IIS 5.1 受支持，但它有仅一个站点的限制，并且每个应用程序都运行在一个称为 aspnet_wp.exe 的工作进程中。IIS 5.1 对于开发 ASP.NET 网站和 WCF 服务是很好的版本。它不是为企业使用而准备的，因为它有连接限制，并且只运行在早期的 Windows 版本或 Windows XP 的客户端版本上。在本章中，我们将讨论 IIS 5.1。

在图 5-11 中，可以看到 IIS 5.1 的进程模型。体系结构被拆分成两部分。左侧的 W3svc.exe 承载 HTTP 侦听器、启动工作进程并管理配置。另一侧的工作进程则使 IIS 5.1 能够承载托管的 .NET 应用程序，在这里，ASPNET_ISAPI.dll 负责创建托管 .NET 应用程序域。请注意，在 Windows XP 上，W3svc.exe Windows 服务与 SMTP 和 FTP 服务一起承载在 SvcHost.exe 进程中。

图 5-11：IIS 5.1 进程模型体系结构

注意：不必有 IIS 即可运行 ASP.NET 和 WCF 服务。例如，可以使用 Visual Studio 2005 附带的 ASP.NET 开发 Web 服务器。在发布 Windows XP 时，Visual Studio 还没有此功能。必须使用 IIS 5.1 才能在 Windows XP 上开发 Web 应用程序。

Windows Server 2003 和 IIS 6.0

到 Windows Server 2003 时，Microsoft 引入了内核模式 HTTP 堆栈，称为 HTTP.SYS。HTTP.SYS 通过 W3svc.exe 插入 IIS 6.0 体系结构中。W3svc.exe 是用户模式组件，用于桥接内核模式的 HTTP.SYS 实现，并将它连接到在 IIS 5.1 中已有的进程和配置管理系统。到 IIS 6.0 时，应用程序池的概念更加普及。尽管在 IIS 5.1 中只有托管 (ASP.NET) 应用程序可以承载在单独的应用程序池中，但在 IIS 6.0 中所有类型的应用程序都可以承载在单独的应用程序池中。ASPNET_ISAPI.dll 仍然负责启动在托管 ASP.NET 世界中的应用程序域。图 5-12 说明了 IIS 6.0 中的进程模型。

图 5-12：在 IIS 6.0 中承载的 IIS 6.0 进程模型体系结构

下面的详细步骤说明如何在 IIS 6.0 中承载 .NET 3.0 WCF 服务。我们将使用在前面描述的示例在 IIS 6.0 中进行承载。

1、请在示例代码文件夹中打开包含 ExchangeServiceIISHost 文件夹的文件夹。

2、下一步是在 IIS 中为该文件夹创建虚拟目录。可以通过 IIS 管理器导航；但为简单起见，只需右键单击此文件夹，然后选择“属性”。

3、一旦出现属性对话框，请单击“Web 共享”选项卡。只需单击“共享此文件夹”单选按钮，将显示“编辑别名”。将别名从“ExchangeServiceIISHost”重命名为“ExchangeService”。可以启用“目录浏览”以使您更容易查看并单击网站中的项目。通常，这是只用于开发的设置；关于 Web 共享设置，请参见图 5-13。

警告：此设置允许用户浏览站点中的所有文件，就像使用 Windows 资源管理器一样。虽然是好功能，但请在实际运行环境中使用时一定要小心。

图 5-13：Web 共享“编辑别名”对话框

1、此时，只需单击“确定”几次，即可退出对话框。现在，应当可以通过以下网址http://localhost/ExchangeService 访问站点。但是，我们仍然必须检查为此站点设置的 ASP.NET 的版本。如果只安装了 .NET 2.0（就是说从未安装 .NET 1.1），则应当不用做其他操作，但检查一下是有好处的。因此，请打开 IIS 管理器（“开始” | “控制面板” | “管理工具” | “Internet 信息服务”）。一旦看到“属性”对话框，请单击“ASP.NET”选项卡，然后使用下拉框将 ASP.NET 的版本切换到 .NET 3.0（受支持的版本）2.0.50727（RTM 版本）。

2、对于我们的示例，有一个额外的步骤，用于使“匿名”请求能够访问资源。匿名请求是指没有与 HTTP 请求关联的标识或 Windows 主体的任何请求。

单击“目录安全”选项卡，然后在对话框的“匿名访问和身份验证控制”区域下单击“编辑”。确保选项“匿名访问”被启用。这将允许我们的示例运行，而不会涉及如何为请求提供身份验证凭据。

此时，如果使用 Internet Explorer 浏览到 http://localhost/ExchangeService 位置，将能够看到一个目录列表（只要设置与上一图中相似）。如果单击 Service.svc，将转到由 *.svc 扩展的 System.ServiceModel.Activiation.HttpHandler 生成的默认帮助屏幕。

此时，将执行与在客户端应用程序中相同的步骤，要么直接通过使用 Svcutil.exe 实用程序生成代理类，要么右键单击项目并通过“添加服务”加载项功能生成代理，本章后面的“使用 WCF 服务”一节将对此进行介绍。

此示例附带的解决方案有完整的控制台客户端，它可以调用我们刚创建的 WCF 服务。

在 IIS 7.0 上进行承载

IIS 7.0 推动了 Web 服务器领域中的又一重大演进。可以在图 5-14 中看到两个重要改变。第一，现在特定于协议的侦听器适配器支持所有四种 WCF 传输，而不是仅限于 IIS 6.0 中的 HTTP 传输。此外，出现了称为 Windows 激活服务 (WAS) 的新操作系统服务。W3svc.exe 和 WAS 都运行在称为 SvcHost.exe 的操作系统宿主的内部。为了能够将 IIS 6.0 进程模型的强大功能与 WCF 结合使用，则需要进行这些更改。您可能会问“为什么？”好的，WCF 服务也工作在 IIS 5.1 和 IIS 6.0 中，那么，通过在 IIS 中推广进程模型和激活功能可以获得什么好处呢？很简单：通过推广激活概念使它与协议无关，而不是绑定到 HTTP，可以将平台的激活功能扩展到几乎所有传输类型。

图 5-14：IIS 7.0 进程模型体系结构

在新发布的 Windows Vista 和 Windows Server 2007 中，Microsoft 转移了 IIS 的进程管理和配置功能，并使它在操作系统内部普遍可用。这使建立于该模型上的任何应用程序都能基于传入的消息使用运行时激活和生成工作进程的功能。

HTTP、TCP/IP、命名管道和 MSMQ 的特定于协议的侦听器适配器运行于它们自己的进程内部，并将特定传输桥接到 WAS。侦听器适配器要求 WAS 激活工作进程，然后将实际通信转交给这些工作进程内部的特定协议处理程序。因此，WAS 现在拥有 W3svc.exe 中具备的所有功能。通过将此责任拆分成多个单独的进程，其他三种传输也受益于过去内置在 IIS 6.0 中但只用于 HTTP 的进程模型和激活功能。总而言之，使用 IIS 7.0 可以跨越 IIS 中提供的任何传输类型承载任何 WCF 服务。在下一节中，将介绍 WAS 激活的工作原理，以及如果希望在 Windows Vista 或 Windows Server 2007 上的 IIS 7.0 和 WAS 内部承载 WCF 服务时必须注意的事项。

若要在 IIS 7.0 内部承载本书中使用的 TradeService，您要做的就是配置 IIS，并将为 IIS 6.0 创建的 .svc 文件放在您将创建的站点中。利用以下步骤您将能够在 Windows Server 2007 上配置 IIS 7.0、WAS 和 .NET Framework 3.0，并使 TradeService 运行在 IIS 7.0 内部：

1、启动服务器管理器（位于“管理工具”中）。

2、向服务器添加 Web 服务器 (IIS) 角色。

3、注意，安装 Web 服务器时将自动添加 WAS。

4、在 IIS 的“详细设置”屏幕上，选择“ASP.NET”，并在“安全”下选择“基本和 Windows 身份验证”。让其余选项保持默认设置。

这将安装 IIS 和 WAS。

5、默认情况下，Windows Server 2007 不附带安装 .NET Framework 3.0。若要安装 .NET Framework 3.0，请打开“添加功能向导”（“控制面板” | “程序” | “Windows 功能”）。

6、单击“添加功能”，并选择“NET Framework 3.0”（如果要用 WCF MSMQ 传输进行实验）。还应选择“MSMQ”。

现在，就可以准备在 IIS 7.0 上运行 WCF 服务了。下一步是在 IIS 中创建在其中运行服务的应用程序。这需要使用 Internet 信息服务 (IIS) 管理器。可以在“开始”菜单的“管理工具”中找到 IIS 管理工具。然后，导航到您的服务器和您的网站，最后找到默认网站。右键单击默认网站，并选择“创建应用程序”，如图 5-15 所示。

图 5-15：在 IIS 管理器中新建应用程序

现在，需要指定本地计算机上的一个文件夹，用于承载应用程序的 .svc 文件。如图 5-16 所示，可以为应用程序指定一个用于访问服务的名称 (http://localhost/<chosenname>) 和驻留文件的文件夹，然后选择应用程序池。

图 5-16：在 IIS 管理器中为新应用程序设置属性

如果正确完成所有操作，则可以通过 IIS 7.0 访问您的服务。通过导航到新创建的应用程序可以测试实际效果，例如：

http://localhost:8080/QuickReturns/Exchange.svc/ExchangeService

Windows 激活服务

WAS 使您能够承载任何 WCF 服务，以便在 IIS 模型内部支持任何传输。WAS 接管了最初 IIS 6.0 中 W3svc.exe Windows 服务的创建工作进程和提供配置的工作（并运行在 Inetinfo.exe 进程的内部）。WAS 和 IIS 现在共享用于定义站点、应用程序、应用程序池和虚拟目录的配置存储区。在这一节中，我们将介绍用 WAS 激活的过程，如图 5-17 所示。

默认情况下，如果没有向新启动的服务器发出请求，Windows 将运行五个服务（如果启用了所有协议）。下面是这些 Windows 服务：

◆WAS

◆万维网发布服务（承载侦听器适配器）

◆NET.TCP 侦听器适配器

◆NET.PIPE 侦听器适配器

◆NET.MSMQ 侦听器适配器