WCF技术剖析之三:如何进行基于非HTTP的IIS服务寄宿

原文:[原创]WCF技术剖析之三:如何进行基于非HTTP的IIS服务寄宿

上面一篇文章中,我们对不同版本的IIS,以及ASP.NET得的实现机制进行了详细而深入的分析。在介绍IIS7.0的时候,我们谈到,HTTP.SYS+W3SVC实现了基于HTTP的请求监听,在此基础上引入了以下三组网络监听器(Listener)和监听适配器(Adapter),实现了基于TCP、Named Pipes和MSMQ的网络监听,图1揭示了IIS7的总体结构。

  • TCPListener|TCP Listener Adapter
  • NamedPipes Listener|Named Pipes Listener Adapter
  • MSMQ Listener|MSMQ Listener Adapter

图1 IIS 7总体架构

由于IIS 7提供了基于非HTTP网络协议的监听支持,那么就意味着当我们当我们通过IIS进行WCF服务寄宿(Hosting)的时候,可以采用非HTTP的通信方式。在本篇文章中,我们将通过一个简单实例介绍进行非HTTP的IIS服务寄宿,Source Code下载WasHostingDemo.zip

由于IIS 7在本质上通过WAS(Windows Process Activation Service)实现了非HTTP的请求监听,我们也可以将这种方式的服务寄宿称为基于WAS的服务寄宿。在本实例中,我们通过IIS 7实现基于TCP的服务寄宿,图2表示实例应用在VS2008种的解决方案结构。其中,Class Library类型的项目Contracts用于定义服务契约;而Services则用于定义具体的服务;Console应用项目Client模拟客户端。此外,Services对应目录被映射为IIS相应站点下的某个Web应用,虚拟目录名称为WasHostingDemo。

 

图2 基于TCP的IIS服务寄宿实例在VS2008中的解决方案结构

步骤一:定义服务契约和服务

本实例仍然采用我们熟悉的计算服务的例子,在Contracts项目下,定义了接口ICalculator代表计算服务的服务契约。

1: using System.ServiceModel;
2: 
3: namespace Artech.WasHostingDemo.Contracts
4: {
5:     [ServiceContract(Namespace="http://www.artech.com/")]
6:    public interface ICalculator
7:     {
8:         [OperationContract]
9:        double Add(double x, double y);
0:     }
1: }

在Services项目中,实现了ICalculator接口,提供服务的实现:

1: using Artech.WasHostingDemo.Contracts;
2: 
3: namespace Artech.WasHostingDemo.Services
4: {
5:    public class CalculatorService:ICalculator
6:     {
7:         #region ICalculator Members
8: 
9:         public double Add(double x, double y)
0:         {
1:             return x + y;
2:         }
3: 
4:         #endregion
5:     }
6: }

和普通基于HTTP的IIS服务寄宿一样,我们需要为WCF服务创建相应的.SVC文本文件,该文件一般仅仅包含一个<%@ ServiceHost%>指令。简单起见,我仅仅添加了唯一一个必需的Service属性(Attribute)。我把该文件命名为CalculatorService.svc,下面是该.SVC的全部内容:

<%@ ServiceHost Service="Artech.WasHostingDemo.Services.CalculatorService,Artech.WasHostingDemo.Services"%>

然后,将Services所在的目录映射为IIS下的虚拟目录。在本例中,在IIS 7的Default Web Site站点下,创建了一个命名为WasHostingDemo的Web应用,并将其物理地址指定为Services项目所在的目录。然后在根目录下创建一个Web.config,配置WCF服务寄宿相关的设置。整个WCF配置如下,Binding类型指定为NetTcpBinding。

1: <?xml version="1.0" encoding="utf-8" ?>
2: <configuration>
3:     <system.serviceModel>
4:         <services>
5:             <service name="Artech.WasHostingDemo.Services.CalculatorService">
6:                 <endpoint address="" binding="netTcpBinding" bindingConfiguration=""
7:                     contract="Artech.WasHostingDemo.Contracts.ICalculator" />
8:             </service>
9:         </services>
0:     </system.serviceModel>
1: </configuration>

注:由于ASP.NET应用在运行的时候默认从根目录下的Bin子目录加载Assembly,而Services项目默认编译的目标目录为Bin\Debug|Release,所以我们需要通过修改项目属性将编译的目标目录设为Bin。

步骤二:为站点设置TCP绑定,为Web应用添加支持协议

进行非HTTP的服务寄宿是WAS为WCF提供的最显著的特性。由于在默认的情况下,IIS仅仅支持对于HTTP请求的处理,我们需要相应的方式对IIS相关配置进行相关的修改,从而改变IIS默认的请求处理行为。在上面我们说过,IIS 7.0广泛采用了基于XML文件的配置方式,所以最终极的方式就是直接修改相应的配置文件。但是,直接修改配置文件的方式,出错的频率很高,对于很多的配置,我们都可以直接通过IIS管理器进行相应的修改。此外,我们可以选择通过命令行的方式修改相应的配置,IIS为我们提供了一系列的命令。

