WCF 第二章 契约 系列文章

上一个系列向大家普及了什么是WCF？ WCF 由什么组成？ WCF 主要通过什么方式寄宿等等。给大家提纲挈领般的提出了一个总的概括，就相当于这个社会主体已经存在，我们下一步将要描述社会具体由什么组成的，各个组成部分都发挥着什么样的作用，社会中最核心、最基础的内容是什么？ 不用我回答，我们也能亲身体验到，社会存在的核心就是诚信，进一步讲构筑诚信的基础是什么呢？ 契约，既构筑了真实世界的基础，也构筑了WCF的基础。我们在这一章会详细讨论这个基础与核心。

[第1篇] 基础

在原子和金钱世界中，契约是两个或多个组织以一个已知的价格提供商品和服务的合同。在比特和服务的世界中，契约有类似的功能:它是两个或多个组织之间确定消息交换和消息条款及条件的合同。

契约是由服务终结点发送或接收的消息的描述。每一个终结点都由ABCs定义:一个消息发送到的网络上的地址，一个描述消息如何发送的绑定，一个描述消息格式的契约。

[第2篇] 服务契约

服务契约描述了由服务终结点实现的接口操作。服务契约引用消息格式并描述它们是怎么被交换的。消息格式更进一步被数据契约和消息契约描述。这一部分主要涉及由服务契约实现的消息交换。

[第3篇] 同步请求回复操作

对服务操作来说，同步请求回复消息交换是最普通的模式。这个模式就像任何人在面向过程或者面向对象语言中编程的那样。请求回复模式是本地过程调用的原型，对远程过程调用也很普通。图片2.3显示了一个请求回复交互，一个在客户端运行的代理发送请求给一个服务，服务端同步返回消息给客户端。

[第4篇] 异步访问服务操作

好的设计会降低用户必须等待一个任务结束然后初始化另一个任务之前的情况。例如，当一个e-mail客户端正在下载新邮件，你仍然可以读或者删除已经下载下来的邮件。或者当一个浏览器正在下载一个网页上引用的图片时，你仍然可以拖动网页或者跳转到任何地方。在客户端程序中的多任务形式是通过异步设计模式来完成的。

[第5篇] 单向操作

当一个客户端需要向一个服务端发送消息但是不接受返回消息时，但不消息交换模式很有用。使用这个模式，客户端只需要消息成功传递的确认；它不需要服务端返回一个精确的消息。有时单步模式被错误的称作"发后不理"。在实际应用中，它是"发送和理解"因为调用者接收到一个消息成功提交到通信信道的确认。

[第6篇] 双向操作

请求-回复通信是客户端与服务端最普遍的消息交换模式。通信在客户端被初始化，客户端发送一个请求消息给服务端，然后服务端发送一个返回消息给客户端。如果返回消息很快，那么通信过程可以是同步的，所以客户端应用程序阻塞等待反馈。如果请求和回复之间会有延时，请求-回复模式可以在客户端使用标准.NET技术实现异步调用。在那种情况下，WCF会在发送请求给服务端后立即把控制返回给客户端应用程序。当服务接收到反馈以后，一个.NET回调方法被调用来完成WCF回复。

[第7篇] 两个单工契约VS一个双工契约

你可以通过两个不同消息交换模式来解决双向通信问题。你可以使用两个单向契约，或者你可以使用一个双工契约。对于两个单向契约来说，客户端和服务端都是独立的WCF宿主。它们分别暴露终结点来可以让另一个向自己发消息。因为它们是全面的服务，它们可以暴露多个终结点，使用多个绑定和独立的定义契约的版本。使用一个双工契约，客户端不用明确的变成一个WCF服务而且不用很复杂(很灵活)来选择绑定或者暴露其他终结点。更进一步，定义客户端终结点的地址，绑定和契约是由信道工厂在双工通信被客户端初始化时完成的。

[第8篇] 实现一个双向契约的服务端部分

一个双向契约包含服务终结点和客户端终结点的接口实现。在契约类型中，服务端契约在客户端实现。

