Mikel

[转载]WCF – Ysj_BK – 博客园. 为了使读者对基于WCF的编程模型有一个直观的映像，我将带领读者一步一步地创建一个完整的WCF应用。本应用功能虽然简单，但它涵盖了一个完整WCF应用的基本结构。对那些对WCF不是很了解的读者来说，这个例子将带领你正式进入WCF的世界。 在这个例子中，我们将实现一个简单的计算服务（CalculatorService），提供基本的加、减、乘、除的运算。和传统的分布式通信框架一 样，WCF本质上提供一个跨进程、跨机器以致跨网络的服务调用。在本例中，客户端和服务通过运行在相同的同一台机器上不同进程模拟，图1体现了客户端和服务端进程互相调用的关系。   图1 计算服务应用运行环境 WCF的服务不能孤立地存在，需要寄宿于一个运行着的进程中，我们把承载WCF服务的进程称为宿主，为服务指定宿主的过程称为服务寄宿 （Service Hosting）。在我们的计算服务应用中，采用了两种服务寄宿方式：通过自我寄宿（Self-Hosting）的方式创建一个控制台应用作为服务的宿主 （寄宿进程为Hosting.exe）；通过IIS寄宿方式将服务寄宿于IIS中（寄宿进程为IIS的工作进行W3wp.exe）。客户端通过另一个控制 台应用模拟（进程为Client.exe）。接下来，我们就一步一步来构建这样的一个WCF应用。 步骤一：构建整个解决方案 通过VS 2008创建一个空白的解决方案，添加如下四个项目。项目的类型、承载的功能和相互引用关系如下，整个项目在VS下的结构如图2所示。 Contracts：一个类库项目，定义服务契约（Service Contract），引用System.ServiceMode程序集（WCF框架的绝大部分实现和API定义在该程序集中）； Services：一个类库项目，提供对WCF服务的实现。定义在该项目中的所有WCF服务实现了定义在Contracts中相应的服务契约，所以Services具有对Contracts项目的引用； Hosting：一个控制台（Console）应用，实现对定义在Services项目中的服务的寄宿，该项目须要同时引用Contracts和Services两个项目和System.ServiceMode程序集； Client：一个控制台应用模拟服务的客户端，该项目引用System.ServiceMode程序集。   图2 计算服务在VS中的结构 步骤二：创建服务契约 WCF采用基于契约的交互方式实现了服务的自治，以及客户端和服务端之间的松耦合。WCF包含四种类型的契约：服务契约、数据契约、消息契约和错误 契约，这里着重于服务契约。从功能上讲，服务契约抽象了服务提供的所有操作；而站在消息交换的角度来看，服务契约则定义了基于服务调用的消息交换过程中， 请求消息和回复消息的结构，以及采用的消息交换模式。第4章将提供对服务契约的详细介绍。 一般地，我们通过接口的形式定义服务契约。通过下面的代码，将一个接口ICalculator定义成服务契约。WCF广泛采用基于自定义特性（Custom Attribtue）的声明式编程模式，我们通过在接口上应用System.ServiceModel.ServiceContractAttribute特性将一个接口定义成服务契约。在应用ServiceContractAttribute特性的同时，还可以指定服务契约的名称和命名空间。至于契约名称和命名空间的含义和作用，在本人拙著《WCF技术剖析(卷1)》第4章，在这里我们将契约名称和命名空间设置成CalculatorService和http://www.artech.com/)。 通过应用ServiceContractAttribute特性将接口定义成服务契约之后，接口的方法成员并不能自动成为服务的操作。在此方 面，WCF采用的是显式选择（Explicit Opt-in）的策略:我们须要在相应的操作方法上面显式地应用OperationContractAttribute特性。 1: using System.ServiceModel; 2: namespace Artech.WcfServices.Contracts 3: { 4: [ServiceContract(Name="CalculatorService", Namespace="http://www.artech.com/")] 5: public interface ICalculator 6: { 7: [OperationContract] [...]

