王翔

全国海关信息中心，高级架构师

：

时至今日，企业环境下的开发资源被渐渐吸附到一个基于服务的开发的范畴之中，无论是Web应用、移动和嵌入式应用、传统桌面应用、后台信息服务还是遗留系统都渐渐显露出互通、互联的需要，俯视来看这些应用只不过是另一个层次上的一个个中间件。新的问题再次摆在架构师们的案头——如何在这些应用的高层视图上穿针引线，把自己内部、合作方、公共商业服务、客户应用编织为一个有机的具有连贯计算能力的信息实体？

回答这个问题并不轻松，时间跨度上要考虑企业近1、2十年的信息化建设积累，技术跨度上要照顾到多种应用类型的特点。此外，更需要慎重的是如何保证互联起来的新实体在分布式计算过程中“可靠”，而仅仅“可靠”一项就最少要涉及到如下方面：

l         数据交换过程的安全性

l         计算主体、客体的实体认证

l         可能的大容量数据交换效率

l         跨不同信任域、不同网络限制后的相互连通性

l         多个宏观应用级“原子”操作协调后的事务性

虽然看起来SOA给出了答案——设计和使用服务，但他只是一个概念，必须使用具体的开发技术填充才能够真正为企业信息化建设所用，WCF（Windows Communication Foundation）就是微软对面向服务互联系统开发给出的答案，它提供统一的、可用于建立安全可靠的面向服务的应用开发平台，主要特点如下：

l         统一了微软现有的各种分布式技术

l         基于类型实体属性（Attribute）的开发和扩展，以这种“即时贴”的编码方式区分不同逻辑间的分工

l         与现有的微软组件技术兼容，同时以 WS-*的协议为范本，调用异构平台的服务

l         开发、部署过程以配置为中心

（注：本文所提及的“服务”均指W3C所定义的“服务提供者完成一组工作，为服务使用者交付所需的最终结果。最终结果通常会使使用者的状态发生变化，但也可能使提供者的状态改变，或者双方都产生变化”。）

问题定义：

       下图是WCF的一个典型的应用情形，它抽象了微软以往远程组件的调用过程，将COM+、MSMQ、ASP.Net Web Service、.Net Remoting、相关技术作为调用过程的具体实现层，配合WS-*相关标准协议定义各种面向服务企业开发的技术特性，开发人员仅仅需要将注意力集中在业务逻辑部分，具体实现层的选择只需要根据现场运行环境通过修改配置文件完成。

       从架构上看，WCF自身就是个复杂的层次型系统：

l         最下层它依赖于各种既有组件技术完成远程调用

l         随后，通过抽象出一个统一的消息机制用以屏蔽掉具体通信机制对于信息编码和表示上的不同，同时根据具体数据协议的要求进行主要针对消息头部的操作，例如：在WS-Security协议下通过消息头操作进行消息源、消息主体的认证

l         接着是一个服务运行框架层，可以说这个部分是WCF中调度和协调的部分，他提供了抽象化服务职能（Contract）与具体消息（Message）实体关联后执行所需要的众多企业应特性的支持。包括吞吐量控制、服务异常处理、事务控制等等。概念上可以类比的参考COM+中DTC、TCP/IP协议栈中的TCP层、J2EE的EJB容器，可以说正因为有了这一层的保证才使得WCF可以被作为一个系统层面的面向企业级应用开发的框架。

l         之上是对整个面向服务系统各个方面定义的抽象层，通过基于XSD（W3C XML Schema）描述相关行为的执行参数，这样整个WCF平台被建立在一个平台无关、开发技术无关的XML世界中，它确保WCF可以在各个服务层面上互联起不同的应用。

图：WCF的总体逻辑架构

：