WAS的配置保存在配置文件applicationHost.config中,该文件保存在%windir%\system32\inetsrv\config目录中。为了实现基于非HTTP的服务寄宿,首先需要做的是为WCF Service的寄宿应用所在的Web Site添加非相应非HTTP协议的站点绑定(site binding),该操作可以通过执行Appcmd.exe命名实现,该命名存放在%windir%\system32\inetsrv\目录中。

为了使寄宿WCF服务的Web站点具有基于TCP的监听能力,我们可以通过下面的命名行为该站点(Default Web Site)添加基于TCP的绑定,指定监听端口为808(默认端口)。

appcmd.exe set site "Default Web Site" -+bindings.[protocol=‘net.tcp‘,bindingInformation=‘808:*‘]

站点绑定添加于修改也可以直接通过IIS管理器进行:选择相应站点=〉在右边的部分“Bindings”=〉在弹出的Site Bindings对话框中可以添加新的站点绑定和编辑现有的站点绑定,如图3所示。

 

3 通过IIS管理器设置站点绑定

在站点级别非HTTP绑定存在的情况下,你还可在应用级别控制对非HTTP协议的支持。在默认的情况下,Web应用并不提供对非HTTP协议的支持,你需要通过AppCmd.exe为应用添加对于某个非HTTP协议支持的能力。通过下面的配置对默认站点下的WasHostingDemo应用添加了对net.tcp支持的能力。

appcmd.exe set app "Default Web Site/WasHostingDemo" /enabledProtocols:net.tcp

步骤三:创建客户端程序进行服务调用

对于调用非HTTP协议的IIS寄宿服务的客户端来说,和普通的WCF服务调用完全一样,下面是服务调用代码和相关的配置。由于,客户端程序通过访问WCF服务的.SVC文件的方式进行服务的调用,所以在相应终结点中的地址为.SVC所在的地址。

1: using System;
2: using System.ServiceModel;
3: using Artech.WasHostingDemo.Contracts;
4: 
5: namespace Artech.WasHostingDemo.Client
6: {
7:     class Program
8:     {
9:         static void Main(string[] args)
0:         {
1:             using (ChannelFactory<ICalculator> channelFactory = new ChannelFactory<ICalculator>("calculatorservice"))
2:             {
3:                 ICalculator calculator = channelFactory.CreateChannel();
4:                 using (calculator as IDisposable)
5:                 {
6:                     try
7:                     {
8:                         Console.WriteLine("x + y = {2} when x = {0} and y = {1}", 1, 2, calculator.Add(1, 2));
9:                     }
0:                     catch (CommunicationException)
1:                     {
2:                         (calculator as ICommunicationObject).Abort();
3:                         throw;
4:                     }
5:                     catch (TimeoutException)
6:                     {
7:                         (calculator as ICommunicationObject).Abort();
8:                         throw;
9:                     }
0:                 }
1:             }
2:         }
3:     }
4: } 
   1: <?xml version="1.0" encoding="utf-8" ?>

   2: <configuration>
   3:   <system.serviceModel>
   4:     <client>
   5:       <endpoint address="net.tcp://127.0.0.1/WasHostingDemo/CalculatorService.svc"
   6:       binding="netTcpBinding" bindingConfiguration="" contract="Artech.WasHostingDemo.Contracts.ICalculator"
   7:       name="calculatorservice" />
   8:     </client>
   9:   </system.serviceModel>
  10: </configuration>

通过运行客户端程序,你将得到如下的输出:

   1: x + y = 3 when x = 1 and y = 2
时间: 2024-10-07 21:05:35

WCF技术剖析之三:如何进行基于非HTTP的IIS服务寄宿的相关文章

WCF技术剖析之三十:一个很有用的WCF调用编程技巧[下篇]

原文:WCF技术剖析之三十:一个很有用的WCF调用编程技巧[下篇] 在<上篇>中,我通过使用Delegate的方式解决了服务调用过程中的异常处理以及对服务代理的关闭.对于<WCF技术剖析(卷1)>的读者,应该会知道在第7章中我通过类似于AOP的方式解决了相似的问题,现在我们来讨论这个解决方案. 通过<服务代理不能得到及时关闭会有什么后果?>的介绍,我们知道了及时关闭服务代理的重要意义,并且给出了正确的编程方式.如果严格按照上面的编程方式,就意味着对于每一个服务调用,都要

WCF技术剖析之三十:一个很有用的WCF调用编程技巧[上篇]