[转载][WCF REST] 解决资源并发修改的一个有效的手段：条件更新（Conditional Update） – Artech – 博客园. 条件获取（Conditional Update）可 以避免相同数据的重复传输，进而提高性能。条件更新（Conditional Update）用于解决资源并发操作问题。如果我们预先获取一个资源进行修改或者删除，条件更新检验帮助我们确认资源被获取出来到针对它的修改/删除操作 被提交的这段时间内是否被其他人改动过。[源代码从这里下载] 一、HTTP对条件更新的支持 HTTP 为条件更新提供了相应的报头，我们按照分析条件获取的方式来分析条件更新在HTTP请求/回复过程中的实现。客户端第一次向服务端发起针对某个资源的请 求，服务端除了将资源数据作为回复消息主体返回之外，会将与资源关联并且能够可以用于对其进行对等性判断的某个值作为回复的ETag报头，这与条件获取时 一致的。 客户端通过回复获得请求的资源和ETag报头值。对于资源修改操作，客户端直接针对获取的资源进行相应的修改，并将修改后的资 源以HTTP请求的方式向服务端提交；对于资源删除操作，则可以指定被删除资源的唯一标识直接向服务端发送删除的请求。而之前获取的ETag指将会作为请 求消息的If-Match报头。 服务端接收到资源修改/删除请求后先获取到现有的资源的ETag值，并将此值与请求消息的If- Match报头值进行比较。如果两者不一致，则表明试图被修改/删除的资源已经被修改了，在这种情况下会直接回复一个HTTP状态为“412 (Precondition Failed)”的空消息。条件更新同时支持针对PUT、POST和DELETE这三种方法的HTTP请求。 二、WebOperationContext与条件更新 服 务端进行条件更新检测，以及客户端对If-Match请求报头的设置都可以通过当前的WebOperationContext来完成。如下面的代码片断所 示，表示入栈请求上下文的IncomingWebRequestContext类型具有如下四个CheckConditionalUpdate方法重载用 于进行添加更新检测。 1: public class IncomingWebRequestContext 2: { 3: //其他成员 4: public void CheckConditionalUpdate(Guid entityTag); 5: public void CheckConditionalUpdate(int entityTag); 6: public void CheckConditionalUpdate(long entityTag); 7: public [...]

[转载]WCF RESTful服务的Google Protocol Buffers超媒体类型 – 张善友 – 博客园. Protocol Buffers 是在一个很理想的结构化数据的语言中立的序列化格式。你可以考虑一下XML或JSON，但更轻，更小的协议缓冲区。 这种格式的广应用于谷歌不同的系统之间交换数据。 由于其结构化数据的最佳表现，protocol buffers 是一个代表RESTful服务处理的数据很好的选择。要遵循REST的原则， protocol buffers 应作为一个新的超媒体类型的代表。 在当前版本（.NET 4) 的Windows通讯基础（WCF），包含一个新的媒体类型，需要相当数量的努力。 幸运的是，新版本的WCF HTTP堆栈，使媒体类型的WCF编程模型的一等公民，大家可以Glenn Block’s 博客去了解更详细的内容。推荐大家假期可以看下这本书《REST实战》http://book.douban.com/subject/6854551/ 下面我们来介绍如何使用Google Protocol Buffers，只定义一个超媒体类型 ProtoBufferFormatter： 自 定义超媒体类型是通过创建自定义的MediaTypeFormatter，实现OnWritetoStream() 和 OnReadFromStream() 方法进行序列化和反序列化处理。人们经常认为媒体类型只是在服务端使用，但是它用来在客户端控制序列化和反序列化的要求，下图显示了一个HTTP 请求/响应和媒体类型格式化扮演的角色： 这个例子我们使用入门：构建简单的Web API 的代码和WCF Web API Preview 6。使用的媒体类型是application/x-protobuf ，REST服务的核心原则就是服务器和客户端之间的松耦合性，客户端需要知道书签的URI，但不应该知道任何其他的URI的知识，但是客户端必须知道链接关系。 下面的代码是自定义的ProtoBufferFormatter，构造函数里指明了支持的媒体类型 application/x-protobuf。 using System; using System.Collections.Generic; using System.Linq; using System.Web; using System.Net.Http.Formatting; [...]

[转载][翻译]实例：在Android调用WCF服务 – 一味 – 博客园. 原文:http://fszlin.dymetis.com/post/2010/05/10/Comsuming-WCF-Services-With-Android.aspx 在移动设备中，使用XML传输可能会消耗更多的资源，Android没有提供任何组件来直接调用WCF，但是我们可以通过第三方的包（例如：org.apache.http，org.json）来相对简单的调用REST形式的WCF服务。 本文将演示如何创建REST形式的WCF服务和在Android上如何调用服务。 第一步，创建一个包含两个GET操作和一个POST操作的Service Contract。由于是通过JSON对象传输数据，这里需要指定Request和Response的数据格式为JSON。为了支持多个参数，还需要设置 BodyStyle为WrappedRequest。 1 namespace HttpWcfWeb 2 { 3 [ServiceContract(Namespace = "http://services.example.com")] 4 public interface IVehicleService 5 { 6 [OperationContract] 7 [WebGet( 8 UriTemplate = "GetPlates", 9 BodyStyle = WebMessageBodyStyle.WrappedRequest, 10 ResponseFormat = WebMessageFormat.Json, 11 RequestFormat = WebMessageFormat.Json)] 12 IList<string> GetPlates(); 13 14 [OperationContract] 15 [WebGet(UriTemplate = [...]

[转载]来源于WCF的设计模式：可扩展对象模式 – Artech – 博客园. 我一直很喜欢剖析微软一些产品、框架的底层实现。在我看来，这不但让我们可以更加深入地 了解其运作的原理，同时也能提高设计/架构的技能。因为对于这些框架或者产品来说，高质量的设计是它们能够成功的一个最基本的因素。比如说比如 ASP.NET，不但能够支持传统的Web Form应用，MVC同样建立在它基础之上。比如说WCF，从其诞生的那一天开始，真个架构体系就从未改变。这些应用在这些产品和框架上的设计其实是最值 得我们学习的设计案例。比如说，今天我们介绍的“可扩展对象模式（Extensible Object Pattern）”就来源于WCF。[源代码从这里下载] 一、一个简单的“可扩展对象模式”的实现 为 了让这种所谓的“可扩展对象模式”有一个大概的了解，我们先来演示一个简单的例子。现在有一个表示房间的类型Room，它具有几个基本的属性Walls、 Windows和Door分别表示房间的墙、窗户和门。现在我们要来创建一个Room对象，即分别创建组成这个Room对象的各个构成元素。按照“大事化 小”这个基本的设计原则，我们分别创建相应的Builder来分别为Room构建相应的元素。按照“可扩展对象模式”的原理，Room对象就是一个可扩展 对象，而相应的Builder实现了对它的扩展。现在我们将Room这个类型定义在实现了接口 IExtensibleObject<Room>的可扩展对象。 1: public class Room : IExtensibleObject<Room> 2: { 3: public Room() 4: { 5: this.Extensions = new ExtensionCollection<Room>(this); 6: } 7: public Door Door { get; set; } 8: public IList<Wall> Walls { get; set; } [...]