考虑到不同组件协议对于交互过程数据表示的不同，WCF中抽象了很具意义的消息（Message）对象，整个WCF是一个基于消息的API系统，而抽象消息对象的出现也为上层调度和业务逻辑部分提供了必要支持。首先，它是对调用过程载体和传输机制的抽象，例如：MSMQ调用中的报文、Web Service调用中的XML over HTTP请求；其次它也适应了对通信协议的抽象，将文本数据、二进制数据和用于大容量持续交互的特殊编码数据从业务处理的角度剥离——业务逻辑就关心对象实体需要的内容条目即可。消息的处置采用通道（Channel）方式，也就是通过一个栈(Channel Stack)的方式逐层对消息数据、消息头进行处理，为了适应不同协议、不同通信机制，Channel被分为协议通道（transport channels） 和协议通道（protocol channels）。前者是面向网络的，主要负责从网络读写外部数据，同时考虑到不同数据编码方式的不同，传输通道还负责转换相关数据编码，事实上WCF项目开发中该类channel一般采用微软提供的现成类型。后者是面向协议相关数据加工的，由于一般而言WS-*相关协议的操作都是通过在消息头部进行扩展，所以protocol channel一般也都是面向消息头操作，例如常用的WS-Security协议。

       一般而言，根据需要您可以选择各个WCF环境内置的一些通道：

l         采用增加了WS-Reliable协议的消息通道，因为它主要用于保障消息的可靠交付，由于WCF设计上即是面向一个完全分布的网络环境，因此尤其对于基于HTPP的调用更是需要考虑到可能的消息交付错误。因此，这个通道借助被业内主要厂商普遍接受的WS-Reliable标准解决了与业务逻辑无关，但是技术上又非常具有挑战性的开发工作，他可以保证4种可靠交付模式：At Least Once、At Most Once、Exactly Once、A Ordering Group（确保一组消息按照既定次序逐个有效交付），前三种模式的示意如下：

l         考虑到防火墙、IPSEC等网络限制，建议尽量采用HTTP Channel进行消息内容的HTTP编码，不过如果您的应用是同一信任域（或者具有直接信任关系的信任域）之间的服务调用，TCP Channel将使您在传输效率、网络流量方面获益。

l         在需要事务性保障的情况下应选择Transaction Flow Channel；如果消息的调用是进程内调用，可以采用类似Unix系统命名管道（Named Pipe）机制的Named Pipe Channel。

l         如果调用上涉及与VMS、非TCP/IP协议平台应用、高安全性敏感隔离应用（例如：采用网闸隔离）等这类特殊应用通信，那么MSMQ Channel将非常必要。

：

       经过上世纪九十年代的发展，微软平台的相关技术基本趋于COM化，相关的周边厂商也陆续提供了很多Socket、RPC的COM封装，对于VMS等早期操作系统平台也可以寻找到很多基于报文的COM中间件。因此，WCF所面对的遗留系统绝大多数可以通过与COM世界的互操作完成，对于一些事务性控制、异步调用、对象实例池化、调用队列等高级支持也很大程度上可以借助COM+现有服务通过配置实现。

不过这里还存在一个比较麻烦的问题，就是与遗留系统的认证和组件访问授权问题，而且如果上层操作中要求调用过程Enlist到一个事务过程，那么还需要COM+部分也相应的开始一个吻合的事务，同时启动一个匹配的调用上下文（Transaction Context）。WCF上常用的解决办法就是把对应的COM+包装为一个Web Service，配合必要的WS-*协议可以定义同样交易隔离度的事务说明、认证和授权控制，然后根据需要可以选择把相应的Web Service借助COM+宿主进程（dllhost.exe）或者IIS宿主进程暴露给后续WCF应用处理。

：

       虽然WCF自身运行于.Net Framework 3.0平台，但是借助XML技术和相关标准化WS-*完全可以与其他非.Net Windows平台、非Windows系统服务平台、非.Net语言服务平台集成，这里WCF的Interoperability（互操作）能力起到关键作用，其中又以SOAP调用为基础。WCF借助SOAP（而非以往的二进制PRC调用）在异构平台集成中获得如下特性：

l         脱离调用与具体开发语言的紧密结合

l         因为SOAP中XML的文本特性，确保调用不需和特定传输协议紧密结合

l         脱离与具体分布式组件系统的依赖

l         完全标准化

可以说WCF在选择SOAP的同时也具有了异构平台间互操作的一致的数据结构体系，而WS-*相关协议则是在各类调用特性中增强了各种功能特性，简而言之就是标准化的各个标准确保了WCF的互操作能力。

WCF 借助WS-* 实现了可交互的 Web 服务开发平台，并且将不同互操作端点间的安全性、可靠性和事务性借助相关协议完成：