[第9篇] 实现一个双向契约的客户端部分

为了参与到一个双工消息交换模式中，客户端必须实现WCF的ABCs-必须在客户端定义服务要把消息发送到的地址，指导服务端如何把消息发送给客户端的绑定，定义消息内容和格式的契约。幸运的是，当你生成一个客户端代理而且在运行时使用信道结构时，WCF很大程度上考虑到了这些。

[第10篇] 在一个服务中实现多个契约和终结点

一个服务作为一系列终结点被定义的。每个终结点都有一个地址，绑定和契约。契约就是暴露终结点能力的。地址就是这些应用或服务从网络的哪个地址可找到，契约是关于如何访问他们的。

[第11篇] WSDL中的操作名字、类型、操作和命名空间

WCF 根据服务端源代码中定义的内部类名称和属性来生成外部暴露服务实现。这些实现通过服务中的MEX终结点暴露出来并在设计阶段时被客户端以WSDL形式使用。接下来在客户端，WSDL会被用来写一些代码来建立可以与服务端通信的适当的消息格式。所以你选择的类，方法和参数的名字与服务范围潜在相差很远。

[第12篇] 数据契约

在一个服务内部，功能性的应用由代码实现的。在服务外部， 功能性服务在WSDL中定义。在一个WCF服务中，应用程序数据在简单和复杂类型表示；而在服务外部，应用程序数据由XML元数据定义表示。WCF数据契约提供了对代码定义的.NET CLR类型与W3C组织定义用来在服务外部通信的XML元数据定义之间的映射。

[第13篇] 定义类的层次结构

复杂类型一般在代码中以类的形式实现。复杂类更进一步通过增加特殊结构的继承关系来定义。这种方式，一个通用类型比如”price” 可以派生出为一个更加特殊的类型如”stock price” 或者 “house price”.WCF支持通过在WSDL中合适的表示的类的继承关系，在类结构和XML之间序列化和反序列化它们同时从每个类中取出属性并加入到一个集合中。

[第14篇] 在WSDL中使用KnownType暴露额外类型

如果数据类型满足任何先前描述的条件，那么它们会在WSDL中暴露出来。有一些额外的可能，当然，你也可能想强制一个类型包含在WSDL契约中。

[第15篇] 数据契约版本

变化是不可避免的。企业改变，技术改变，法律改变，软件契约也会改变。在面对软件的变更时，一个坚实的版本控制是必须的。我们必须为不可避免的变化做好提前准备同时对已经存在的客户端进行向后兼容处理。

[第16篇] 数据契约等效

如果你在使用WCF暴露服务而且使用svcutil.exe来为创建访问服务代码，一般情况下你不需要关心在客户端和服务端间传输的消息的线上表示。数据契约知道WCF把一个.NET类型序列化成一个XML信息集和讲一个XML信息集反序列化成一个.NET类型。XML信息集可能在线上以文件或者二进制形式编码，这些取决于通信过程中所使用的绑定，但是再次，.NET代码不会意识到编码的存在。这种方式就好比你在代码中使用.NET类型但是一个基于标准的XML信息集的编码表示在线上具体传输。

[第17篇] 消息契约

消息契约描述了发送给一个服务以及从一个服务接收的SOAP消息的结构，并且允许你检测和控制SOAP消息头和消息体中大部分细节。而且数据契约能够让使用XML元数据定义(XSD)标准的系统之间互通，消息契约能够让任何通过SOAP通信的系统互通。

[第18篇] 总结

这一章覆盖了非常多的契约背景，它们是互通性的基础。契约精确地描述了一个服务所能理解的消息。

WCF高度利用SOAP于契约定义中。特别的，它使用WSDL来描述服务终结点，使用XSD来描述数据。定义在WSDL中的服务操作用来在运行时把收到的请求转发给正确的.NET类。类似的，通过XSD契约定义的XML文件在运行时被反序列化成.NET类型而且发送给服务操作。合二为一，WSDL和XSD定义提供了对服务实现中的.NET类型一种基于标准的实现。