摘要： 构建HelloWCF应用的第一步是创建服务契约。契约式是表示消息应用外形的主要方式。对于外形，是指服务暴露的操作，使用的消息schema和每个操作实现的消息交换模式（MEP）。总之，契约定义了我们消息应用生成和使用的东西。大多数契约是带有WCF API定义的属性标记的类型定义。 阅读全文

摘要： 消息拓扑描述的是在一个或多个发送者和接受者之间消息如何发送的。消息拓扑可以描述简单的应用-应用的连接关系，但是它同样可以描述复杂的应用-企业的连接。概括地说，这些可能存在的拓扑结构比面向组件的应用系统能够涉及到的情况会更加多、更加复杂。 阅读全文

摘要： 我们描述消息交换最常用的细节粒度就是消息交换模式(MEP)。根据W3C草案(http://www.w3.org/2002/ws/cg/2/07/meps.html)，一个MEP是“一个描述在消息参与者之间交换的消息的模板。”一个MEP被限制在一个发送者和接收者之间的逻辑连接上，整个行业也已经接收了这个事实。因为MEPS是个有点抽象的概念，近距离看一些现实世界的例子对于我们弄清MEPs这个概念有帮助。让我们来看看下面我和朋友关于足球票通话的例子： 阅读全文

摘要： “为什么我们需要面向服务？”回答很简单：可伸缩性、维护性、互操作性和灵活性。过去，分布式组件技术像COM紧紧地把所有的组件绑定到一起。最低限度上，这些分布式技术必须分享公共类型系统，并且常常是一个运行时。有了这些依赖，升级和软件升级变得复杂、费时和费力的。面向服务的应用系统，恰恰相反，不需要相同类型的依赖，因此显示出更加适合企业精算需求的行为。 阅读全文

摘要： 显然地，面向服务系统开发首先应该是创建契约。为了例子简单，一个订单包含一个产品ID（product ID）、数量（quantity）和状态消息（status message）。有了这三个字段，一个订单可以使用下面的伪schema代码表示： 阅读全文

摘要： 面向服务里，服务可以与每个其它的服务通过消息交互。换句话说，服务可以穿越边界发送消息给其它服务。服务可以发送和接收消息，并且能被发送和接受的消息形状定义了服务的边界。这些边界被良好地定义，清晰地表示，并且是唯一的服务功能访问点。更实际点，如果服务1要和服务2交互，服务1必须发送消息给服务2.相反，一个面向对象或者面向组件的世界里，要求服务1应该创建一个服务2的实例（或者一个服务2的代理）。这个例子里，这些服务间的边界变得模糊了，因为服务1为了所有的目的，被服务2所控制。 阅读全文

摘要： 现在我们已经看过了与消息交互的实体，详细剖析了消息结构，然后看了一下WCF提供了几个消息编码器，现在我们来看一下如何在详细发送的时候表示我们要发送的目的地。毕竟，除非能发送给接受者，否则消息等于是毫无用处。和邮政服务需要一个良好格式的地址结构一样，面向服务的消息同样也需要一个定义良好的地址结构。这节里，我们将会建立自己的地址结构（Scheme），看它可以不可以广泛适用于所有的消息应用系统，然后把它关联到那个和WCF消息一起使用的地址结构上。 阅读全文

摘要： 随着时间的流逝，也许我们会条件反射式地认为XML（SOAP）是一个结构文本。毕竟，文本是人可读的，每个计算机系统也可以处理文本。基于文本的XML的普遍共性与我们的与其它系统交互的想法产生了共鸣。可以容易的解释的基于文本的XML本质上会体积变大。可以理解使用XML会带来性能损失。就像要花费点精力把信装到信封里一样，它需要一些处理时间与XML交互。某些情况下，基于文本的XML数据大小限制了它的应用，特别是当我们要通过网络发送一个XML消息的时候。 阅读全文

摘要： 本章主要介绍元数据通用查询类 MetadataHelper。 阅读全文

摘要： 本章主要介绍WCF服务契约的重载与继承，以及设计和分离服务契约的一般原则。 阅读全文

摘要： WCF服务类不能凭空存在。每个 WCF 服务都必须托管（Hosting） 在 Windows 进程中，该进程被称为宿主进程（Host Process）。单个宿主进程可以托管多个服务，而相同的服务类型也能够托管在多个宿主进程中。WCF 没有要求宿主进程是否同时又是客户端进程。显然，一个独立的进程有利于错误与安全的隔离。谁提供进程或是提供何种类型的进 程并不重要。宿主可以由 IIS 提 供，也 可以由 Windows Vista 的 Windows 激活服务（Windows Activation Service，WAS）提供，或者开发者直接将它作为应用程序的一部分。 阅读全文

摘要： 服务有两种方案可以发布自己的元数据。一种是基于 HTTP-GET 协议提供元数据，另一种是使用专门的终结点的方式。 WCF能够为服务自动提供基于 HTTP-GET 的元数据，但需要显式地添加服务行为（Behavior）以支持这一功能。行为属于服务的本地特性，例如是否需要基于 HTTP-GET 交换元数据，就是一种服务行为。 阅读全文

摘要： ServiceContract 特性可以将一个 CLR 接口（或者通过推断获得的接口）映射为与技术无关的服务契约。ServiceContract 特性公开了 CLR 接口（或者类）作为 WCF 契约。WCF 契约与类型的访问限定无关，因为类型的访问限定属于 CLR 的概念。即使将 ServiceContract 特性应用在内部（Internal）接口上，该接口同样会公开为公有服务契约，以便于跨越服务边界实现服务的调用。如果接口没有标记 ServiceContract 特性，WCF 客户端则无法访问它（即使接口是公有的）。这一特点遵循了面向服务的一个原则，即明确的服务边界。为满足这一原则，所有契约必须明确要求：只有接口（或者类）可以被标记为 ServiceContract 特性，从而被定义为WCF 服务，其他类型都不允许。即使应用了ServiceContract特性，类型的所有成员也不一定就是契约中的一部分。我们必须使用OperationContractAttribute特性显式地标明哪些方法需要暴露为WCF契约中的一部分。 阅读全文

摘要： WCF 提供了对可靠性、事务性、并发管理、安全性以及实例激活等技术的有力支持，它们均依赖于基于拦截机制的WCF体系架构（WCF Architecture）。通过代理与客户端的交互意味着WCF总是处于服务与客户端之间，拦截所有的调用，执行调用前和调用后的处理。当代理将调用栈帧（Stack Frame）序列化到消息中，并将消息通过通道链向下传递时，WCF就开始执行拦截。通道相当于一个拦截器，目的在于执行一个特定的任务。每个客户端通道都会执行消息的调用前处理。链的组成与结构主要依赖于绑定。例如，一个通道对消息编码（二进制格式、文本格式或者 MTOM），另一个通道传递安全的调用上下文；还有一个通道传播客户端的事务，一个通道管理可靠会话，另一个通道对消息正文（Message Body）加密（如果进行了配置），诸如此类。客户端的最后一个通道是传输通道，根据配置的传输方式发送消息给宿主。 阅读全文

摘要： WCF（Windows Communication Foundation）是基于Windows平台下开发和部署服务的软件开发包。它使得开发者能够建立一个跨平台的安全、可信赖、事务性的解决方案，且能与已有系统兼容协作。WCF是微软分布式应用程序开发的集大成者，它整合了.Net平台下所有的和分布式系统有关的技术，例如.Net Remoting、ASMX、WSE和MSMQ。以通信(Communiation)范围而论，它可以跨进程、跨机器、跨子网、企业网乃至于 Internet；以宿主程序而论，可以以ASP.NET，EXE，WPF，Windows Forms，NT Service，COM+作为宿主(Host)。WCF可以支持的协议包括TCP，HTTP，跨进程以及自定义，安全模式则包括SAML， Kerberos，X509，用户/密码，自定义等多种标准与模式。也就是说，在WCF框架下，开发基于SOA的分布式系统变得容易了，微软将所有与此相关的技术要素都包含在内，掌握了WCF，就相当于掌握了叩开SOA大门的钥匙。 阅读全文