l         SOAP之上WCF集成了WS-Addressing和MTO，这一方面支持通过对 SOAP头扩展达到为SOAP 消息寻址的目的，确保WCF的SOAP调用在寻址信息时无需依赖底层传输协议，另一方面也实现了对于大容量XML数据在串行化为网络二进制流的过程中优化XML数据包的作用，后者尤其利于SOAP消息中包括附件的情况。

l         对于企业应用而言经常需要扩展标准协议，以实现行业内部应用间、与合作伙伴应用间的定制交互，其中通过具有语义、结构特征的元数据进行扩展是一个很有效的途径。WCF为了实现异构平台间的元数据支持，提供了WSDL、WS-MetadataExchange、WS-Policy 和 WS-SecurityPolicy的开发API，尤其是WS-SecurityPolicty更提供了WSDL不足以表达的有关安全性方面的很多动态特性，然后通过WS-MetadataExchange让客户程序可以获得元数据，包括WSDL描述和相关的安全策略等。

l         安全性方面WCF 通过实现 WS-Security、WS-Trust和WS-SecureConversation，支持通信源与目的点之间的SSL通道层加密，此外还提供异构平台间调用（一般需要公钥证书体系支持）的数据完整性、主体身份验证、SOAP特定数据项加密等安全性要求的支持。

l         WCF通过WS-Coordination（通常用于长事务）和WS-AtomicTransaction（通常用于短事务）两个协议的支持，确保可以在SOAP多步调用过程中实现事务性。不仅如此，通过WS-ReliableMessaging起到类似TCP层相同的作用——确保消息“依次”“可靠”到达。

  【IT168 技术文档】

点对点通信的支持

     虽然现今企业应用中普遍采用的是“客户——服务器”方式的集中式计算体系，但是随着Web 2.0相关应用的推出，P2P类型的应用也将会且正在逐步提上开发日程，例如企业内部的及时消息系统、视频会议和视频培训服务等。WCF为Windows平台（Windows XP Sp2 +）这类应用的开发提供了一个较为完整的支持。WCF中有一个可以配置加载的Peer Channel，通过Windows平台的点对点网络平台WCF提供了可以创建、发送、接受点间交互的一整套API。作为一个多层逻辑抽象的系统，WCF仅需要消息协议绑定和消息地址部分稍作特殊定义，而对于更上层的Contract的业务逻辑部分而言没有影响，也就是说WCF将应用逻辑和应用交互模式隔离开。配置上，消息地址需要选择netP2P类型的消息格式定义，并选择它与具体的通信协议的绑定对象为NetPeerTcpBinding.。此外，由于P2P应用从架构模式看属于一个跨进程的“出版——预订”模式，因此为了确保交互源点与目标点之间的交互，还需要为他们在最上层Contract部分定义回调(callback)的内容。

       同样对于敏感的点对点应用情形一样需要实施安全保护，WCF可以通过配置为Peer Channel提供一个加密密钥（考虑到点对点特性，因此通常考虑对称密钥），用于加密传输过程加密，甚至用于访问对于点对点实体命名进行解析的服务。

服务环境的运行管理：

       在提供完整开发支持之外WCF还提供了一整套服务环境的管理工具，毕竟面向服务的开发与以往桌面应用、同构环境下“客户——服务器”模式应用的开发环境相比更为复杂，尤其在跨信任域之后相关的网络、证书体系、服务安全控制等限制无处不需要大量的配置。可以这么说：虽然WCF的API系统提供了开发层面的各种支持，但是在生产环境的部署上WCF的工具支持更决定了其是否可以被广大企业用户接纳（包括接纳的程度）。WCF里面也包括各种WMI对象集合，借助这个工具可以使用MOM或其他自定义脚本完成应用运行监控的自动化，毕竟从应用生命期角度看，普遍情况下在WCF大量开发库的支持下整个开发过程也就占其一小部分，更多的时间还是运行维护阶段，因此WMI的加入确保即便在.Net 3.0平台上企业的信息系统管理人员一样可以通过他们所熟悉的脚本语言（VBScript、Jscript等）完成运行系统的管理工作，所需的仅仅就是“按需”找到对应的WMI Classes。

图：WCF的运行管理部署模式