Loading [MathJax]/jax/output/CommonHTML/config.js
前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >[WCF REST] 一个简单的REST服务实例

[WCF REST] 一个简单的REST服务实例

作者头像
蒋金楠
发布于 2018-01-16 12:02:11
发布于 2018-01-16 12:02:11
7510
举报
文章被收录于专栏:大内老A大内老A

微软在WCF 3.5中就通过提供基于Web HTTP的编程模式使我们很容易地创建基于REST的服务,WCF 4.0中对此进行了较大的改进。为了让读者对REST在WCF中的应用有一个大致的了解,我们先来进行一个简单的实例演示。 [源代码从这里下载]

一、定义服务契约

在这个实例中,我们创建一个简单的服务来管理员工的基本信息。至于实例程序的结构,我们依然采用熟悉的包含三个项目(Service.Interface、Service和Client)的解决方案。如下所示的是定义在Service.Interface中用于表示员工的Employee类的定义,它是一个数据契约。

代码语言:js
AI代码解释
复制
   1: [DataContract(Namespace="http://www.artech.com/")]
   2: public class Employee
   3: {
   4:     [DataMember]
   5:     public string Id { get; set; }
   6:  
   7:     [DataMember]
   8:     public string Name { get; set; }
   9:  
  10:     [DataMember]
  11:     public string Department { get; set; }
  12:  
  13:     [DataMember]
  14:     public string Grade { get; set; }
  15:  
  16:     public override string ToString()
  17:     {
  18:         return string.Format("ID: {0,-5}姓名: {1, -5}级别: {2, -4} 部门: {3}",Id, Name, Grade, Department);
  19:     }
  20: }

接下来我们定义了如下一个表示服务契约的接口IEmployeesService。和基于SOAP的服务契约定义不同,我们无需在相应的操作方法上面应用OperationContractAttribute特性,但是应用在接口/类上的ServiceContractAttribute特性仍是必需的。在这里替换OperationContractAttribute特性的分别是WebGetAttributeWebInvokeAttribute,它们均定义在System.ServiceModel.Web程序集中。

代码语言:js
AI代码解释
复制
   1: [ServiceContract(Namespace="http://www.artech.com/")]
   2: public interface IEmployees
   3: {
   4:     [WebGet(UriTemplate = "all")]
   5:     IEnumerable<Employee> GetAll();
   6:  
   7:     [WebGet(UriTemplate = "{id}")]
   8:     Employee Get(string id);
   9:  
  10:     [WebInvoke(UriTemplate = "/", Method = "POST")]
  11:     void Create(Employee employee);
  12:  
  13:     [WebInvoke(UriTemplate = "/", Method = "PUT")]
  14:     void Update(Employee employee);
  15:  
  16:     [WebInvoke(UriTemplate = "{id}", Method = "DELETE")]
  17:     void Delete(string id);
  18: }

契约接口IEmployeesService中定义了5个操作,分别用于实现针对员工数据的获取、添加、修改和删除。按照REST设计原则,我们将被操作的员工信息体现为某种网络资源,而操作类型最好与相应的HTTP方法相匹配。在操作方法中针对资源的操作类型与HTTP方法之间的匹配是通过应用在它们上面的WebGetAttribute和WebInvokeAttribute特性来体现。

WebGetAttribute针对GET方法,而其他的HTTP方法则通过WebInvokeAttribute的Method属性来体现。在IEmployeesService中,两个用于获取员工信息GetAll和Get方法均应用了WebGetAttribute特性,而其他的Create、Update和Delete方法在应用了WebInvokeAttribute特性,并且其Method属性被分别设置为PUT、POST和DELETE。

WebGetAttribute和WebInvokeAttribute和均具有相同的属性UriTemplate,该属性用于定义作为最终操作URI的模板。我们不仅可以通过UriTemplate属性为操作指定一个相对于终结点地址的静态路径,还可以通过占位符实现路径中的动态部分与参数之间的映射。

