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.Contracts4: {5:     [ServiceContract(Namespace="http://www.artech.com/")]6:    public interface ICalculator7:     {8:         [OperationContract]9:        double Add(double x, double y);0:     }1: }

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

1: using Artech.WasHostingDemo.Contracts;2:3: namespace Artech.WasHostingDemo.Services4: {5:    public class CalculatorService:ICalculator6:     {7:         #region ICalculator Members8:9:         public double Add(double x, double y)0:         {1:             return x + y;2:         }3:4:         #endregion5:     }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。

以上是小编为您精心准备的的内容,在的博客、问答、公众号、人物、课程等栏目也有的相关内容,欢迎继续使用右上角搜索按钮进行搜索iis
, 监听
, services
, 服务
, listener
, 非web项目
, 基于
, 寄宿方式
非站点目录
,以便于您获取更多的相关知识。

时间: 2024-12-30 21:35:40

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

WCF技术剖析之三十一: WCF事务编程[中篇]

[续<上篇>]通过将TransactionFlowAttribute特性应用在服务契约的某个操作之上,并指定相应的TransactionFlowOption枚举直,仅仅定义了事务流转的策略而已.或者说,通过这种方式确定对事物流转的一种意愿,客户端是否愿意将当前事务流出,服务端是否愿意接受流入的事务,可以通过TransactionFlowAttribute特性进行控制.所以说,服务操作上定义个TransactionFlowAttribute特性是是否进行事务流转的总开关,真正的事务传播是建立在T

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

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

WCF技术剖析之三十二:一步步创建一个完整的分布式事务应用

在完成了对于WCF事务编程(<上篇>.<中篇>.<下篇>)的介绍后,本篇文章将提供一个完整的分布式事务的WCF服务应用,通过本例,读者不仅仅会了解到如何编程实现事务型服务,还会获得其他相关的知识,比如DTC和AS-AT的配置等.本例还是沿用贯通本章的应用场景:银行转帐.我们将会创建一个BankingService服务,并将其中的转帐操作定义成事务型操作.我们先从物理部署的角度来了解一下BankingService服务,以及需要实现怎样的分布式事务. 一.从部署的角度看分

WCF技术剖析之三十一: WCF事务编程[下篇]

在WCF事务编程模型下,通过服务契约确定事务流转的策略(参阅<上篇>),通过事务绑定实施事务的流转(参阅<中篇>).但是,对于事务绑定接收到并成功创建的事务来说,服务操作的执行是否需要自动登记到该事务之中,以及服务操作采用怎样的提交方式,这就是服务端自己说了算了.正因为如此,WCF通过服务(操作)行为的形式定义事务的登记和提交(完成)方式. 一.事务的自动登记(Enlistment)与提交(完成) 在OperationBehaviorAttribute特性(其本身是一个操作行为)中

WCF技术剖析之三十一:WCF事务编程[上篇]

WCF事务编程其实很简单,可以用三句话进行概括:通过服务契约决定事物流转(Transaction Flow)的策略:通过绑定实施事务的流转:通过服务行为控制事务的相关行为.本篇文章着重介绍如果通过TransactionFlowAttribute特性定义事务流转策略.  契约时是一种双边协定,是双方就某个关注点达成的一种共识.对于分布式事务的实现来讲,首先需要解决的是事务流转的问题,即事务将客户端的事务流向服务端.要解决事务流转的问题,需要在事务的发送方和接收方就流转问题达成共识,即双方采用相匹配

WCF 技术剖析之三十三:你是否了解WCF事务框架体系内部的工作机制?[下篇]

[续<上篇>]TransactionFlow选项通过TransactionFlowAttribute这个操作契约写入绑定上下文,由事务绑定创建的事务信道获取该选项并以此作为首否对事务实施传播(发送或者接收)的依据.客户端事务信道通过TransactionFormatter对当前事务按照指定的事务处理协议进行格式化,并嵌入出栈消息:通过TransactionFormatter则从入栈消息中提取相应的数据重建事务.这就是事务流转实现的本质.整个WCF事务还有一个重要的步骤需要实现:如何将通过Ope

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

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

WCF技术剖析系列文章汇总

WCF技术剖析之三十:一个很有用的WCF调用编程技巧[下篇] WCF技术剖析之三十:一个很有用的WCF调用编程技巧[上篇] WCF技术剖析之二十九:换种不同的方式调用WCF服务 WCF技术剖析之二十八:自己动手获取元数据 WCF技术剖析之二十七: 如何将一个服务发布成WSDL[基于HTTP-GET的 WCF技术剖析之二十七: 如何将一个服务发布成WSDL WCF技术剖析之二十七: 如何将一个服务发布成WSDL[编程篇] WCF技术剖析之二十六:如何导出WCF服务的元数据(Metadata)[扩展

WCF技术剖析之八:ClientBase&lt;T&gt;中对ChannelFactory&lt;T&gt;的缓存机制

和传统的分布式远程调用一样,WCF的服务调用借助于服务代理(Service Proxy).而ChannelFactory<T>则是服务代理的创建者.WCF采用基于终结点(Endpoint)服务消费方式:WCF服务通过一个或者多个终结点暴露给潜在的服务消费者,服务的消费中通过与之匹配的终结点与之交互.在客户端,我们具有两种典型的服务代理创建方式,其一是通过诸如SvcUtil.exe这样的工具导入服务的元数据生成相应的服务代理(一个继承自ClientBase<T>的类型)代码和相关配置