原文:WCF技术剖析之三十:一个很有用的WCF调用编程技巧[上篇] 在进行基于会话信道的WCF服务调用中,由于受到并发信道数量的限制,我们需要及时的关闭信道:当遇到某些异常,我们需要强行中止(Abort)信道,相关的原理,可以参考我的文章<服务代理不能得到及时关闭会有什么后果?>.在真正的企业级开发中,正如我们一般不会让开发人员手工控制数据库连接的开启和关闭一样,我们一般也不会让开发人员手工去创建.开启.中止和关闭信道,这些工作是框架应该完成的操作.这篇文章,我们就来介绍如果通过一些编程技巧,

《WCF技术剖析》博文系列汇总[持续更新中]

http://www.cnblogs.com/artech/archive/2009/11/21/1607686.html 近半年以来,一直忙于我的第一本WCF专著<WCF技术剖析(卷1)>的写作,一直无暇管理自己的Blog.在<WCF技术剖析(卷1)>写作期间,对WCF又有了新的感悟,为此以书名开始本人的第三个WCF系列.本系列的目的在于对<WCF技术剖析>的补充,会对书中的一些内容进行展开讲述,同时会囊括很多由于篇幅的原因忍痛割弃的内容. [第1篇] 通过一个ASP

WCF技术剖析之十八:消息契约(Message Contract)和基于消息契约的序列化

在本篇文章中,我们将讨论WCF四大契约(服务契约.数据契约.消息契约和错误契约)之一的消息契约(Message Contract).服务契约关注于对服务操作的描述,数据契约关注于对于数据结构和格式的描述,而消息契约关注的是类型成员与消息元素的匹配关系. 我们知道只有可序列化的对象才能通过服务调用在客户端和服务端之间进行传递.到目前为止,我们知道的可序列化类型有两种:一种是应用了System.SerializableAttribute特性或者实现了System.Runtime.Serializat

WCF技术剖析之四:基于IIS的WCF服务寄宿(Hosting)实现揭秘

原文:WCF技术剖析之四:基于IIS的WCF服务寄宿(Hosting)实现揭秘 通过<再谈IIS与ASP.NET管道>的介绍,相信读者已经对IIS和ASP.NET的请求处理管道有了一个大致的了解,在此基础上去理解基于IIS服务寄宿的实现机制就显得相对容易了.概括地说,基于IIS的服务寄宿依赖于两个重要的对象:System.ServiceModel.Activation.HttpModule和System. ServiceModel.Activation.HttpHandler. 一.通过Htt

WCF技术剖析之六:为什么在基于ASP.NET应用寄宿(Hosting)下配置的BaseAddress无效

原文:WCF技术剖析之六:为什么在基于ASP.NET应用寄宿(Hosting)下配置的BaseAddress无效 本篇文章来源于几天前一个朋友向我咨询的问题.问题是这样的,他说他采用ASP.NET应用程序的方式对定义的WCF服务进行寄宿(Hosting),并使用配置的方式对服务的BaseAddress进行了设置,但是在创建ServiceHost的时候却抛出InvalidOperationException,并提示相应Address Scheme的BaseAddress找不到.我意识到这可能和WC

WCF技术剖析之二:再谈IIS与ASP.NET管道

原文:WCF技术剖析之二:再谈IIS与ASP.NET管道 在2007年9月份,我曾经写了三篇详细介绍IIS架构和ASP.NET运行时管道的文章,深入介绍了IIS 5.x与IIS 6.0HTTP请求的监听与分发机制,以及ASP.NET运行时管道对HTTP请求的处理流程: [原创]ASP.NET Process Model之一:IIS 和 ASP.NET ISAPI [原创]ASP.NET Process Model之二:ASP.NET Http Runtime Pipeline - Part I

WCF技术剖析之九:服务代理不能得到及时关闭会有什么后果?

原文:WCF技术剖析之九:服务代理不能得到及时关闭会有什么后果? 我们想对WCF具有一定了解的人都会知道:在客户端通过服务调用进行服务调用过程中,服务代理应该及时关闭.但是如果服务的代理不等得到及时的关闭,到底具有怎样的后果?什么要关闭服务代理?在任何时候都需要关闭服务代理吗?是否有一些例外呢?本篇文章将会围绕着这些问题展开. 一.会话信道(Sessionful Channel) V.S. 数据报信道(Datagram Channel) WCF通过信道栈实现了消息的编码.传输及基于某些特殊功能对

WCF技术剖析之十:调用WCF服务的客户端应该如何进行异常处理

原文:WCF技术剖析之十:调用WCF服务的客户端应该如何进行异常处理 在前面一片文章(服务代理不能得到及时关闭会有什么后果?)中,我们谈到及时关闭服务代理(Service Proxy)在一个高并发环境下的重要意义,并阐明了其根本原因.但是,是否直接调用ICommunicationObject的Close方法将服务代理关闭就万事大吉了呢?事情远不会这么简单,这其中还会涉及关于异常处理的一些操作,这就是本篇文章需要讨论的话题. 一.异常的抛出与Close的失败 一般情况下,当服务端抛出异常,客户客户