同样以定义在契约接口IEmployeesService中的5个操作方法为例,如果终结点地址为http://127.0.0.1:3721/employees,由于用于返回所有员工列表的GetAll操作的UriTemplate被设置“All”,所以其地址为http://127.0.0.1:3721/employees。用于返回指定员工ID的Get操作的UriTemplate被设置成“{id}”,意味着我们直接在表示请求地址的URI中指定员工的ID,而它会自动映射为该操作方法的参数id。用于删除某个指定员工的Delete操作具有相同的UriTemplate设置,而用于创建添加新员工和修改现有员工信息的Create和Update操作,由于作为参数的Employee对象具有ID属性,所以直接采用终结点地址。

二、创建/寄宿服务

在控制台程序Service中我们定义了如下一个实现了契约接口IEmployeesService的服务类型EmployeesService。简单 起见,我们直接通过一个静态字段employees表示存储的员工列表,该静态字段在初始化的工作中被添加了两个ID分别为001和002的Employee对象。针对员工信息的获取、添加、修改和删除的操作均在此列表中进行。

代码语言:js
AI代码解释
复制
   1: public class EmployeesService : IEmployees
   2: {
   3:     private static IList<Employee> employees = new List<Employee>
   4:     {
   5:         new Employee{ Id = "001", Name="张三", Department="开发部", Grade = "G7"},    
   6:         new Employee{ Id = "002", Name="李四", Department="人事部", Grade = "G6"}
   7:     };
   8:     public Employee Get(string id)
   9:     {
  10:         Employee employee = employees.FirstOrDefault(e => e.Id == id);
  11:         if (null == employee)
  12:         {
  13:             WebOperationContext.Current.OutgoingResponse.StatusCode = 
  14:             HttpStatusCode.NotFound;
  15:         }
  16:         return employee;
  17:     }
  18:  
  19:     public void Create(Employee employee)
  20:     {
  21:         employees.Add(employee);
  22:     }
  23:  
  24:     public void Update(Employee employee)
  25:     {
  26:         this.Delete(employee.Id);
  27:         employees.Add(employee);
  28:     }
  29:  
  30:     public void Delete(string id)
  31:     {
  32:         Employee employee = this.Get(id);
  33:         if (null != employee)
  34:         {
  35:             employees.Remove(employee);
  36:         }
  37:     }
  38:  
  39:     public IEnumerable<Employee> GetAll()
  40:     {
  41:         return employees;
  42:     }
  43: }

值得一提的是,不论是用于获取某个指定ID的员工信息的Get方法,还是用于修改和删除员工记录的Update和Delete方法,当指定ID的员工不存在时都通过WebOperationContext表示当前Web操作上下文的对象将回复状态设置为NotFound(即404 Not Found),这体现了我们的服务是基于Web的。

接下来我们通过自我寄宿的方式对上面定义的EmployeesService服务进行寄宿,下面是相应的配置。我们为寄宿的服务添加了唯一一个终结点,并简单地指定了其ABC三要素。和我们之前配置的终结点不同的是,在这里我们采用的绑定类型为WebHttpBinding。

代码语言:js
AI代码解释
复制
   1: <configuration>
   2:     <system.serviceModel>
   3:     <services>
   4:         <service name="Artech.WcfServices.Service.EmployeesService">
   5:         <endpoint address="http://127.0.0.1:3721/employees" 
   6:                   binding="webHttpBinding"
   7:                   contract="Artech.WcfServices.Service.Interface.IEmployees"/>
   8:         </service>
   9:     </services>
  10:     </system.serviceModel>
  11: </configuration>

最终我们通过如下的程序进行服务的寄宿。之前我们总是使用基于服务类型创建的ServiceHost进行服务寄宿,在这里我们使用的是ServiceHost它的子类WebServiceHost

代码语言:js
AI代码解释
复制
   1: using (WebServiceHost host = new WebServiceHost(typeof(EmployeesService)))
   2: {
   3:     host.Open();
   4:     Console.Read();
   5: }

三、进行服务调用

