WCF4.0新特性体验(7):IIS无SVC文件托管WCF服务（IIS hosting without an SVC file ）-阿里云开发者社区

今天我来继续学习WCF4.0新特性体验(7):IIS无SVC文件托管WCF服务（IIS hosting without an SVC file ）。这个是在WCF4.0中提供的一个新特性。在这一节里，我会介绍WCF服务实例化的机制，其中介绍两个主要的类型通道分发器和服务宿（ChannelDispatcher和ServiceHost）。它们与服务激活的关系。最后给出详细的开发过程。

【1】基本概念：

　　Fileless Hosting也就是IIS hosting WCF Service without an SVC file ，中文意思，也就是无svc文件托管WCF服务。

【2】服务实例化：

　　我们知道在4.0之前的版本，创建IIS托管的WCF服务程序，默认都会生成一个对应的svc文件。这个和Asp.net Web服务的ASMX文件作用类似，也就是设置一些重要的功能，比如code-behind.代码后置。在svc文件里，我们可以看到一些主要的信息：

<%@ ServiceHost Language="C#" Debug="true" Service="Service" CodeBehind="~/App_Code/Service.cs" %>

　　上面的声明通知 .svc 处理程序要在哪个类中查找 WebMethod，该处理程序就会神奇地处理其余所有事情。例如，假设虚拟目录的名称为 'service1'，它包含'service1'.svc 以及一个包含该程序集的 bin 子目录。

【3】通道分发器：

　　这里一个重要的类型就是通道分发器ChannelDispatcher，它会负责把特定的消息与服务实例关联起来，并发特定的消息转发给服务实例。

使用绑定创建通道侦听器
管理通道侦听器上的通道
管理侦听工作
管理通道侦听器和通道堆栈
控制从通道堆栈接收消息的节奏（也称作限流throttling）
管理服务实例的创建、生命周期和数量
路由消息到特定的服务实例
把接收的消息反序列化为特定的对象
使用这个对象来调用服务实例上的方法
序列化返回结果到应答消息里
路由应答消息到特定的通道堆栈，然后通过通道堆栈发送给客户端
处理以上任务异常
管理以上任务默认和指定的执行行为

【4】 ServiceHost 类型：

　　ChannelDispatcher、EndpointDispatcher、DispatchRuntime和DispatchOperation类型不可以在ServiceHost 或ServiceHostBase的实例上下文环境之外使用。事实上，如果我们尝试单独使用的话，ChannelDispatcher会抛出一个InvalidOperationException异常。在接收程序里，ServiceHost位于调用堆栈的顶部，而且它封装了ChannelDispatcher、EndpointDispatcher、DispatchRuntime和DispatchOperation类型的复杂性。ServiceHost类型定义了一个容易使用的API，它简化了侦听终结点的工作。在运行时，ServiceHost类型最终要调用通道侦听器、通道堆栈、ChannelDispatcher、EndpointDispatcher、DispatchRuntime和DispatchOperation。本质上，ServiceHost类型借助本书里介绍的类型来构造一个完整的消息接收程序，因此，开发者不需要再去实现复杂的底层机制。

【5】无svc文件服务激活的原理：

　　在WCF4.0里，通过提供一种虚拟的服务类型映射机制来实现WCF服务的激活。我们可以在配置文件里指定服务类型和相对地址之间的映射关系。这就使得我们可以在不是要.svc文件的情况下，在WAS/IIS里托管WCF服务程序。

　　关于服务激活，这里一个重要的类型就是serviceActivation。我们可以定义服务类型和相对地址之间的映射关系。在配置文件里serviceActivations节点属于serviceHostingEnvironment>。一个简单的服务类型和相对地址之间的映射如下：

　使用这个配置，我们就可以在WCF4.0里，无svc文件激活MyService.

注意 < serviceHostingEnvironment >属于一个应用程序级别的配置。我们必须把它放置在<system.serviceModel>
节点下。此外，serviceHostingEnvironment继承自machinetoApplication。如果我们在machine注册单个服务，程序里的每个服务必须继承该服务。

Configuration-based activation supports activation over both http and non-http protocol. It requires extensions in the relatativeAddress i.e. .svc, .xoml or .xamlx. You can map your own extensions to the know buildProviders, which will then enable you to activate service over any extension. Upon conflict, the <serviceActivations> section overrides .svc registrations.

　　这种通过配置设置的激活映射，支持http和非http协议。我们需要在相对地址relatativeAddress 里扩展文件名，例如.svc、.xoml 或.xamlx。我们也可以定义自己的处理扩展组件，然后在这里配置，那么WCF也会做类似的映射。为了避免冲突，我们在配置文件里定义的 <serviceActivations>会代替svc的内容。也就是配置文件的设置优先级会比较高。

【6】开发过程详解：

【6.1】创建一个WCF服务项目：

　　这里就是用Visual Studio直接创建一个默认的WCF服务程序，也就是IIS托管的项目类型。服务契约和服务类型的定义非常简单：

public class Service : IService
{
        public void DoWork()
        {
        }
}
[ServiceContract]
public interface IService
{
        [OperationContract]
        void DoWork();
}

这里默认WCF会创建一个附加的svc文件。我们这里手动删除。

【6.2】配置服务激活选项：

这里要配置服务激活相关的选项：

relativeAddress是相对地址， service是我们定义的服务的名字，记住这里不要把 service设置为契约名字，否则会出现错误。

【6.3】IIS部署：

这里我们使用的是IIS6（IIS7的部署可能存在差别，但是基本操作是类似的），来部署WCF服务，过程很简单。