随笔分类 - WCF

摘要:本文介绍应用程序中添加书籍的保存功能,涉及两个功能“新增”与“修改”。异常处理的小结。 阅读全文
posted @ 2016-12-01 17:13 DotNet菜园 阅读(2565) 评论(1) 推荐(5) 编辑
摘要:在上一篇文章中我们创建了WCF服务端应用程序,在这一篇文章中我们来学习如何创建WCF的服务端寄宿程序与客户端调用程序。 阅读全文
posted @ 2016-11-17 10:12 DotNet菜园 阅读(1588) 评论(0) 推荐(0) 编辑
摘要:在上一篇文章中我们创建了实体对象与接口协定,在这一篇文章中我们来学习如何创建WCF的服务端代码。创建项目BookMgr.Service的WCF服务代码。 阅读全文
posted @ 2016-11-09 13:42 DotNet菜园 阅读(1601) 评论(0) 推荐(1) 编辑
摘要:在项目BookMgr.Model创建实体类数据 阅读全文
posted @ 2016-11-02 16:01 DotNet菜园 阅读(1592) 评论(0) 推荐(0) 编辑
摘要:通过前面二十几个章节的学习,我们知道了什么是WCF;WCF中的A、B、C;WCF的传输模式;WCF的寄宿方式;WCF的异常处理。本文综合应用以上知识点,一步一步写一个小的WCF应用程序——书籍管理系统(BookMgr)。 这个示例就是一个非常简单的书籍管理系统,功能有:查询、修改、新增、删除(不包括安全、优化等相关问题)、异常处理。WCF的增删改查和WinForm相差无几。WCF只是把具体“实现”写在“服务端”,而“调用”放在了“客户端”。 阅读全文
posted @ 2016-10-27 10:57 DotNet菜园 阅读(2065) 评论(1) 推荐(0) 编辑
摘要:对于路由的实现,本质上就是实现逻辑地址和物理地址的分离。通过前面的示例介绍,我们了解,如何在客户端实现TcpTracer捕获客户端与服务端的通信信息。在这一章节中我们学习如能通过设置ListenUri实现基于服务端的TcpTracer的消息路由。 服务端的物理地址和逻辑地址的分离通过ListenUri实现,ListenUri指定了服务的物理地址,大家可能觉得奇怪,我们设置服务地址的时候一般都是设 置Address(ABC的一部分),但是Address指定的是逻辑地址,而ListenUri指定的是物理地址,如果指定了这个属性的值,那么就指定了服务的物理地址。 阅读全文
posted @ 2016-09-29 15:41 DotNet菜园 阅读(2456) 评论(1) 推荐(1) 编辑
摘要:首先来讲讲TcpTrace实现的基本原理。说简单点,TcpTracer就是一个监听/转发器(Listening/Forwarding),就是一个路由器。当启动的时候,我们需要设置两个端口:监听端口(Listening Port)和目的主机(Destination Server)与目的端口(Destination Port),然后TcpTracer就会在本机的监听端口进行网络监听。一旦有针对该监听端口的请求抵达,他会截获整个请求的消息,并将整个消息显示到消息面板上。随后,TcpTracer会将该消息原封不动地转发给目的主机与目的端口。在另一方面,从目的主机与目的端口发送给原端口的消息,也同样被TcpTracer截获、显示和转发。 说白了就是把要发的消息先给我们查看和备份,再转发出去。 阅读全文
posted @ 2016-09-22 17:13 DotNet菜园 阅读(4201) 评论(0) 推荐(4) 编辑
摘要:为了强调REST的通用性,客户端不用WCF的形式调用服务,而是采用HttpWebResponse通过编程方式直接访问,消息格式我们选XML。 阅读全文
posted @ 2016-09-15 13:53 DotNet菜园 阅读(2439) 评论(0) 推荐(3) 编辑
摘要:本文讲解一下如何创建一个支持REST的WCF服务端程序。 阅读全文
posted @ 2016-08-30 10:56 DotNet菜园 阅读(1644) 评论(0) 推荐(1) 编辑
摘要:WCF如何实现对于Rest支持的呢?弄清这一点是学习Rest WCF的关键。 为了实现于对Rest的支持,在 .NET Framework 中,WCF 在 System.ServiceModel.Web 组件中新增了编程模型和一些基础架构部件。WCF Web编程模型几个重要类型就是: 阅读全文
posted @ 2016-08-25 14:39 DotNet菜园 阅读(1935) 评论(2) 推荐(1) 编辑
摘要:在一个基于面向服务的分布式环境中,借助一个标准的、平台无关的通信协议,使各个服务通过SOAP Message实现相互之间的交互。这个交互的过程实际上就是信息交换的过程。WCF支持不同形式的信息交换,我们把这称之为信息交换模式(Message Exchange Pattern(简称MEP),下同), 常见的MEP包括: 请求/答复,单向模式和双工模式。通过采用双工的MEP,我们可以实现在服务端调用客户端的操作。虽然WCF为我们实现底层的通信细节,使得我们把精力转移到业务逻辑的实现,进行与通信协议无关的编程,但是对通信协议的理解有利于我们根据所处的具体环境选择一个合适的通信协议。说到通信协议, WCF 经常使用的是以下4个:Http,TCP,Named Pipe,MSMQ。 阅读全文
posted @ 2016-08-16 13:03 DotNet菜园 阅读(4000) 评论(1) 推荐(4) 编辑
摘要:双工模式建立在上文所实现的两种模式的基础之上,实现客户端与服务端相互调用:前面介绍的两种方法只是在客户端调用服务端的方法,然后服务端有返回值返回客户端;相互调用是指客户端调用服务端的方法,同时服务端也可以调用客户端的方法。 基于双工MEP (信息交换模式,Message Exchange Pattern,下同)消息交换可以看成是多个基本模式下 (比如请求-回复模式和单项模式)消息交换的组合。双工MEP又具有一些变体,比如典型的订阅-发布模式就可以看成是双工模式的一种表现形式。 阅读全文
posted @ 2016-08-08 14:36 DotNet菜园 阅读(3254) 评论(4) 推荐(4) 编辑
摘要:客户端发送请求,然后一直等待服务端的响应(异步调用除外),期间处于假死状态,直到服务端有了答复后,客户端才会继续向下执行,这种方式相对单向模式来说灵活性差,但是安全性高,因为是单线程的所以安全性极高,适用于有数据返回的请求。 阅读全文
posted @ 2016-07-26 16:27 DotNet菜园 阅读(2142) 评论(1) 推荐(3) 编辑
摘要:第二个示例是通过定制ServiceDebug来获取服务端的异常,但是这种方式只能用于Debug阶段。在我们的WCF应用发布之后,这种获取异常的方式无法在我们的工作环境中使用。我们必须找到一种异常处理方式可以在客户端获取相应的异常提示信息。那就是我们接下来要介绍的基于FaultContract的解决方案。我们知道WCF采用一种基于 Contract,Contract定义了进行交互的双方进行消息交换所遵循的准则和规范。Service Contract定义了包含了所有Operation的Service的接口,Data Contract定义了交互的数据的结构,而FaultContract实际上定义需要再双方之间进行交互的了异常、错误的表示。现在我们来学习如何使用基于FaultContract的异常处理。 阅读全文
posted @ 2016-07-19 13:24 DotNet菜园 阅读(2024) 评论(2) 推荐(1) 编辑
摘要:从前面的示例中,可以看到客户端捕获了异常,这是我们处理异常的前提。为了有利于我们进行有效的调试,WCF提供了ServiceDebug Service Behavior。我们可以通过设置属性设为true,那么如果服务端抛出异常,WCF会简单得包装这个异常并把它置于Soap中Response到服务端的访问者。现在,我们简单修改一下 Hosting的配置信息,添加一个 阅读全文
posted @ 2016-07-12 16:50 DotNet菜园 阅读(2803) 评论(0) 推荐(1) 编辑
摘要:在软件开发过程中,不可能没有异常的出现,所以在开发过程中,对不可预知的异常进行解决时,异常处理显得尤为重要。对于一般的.NET系统来说,我们简单地借助try/catch可以很容易地实现这一功能。但是对于 一个分布式的环境来说,异常处理就没有那么简单了。按照面向服务的原则,我们把一些可复用的业务逻辑以服务的形式实现,各个服务处于一个自治的环境中,一个服务需要和另一个服务进行交互,只需要获得该服务的描述(Description)就可以了(比如 WSDL,Schema和Strategy)。借助标准的、平台无关的通信构架,各个服务之间通过标准的Soap Message进行交互。Service Description、Standard Communication Infrastructure、Soap Message based Communication促使各服务以松耦合的方式结合在一起。但是由于各个服务是自治的,如果一个服务调用另一个服务,在服务提供方抛出的Exception必须被封装在Soap Message中,方能被处于另一方的服务的使用者获得、从而进行合理的处理。下面我们结合一个简单的 阅读全文
posted @ 2016-07-06 15:08 DotNet菜园 阅读(2126) 评论(1) 推荐(2) 编辑
摘要:WCF4.0为了简化服务配置,提供了默认的终结点、绑定和服务行为。也就是说,在开发WCF服务程序的时候,即使我们不提供显示的 服务终结点,WCF框架也能为我们的服务提供一些默认配置功能的服务终结点。当然也包含默认的绑定和默认的服务行为。这一切都是为了简化配置过程,避免一 些不必要的错误。 阅读全文
posted @ 2016-06-29 17:43 DotNet菜园 阅读(2776) 评论(0) 推荐(6) 编辑
摘要:我们在前面章节中讲了寄宿,在前面的实例中也用到了配置文件,这一篇主要讲讲如何在应用配置文件,提高WCF程序的灵活性。在编写WCF服务应用程序时,编写配置项也是其中一项主要工作,在前面的几个示例中我也使用过配置文件,通过配置文件来简化代码。WCF通过公开终结点,向客户端公开服务,包括服务的地址、服务用于发送和接收消息的传输和消息编码,以及服务需要的安全类型等。当我们把这些配置项写入到配置文件后,我们无需编译即可修改WCF的一些可变信息,提高了程序的灵活性。 阅读全文
posted @ 2016-06-21 14:35 DotNet菜园 阅读(2284) 评论(0) 推荐(2) 编辑
摘要:在WCF4.0里,通过提供一种虚拟的服务类型映射机制来实现WCF服务的激活。我们可以在配置文件里指定服务类型和相对地址之间的映射关系。这就使得我们可以在不是要.svc文件的情况下,在WAS/IIS里托管WCF服务程序。 阅读全文
posted @ 2016-06-13 16:10 DotNet菜园 阅读(2714) 评论(0) 推荐(2) 编辑
摘要:IIS7允许通过HTTP外的协议进行激活和网络通信。此环境适合开发可通过 WCF支持的任何网络协议(包括http、net.tcp、net.pipe、net.msmq)进行通信的WCF服务。部署简单、管理方便,这些网络协议在部署时可像Http一样,直接丢到IIS7上即可,我们在下面的例子中以net.tcp为协议为例。IIS7以下的版本只能支持Http的通信。 阅读全文
posted @ 2016-06-03 17:15 DotNet菜园 阅读(2623) 评论(1) 推荐(3) 编辑