由于我们寄宿的服务完全是基于Web的,所以和普通的Web站点没有本质的区别。由于EmployeesService服务的GetAll和Get操作支持HTTP-GET请求,所以我们完全可以在浏览器中针对操作的地址发起请求,而返回的数据可以直接显示在浏览器上。下图所示的是通过浏览器调用GetAll操作(http://127.0.0.1:3721/employees/all)得到的结果,我们可以看到所有员工的列表以XML的形式返回。

我们也可以通过浏览器调用Get操作并直接通过在地址中指定员工的ID(http://127.0.0.1:3721/employees/001)并得到以XML表示的基于相应员工的信息。下图所示XML正式ID为001的Employee对象序列化后的结果。如果在请求地址中指定一个不存在的ID(比如http://127.0.0.1:3721/employees/003),由于Get方法中指定了回复状态为NotFound,我们会得到类似于访问资源不存在的错误信息,就像访问一个不存在的Web页面一样。

上面我们演示了通过浏览器以HTTP-GET方式请求操作地址的方式从而直接将返回结果呈现出来,现在我们来演示如何使用通过ChannelFactory<TChannel>创建的服务代理进行服务调用。我们首先在作为客户端应用程序的Client项目中创建一个App.config,并定义如下的配置。

代码语言:js
AI代码解释
复制
   1: <configuration>
   2:   <system.serviceModel>
   3:     <behaviors>
   4:       <endpointBehaviors>
   5:         <behavior name="webBehavior">
   6:           <webHttp />
   7:         </behavior>
   8:       </endpointBehaviors>      
   9:     </behaviors>
  10:     <client>
  11:       <endpoint name="employeeService"
  12:         address="http://127.0.0.1:3721/employees" 
  13:         behaviorConfiguration="webBehavior"
  14:         binding="webHttpBinding" 
  15:         contract="Artech.WcfServices.Service.Interface.IEmployees"/>
  16:     </client>
  17:   </system.serviceModel>
  18: </configuration>

如上面的配置片断所示,我们定义了一个与服务端相匹配的客户端终结点,该终结点上应用了一个WebHttpBehavior终结点行为。WebHttpBehavior可以说是整个Web HTTP编程模型的核心,绝大部分针对Web的支持都是通过该行为实现的。实际上服务端终结点通过WebServiceHost应用了这个终结点行为。

代码语言:js
AI代码解释
复制
   1: using(ChannelFactory<IEmployees> channelFactory = new ChannelFactory<IEmployees>("employeeService"))
   2: {
   3:     IEmployees proxy = channelFactory.CreateChannel();
   4:  
   5:     Console.WriteLine("所有员工列表:");
   6:     Array.ForEach<Employee>(proxy.GetAll().ToArray(),employee=>Console.WriteLine(employee));
   7:  
   8:     Console.WriteLine("\n添加一个新员工(003):");
   9:     proxy.Create(new Employee
  10:     {
  11:         Id              = "003",
  12:         Name            = "王五",
  13:         Grade           = "G9",
  14:         Department      = "行政部"
  15:     });
  16:     Array.ForEach<Employee>(proxy.GetAll().ToArray(),employee => Console.WriteLine(employee));
  17:  
  18:     Console.WriteLine("\n修改员工(003)信息:");
  19:     proxy.Update(new Employee
  20:     {
  21:         Id              = "003",
  22:         Name            = "王五",
  23:         Grade           = "G11",
  24:         Department      = "销售部"
  25:     });
  26:     Array.ForEach<Employee>(proxy.GetAll().ToArray(), employee => Console.WriteLine(employee));
  27:     Console.WriteLine("\n删除员工(003)信息:");
  28:  
  29:     proxy.Delete("003");
  30:     Array.ForEach<Employee>(proxy.GetAll().ToArray(), employee => Console.WriteLine(employee));        
  31: }

服务调用程序如上所示,我们模拟了员工的添加、修改和删除。程序之后会在客户端控制台产生如下的输出。

所有员工列表:

代码语言:js
AI代码解释
复制
   1: 所有员工列表:
   2: ID: 001  姓名: 张三   级别: G7   部门: 开发部
   3: ID: 002  姓名: 李四   级别: G6   部门: 人事部
   4:  
   5: 添加一个新员工(003):
   6: ID: 001  姓名: 张三   级别: G7   部门: 开发部
   7: ID: 002  姓名: 李四   级别: G6   部门: 人事部
   8: ID: 003  姓名: 王五   级别: G9   部门: 行政部
   9:  
  10: 修改员工(003)信息:
  11: ID: 001  姓名: 张三   级别: G7   部门: 开发部
  12: ID: 002  姓名: 李四   级别: G6   部门: 人事部
  13: ID: 003  姓名: 王五   级别: G11  部门: 销售部
  14:  
  15: 删除员工(003)信息:
  16: ID: 001  姓名: 张三   级别: G7   部门: 开发部
  17: ID: 002  姓名: 李四   级别: G6   部门: 人事部

从编程角度来看,我们采用与SOAP服务完全一样的服务调用方式,那么如何反映出服务调用基于Web的本质呢?首先,之前我们能够通过浏览器访问GetAll和Get两个操作可以证明这两个服务操作是基于HTTP-GET的,返回的数据直接以单纯的XML返回,并没有封装成SOAP。为了证明Create、Update和Delete也是完全基于Web的,我们可以通过Fiddler来分析HTTP请求的内容。

如下所示的三段XML片断分别对应着针对上述三个服务操作调用的HTTP请求消息,从这我们可以看出它们就是单纯的针对PUT、POST和DELETE方法的HTTP请求,而传输给服务端的数据直接作为消息的主体,并没有封装成SOAP消息。

代码语言:js
AI代码解释
复制
   1: Create:
   2: PUT http://jinnan-pc:3721/employees/ HTTP/1.1
   3: Content-Type: application/xml; charset=utf-8
   4: Host: jinnan-pc:3721
   5: Content-Length: 187
   6: Expect: 100-continue
   7: Accept-Encoding: gzip, deflate
   8:  
   9: <Employee xmlns="http://www.artech.com/" xmlns:i="http://www.w3.org/2001/XMLSchema-instance"><Department>销售部</Department><Grade>G11</Grade><Id>003</Id><Name>王五</Name></Employee>
  10:  
  11: Update:
  12: POST http://jinnan-pc:3721/employees/ HTTP/1.1
  13: Content-Type: application/xml; charset=utf-8
  14: Host: jinnan-pc:3721
  15: Content-Length: 186
  16: Expect: 100-continue
  17: Accept-Encoding: gzip, deflate
  18:  
  19: <Employee xmlns="http://www.artech.com/" xmlns:i="http://www.w3.org/2001/XMLSchema-instance"><Department>行政部</Department><Grade>G9</Grade><Id>003</Id><Name>王五</Name></Employee>
  20:  
  21: Delete:
  22: DELETE http://jinnan-pc:3721/employees/003 HTTP/1.1
  23: Content-Type: application/xml; charset=utf-8
  24: Host: jinnan-pc:3721
  25: Content-Length: 80
  26: Expect: 100-continue
  27: Accept-Encoding: gzip, deflate
本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2012-02-04 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
一个通过JSONP跨域调用WCF REST服务的例子(以jQuery为例)
JSONP(JSON with Padding)可以看成是JSON的一种“使用模式”,用以解决“跨域访问”的问题,这篇简单的文章给出一个简单的例子用于模拟如何通过jQuery以JSONP的访问调用一个WCF REST服务。[源代码从这里下载] 在这个例子中,我们将定义一个用于返回所有员工信息的服务,下面是用于表示员工信息的Employee的类型和契约接口。契约接口IEmployees的GetAll操作用以返回所有员工列表,我们指定了Uri模板并将回复消息格式设置为JSON。 1: using Syst
蒋金楠
2018/02/07
8240
一个通过JSONP跨域调用WCF REST服务的例子(以jQuery为例)
[WCF REST] 帮助页面与自动消息格式(JSON/XML)选择
可以说WebHttpBinding和WebHttpBehavior是整个Web HTTP编程模型最为核心的两个类型,前者主要解决消息编码问题,而余下的工作基本上落在了终结点行为WebHttpBehavior上。WebHttpBehavior属性HelpEnabled和AutomaticFormatSelectionEnabled是“帮助页面”与“自动消息格式选择”这两个特性的总开关。[“自动消息格式(JSON/XML)选择”源代码从这里下载] 1: public class WebHttpBehavi
蒋金楠
2018/02/07
7440
[WCF REST] 帮助页面与自动消息格式(JSON/XML)选择
[WCF REST] 提高性能的一个有效的手段:条件资源获取(Conditional Retrieval)
条件获取(Conditional Retrieval)旨在解决这样的问题:客户端获取某个资源并对其进行缓存,当再次获取相同资源时,如果资源数据与之前获取的一致,则不再返回真正的资源数据,而是在回复中设置一个“标识”表明获取的资源并未发生改变。[源代码从这里下载] 一、 HTTP对条件获取的支持 HTTP对条件获取提供了原生的支持。具体的实现是这样的:服务端接收到客户端针对某个资源的第一次获取请求时,除了将资源数据作为HTTP回复主体返回之外,还会设置一个叫做ETag的回复报头。这个ETag与资源本身关联并且
蒋金楠
2018/01/16
6890
[WCF REST] 提高性能的一个有效的手段:条件资源获取(Conditional Retrieval)
快速入门系列--WCF--03RESTFUL服务与示例
之前介绍了基于SOAP的Web服务,接下来将介绍基于REST的轻量级的Web服务。 REST(Representational State Transfer)与技术无关,代表一种软件架构风格,可以成
用户1216676
2018/01/24
7880
快速入门系列--WCF--03RESTFUL服务与示例
[WCF REST] Web消息主体风格(Message Body Style)
对于Web HTTP编程模型来说,服务契约中作为操作的方法无须应用OperationContractAttribute特性,只需要根据需要应用WebGetAttribute与WebInvokeAttribute特性即可。前者针对GET HTTP方法,或者则针对其他HTTP方法。WebGetAttribute与WebInvokeAttribute的属性BodyStyle和IsBodyStyleSetExplicitly涉及到“Web消息主体风格”的话题。 1: [AttributeUsage(Attri
蒋金楠
2018/02/07
8730
[WCF REST] Web消息主体风格(Message Body Style)
[WCF REST] 解决资源并发修改的一个有效的手段:条件更新(Conditional Update)
条件获取(Conditional Update)可以避免相同数据的重复传输,进而提高性能。条件更新(Conditional Update)用于解决资源并发操作问题。如果我们预先获取一个资源进行修改或者删除,条件更新检验帮助我们确认资源被获取出来到针对它的修改/删除操作被提交的这段时间内是否被其他人改动过。[源代码从这里下载] 一、HTTP对条件更新的支持 HTTP为条件更新提供了相应的报头,我们按照分析条件获取的方式来分析条件更新在HTTP请求/回复过程中的实现。客户端第一次向服务端发起针对某个资源的请求,
蒋金楠
2018/01/16
8800
Enterprise Library深入解析与灵活应用(8):WCF与Exception Handling AppBlock集成[下]
在上篇中,我详细介绍了如何通过自定义ClientMessageInspector和ErrorHandler,实现WCF与微软企业库中的Exception Handling Application Block(EHAB)之间的集成。这个方案的基本思路就是:当异常从服务端抛出,利用EHAB针对某个配置好的异常处理策略进行处理;然后将处理有的异常通过ServiceExceptionDetail对象进行封装,最后序列化置于Fault消息,最终被返回给客户端;客户端接收到该Fault消息后,提取并创建ServiceE
蒋金楠
2018/01/16
5180
[WCF-Discovery] 实例演示:如何利用服务发现机制实现服务的“动态”调用?
前面两篇(《服务如何能被”发现”》和《客户端如何能够“探测”到可用的服务?》)我们分别介绍了可被发现服务如何被发布,以及客户端如果探测可用的服务。接下来我们通过一个简单的例子来演示如果创建和发布一个可被发现的服务,客户端如何在不知道服务终结点地址的情况下动态探测可用的服务并调用之。该实例的解决方案采用如右图所示的结构,即包含项目Service.Interface(类库)、Client(控制台应用)和Service(控制台应用)分别定义服务契约、服务(包括服务寄宿)和客户端程序。[源代码从这里下载,Dyn
蒋金楠
2018/02/07
6780
[WCF-Discovery] 实例演示:如何利用服务发现机制实现服务的“动态”调用?
WCF的安全审核——记录谁在敲打你的门
WCF所谓的安全审核就是针对认证和授权所做的针对EventLog的日志记录。我们不但可以设置进行审核的事件(认证成功/失败,授权成功或失败),还可以选择记录信息被写入的EventLog类型,即应用程序日志(Application)还是安全日志(Security)。WCF的安全审核是通过ServiceSecurityAuditBehavior服务行为实现的。 一、ServiceSecurityAuditBehavior服务行为 针对WCF安全审核的编程只涉及ServiceSecurityAuditBehavi
蒋金楠
2018/02/07
8330
WCF的安全审核——记录谁在敲打你的门
WCF技术剖析之二十九:换种不同的方式调用WCF服务[提供源代码下载]
我们有两种典型的WCF调用方式:通过SvcUtil.exe(或者添加Web引用)导入发布的服务元数据生成服务代理相关的代码和配置;通过ChannelFactory<TChannel>创建服务代理对象。在这篇文章中,我们采用一种独特的方式进行服务的调用。从本质上讲,我们只要能够创建于服务端相匹配的终结点,就能够实现正常的服务调用。在WCF客户端元数据架构体系中,利用MetadataExchangeClient可以获取服务的元数据,而利用MetadataImporter将获取的元数据导入成ServiceEndp
蒋金楠
2018/01/16
7970
[WCF REST] UriTemplate、UriTemplateTable与WebHttpDispatchOperationSelector
REST服务采用面向资源的架构,而资源通过URI进行标识和定位,所以URI在REST中具有重要的地位。对于WCF来说,服务调用请求的URI映射为某个具体的操作,所以服务端需要解决的是如何根据请求URI选择出对应的操作。如果采用SOAP,操作的选择是根据消息的<Action>报头来实现的,那么REST服务又采用怎样的操作选择机制呢? 目录 一、URI模板 二、UriTemplate 三、UriTemplateTable 四、WebHttpDispatchOper
蒋金楠
2018/02/07
1.1K0
WCF 4.0一个鲜为人知的改变
本篇文章介绍可以算是WCF 4.0基于限流(Throttling)的新特性,是在修订《WCF技术剖析(卷1)》的时候编写演示实例的时候发现的。这个特性没有出现在官方文档上面,至少在MSDN上的相关介绍依然是错误的。 一、流量限制简介 WCF是一个基于多线程的消息监听、接收和处理框架体系,能够同时应付来自相同或者不同客户端的服务调用请求,并提供完善的同步机制确保状态的一致性。一方面,我们期望WCF服务端能够处理尽可能多的并发请求,但是资源的有限性决定了并发量有一个最大值。如果WCF不控制进入消息处理系统的并发
蒋金楠
2018/01/15
8840
[WCF REST] WebServiceHost有何特别之处?
WCF为REST服务的寄宿提供了一个新的ServiceHost,即WebServiceHost。WebServiceHost是ServiceHost的子类,而WebServiceHostFactory是对应的ServiceHostFactory,在基于IIS/WAS寄宿中被使用。由于对REST服务绝大部分功能的支持都是通过WebHttpBehavior这么一个终结点行为实现的,所以WebServiceHost的核心功能就是将该终结点行为应用到寄宿服务的所有终结点。除此之外,WebServiceHost还具有
蒋金楠
2018/02/07
5830
EndpointAddress——不只是一个Uri[下篇]
《上篇》对AddressHeader在服务端和客户端的作用,以及如何通过配置和编成的方式设置AddressHeader进行了详细介绍。现在我们通过一个实例来演示终结点的地址报头如何影响实现终结点选择的消息筛选机制。这个实例通过为服务端终结点指定地址报头实现针对客户端的授权,让经过许可的客户端才能访问这个服务。具体来说,我们将一个代码序列号的GUID作为终结点的地址报头。对于客户端发送的消息,只有具有相应的报头才能访问服务。[三个实例源代码下载地址:实例1、实例2和实例3] 一、无地址报头下服务调用(实例
蒋金楠
2018/02/08
5610
EndpointAddress——不只是一个Uri[下篇]
快速入门系列--WCF--08扩展与新特性
最后一章将进行WCF扩展和新特性的学习,这部分内容有一定深度,有一个基本的了解即可,当需要自定义一个完整的SOA框架时,可以再进行细致的学习和实践。 服务端架构体系的构建主要包含接下来的几个要素:服
用户1216676
2018/01/24
6630
快速入门系列--WCF--08扩展与新特性
[WCF 4.0新特性] 路由服务[实例篇]
在本篇文章中,我们将通过一个具体的实例来演示如何通过路由服务。在这个例子中,我们会创建连个简单的服务HelloServie和GoodbyeService。假设客户端不能直接调用这两个服务,需要使用到路由服务作为两者之间的中介。整个消息路由的场景如下图所示,中间的GreetingService.svc就是代表路由服务,而两个目标服务则通过HelloServie.svc和GoodbyeService.svc表示。路由服务使用的消息筛选器EndpointAddressMessageFilter,即根据包含在消息中
蒋金楠
2018/02/07
6460
[WCF 4.0新特性] 路由服务[实例篇]
通过“四大行为”对WCF的扩展[实例篇]
为了让读者对如何利用相应的行为对WCF进行扩展有个深刻的认识,在这里我提供一个简单的实例演示。本实例模拟的场景是这样的:我们创建一个支持多语言的资源服务,该服务旨在为调用者提供基于某种语言的文本型资源。但是,我们不希望客户端在每次调用服务的时候都显式地制定具体的语言,而是根据客户端服务调用线程表示语言文化的上下文来自动识别所需的语言。[源代码从这里下载] 要让资源服务具有识别语言文化的能够,我们必须将客户端服务调用线程当前的语言文化信息(具体来说就是Thread的两个属性:CurrentUICulture和
蒋金楠
2018/02/07
6170
通过“四大行为”对WCF的扩展[实例篇]
[WCF REST] 通过ASP.NET Output Caching实现声明式缓存
ASP.NET的输出缓存(Output Caching)机制允许我们针对整个Web页面或者页面的某个部分(主要针对用户控件)最终呈现的HTML进行缓存。对于后续针对相同资源的请求,只需要直接将缓存的HTML予以回复而无须按照页面处理生命周期对每次请求进行重复处理。WCF通过操作行为AspNetCacheProfileAttribute利用ASP.NET的输出缓存提供一种针对于某个操作的声明式缓存机制。[源代码从这里下载] 一、AspNetCacheProfileAttribute WCF对ASP.NET缓存
蒋金楠
2018/01/16
8050
WCF技术剖析之二十三:服务实例(Service Instance)生命周期如何控制[下篇]
在[第2篇]中,我们深入剖析了单调(PerCall)模式下WCF对服务实例生命周期的控制,现在我们来讨轮另一种极端的服务实例上下文模式:单例(Single)模式。在单例模式下,WCF通过创建一个唯一的服务实例来处理所有的客户端服务调用请求。这是一个极端的服务实例激活方式,由于服务实例的唯一性,所有客户端每次调用的状态能够被保存下来,但是当前的状态是所有客户端作用于服务实例的结果,而不能反映出具体某个客户端多次调用后的状态。WCF是一个典型的多线程的通信框架,对并发的服务调用请求是最基本的能力和要求,但是服务
蒋金楠
2018/01/16
1.3K0
[WCF-Discovery]如何利用”发现代理”实现可用服务的实时维护?
上面的内容大部分是围绕着Ad-Hoc模式展开介绍的。Managed模式和Ad-Hoc不同之处在于可用服务的终结点通过发现代理来统一管理。客户端在进行可用目标服务探测和解析的时候不再需要发送广播请求,而是直接向发现代理进行探测和解析请求就可以了。[源代码从这里下载] 目录 一、发现代理与Managed发现模式 二、通过继承DiscoveryProxy创建发现代理 三、实例演示:自定义发现代理服务     步骤一、创建自定义发现代理服务     步骤二
蒋金楠
2018/02/07
7400
推荐阅读
相关推荐
一个通过JSONP跨域调用WCF REST服务的例子(以jQuery为例)
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档