老的Windows通讯开发平台有：WebService和.net Remoting等。
本章节将进行元数据和异常处理的介绍，这部分内容概念型比较强，可以快速浏览一下就好。 客户端和服务器借助于终结点进行通信，服务的提供者通过一个或者多个终结点将服务发布出来，服务的消费者则通过创建与之匹
文本参考自:http://www.cnblogs.com/wangweimutou/p/4365260.html 简介:WCF作为分布式开发的基础框架,在定义服务以及消费服务的客户端时可以通过配置文件的方式,来进行设置,这充分的体现了WCF的伸缩性和自定义性。当然WCF也提供硬编程的方式，通过在代码中直接设置相关对象的属性来完成服务端与客户端的配置，然而这种方式并不利于后期程序的更改和扩展。 一、WCF配置文件结构如下图所示,包含三个部分,services(服务)、bindings(绑定)、behavior
在基于TCP/IP协议簇的对等网络通信下，相互通信的应用程序运行各自的进程中，出于应用层的进程将数据局封装成数据报，并通过传输层的TCP或者UDP进行网络通信。而TCP和UPD则通过一个16bit的端口来识别不同的应用程序。
服务是一个构造，它公开一个或多个终结点，其中每个终结点都公开一个或多个服务操作。
转眼微软的WCF已走过十个年头，它是微软通信框架的集大成者，将之前微软所有的通信框架进行了整合，提供了统一的应用方式。记得从自己最开始做MFC时，就使用过Named Pipe命名管道，之后做Winform时，使用过Remoting，再之后做B/S架构时，就会经常使用.NET平台下的Web Service，直到使用上WCF。看上去有了一些WCF的使用经验，实则不然，比如对安全、分布式事务、可靠会话等主题仍然接触甚少，因而决定重新回顾学习一下相关知识，尤其是对WCF框架的理解（已于2015年开源，可下载源码，h
对于WCF服务端元数据架构体系来说，通过MetadataExporter将服务的终结点导出成MetadataSet（参考《如何导出WCF服务的元数据》），仅仅是完成了一半的工作。被成功导出的以MetadataSet对象表示的元数据需要最终作为可被访问的网络资源发布出来，才能被服务消费者获取，进而有效地帮助他们进行服务调用。元数据的发布最终是通过ServiceMetadataBehavior这样一个服务行为实现的，我们先来认识一下ServiceMetadataBehavior。 一、 元数据发布的实现者：S
第1章 异常处理 （Exception Handling） 1.1. WCF基本异常处理模式 1.1.1. 当异常从服务端抛出（S101） 1.1.2. 异常细节的传播（S102） 1.1.3. 自定义异常信息 1.2. 错误消息与FaultException异常 1.2.1. 从SOAP Fault说起 1.2.2. 唯一可被传播的异常：FaultException 1.2.3. FaultException异常和错误消息之间的转换 1.3. WCF异常处理体系剖析 1.3.1. FaultFormatt
元数据实际上是服务终结点的描述，终结点由地址（Address）、绑定（Binding）和契约（Contract）经典的ABC三要素组成。认真阅读过《WCF技术剖析（卷1）》的读者相对会对这三要素的本质有一个深刻的认识：地址决定了服务的位置并实现相应的寻址机制；契约描述了消息交换模式（Message Exchange Pattern： MEP）以及消息的结构（Schema）；绑定则通过创建信道栈实现对消息的编码、传输和基于某些特殊的功能（比如实现事务、可靠传输以及基于消息的安全）对消息作出的处理。 服务的消
开篇，简单知识介绍： 最近开始用WCF，一直仅限于初级阶段，整理了下思路，深入研究一下。 开始时，在看一个叫Artech写的系列文章，结果。。。 1、长篇大作，有絮叨之嫌 2、“专业术语”横行，这还可以接受，也许这就是面向高端人员看的 3、广告太多，卖书就卖书，没必要博文的每一段都加个链接 4、夹生英文词太多，而且还是很多特别简单的，比如blog、link之类的，看着别扭，额。。。个人喜好，不过多做评价。 没办法，只能愤而关之，另寻他途。于是乎，找到了这个，参考着看，这里有一部分是复制，一部分是自己的想法。
在年前写一个几篇关于分布式事务的文章，实际上这些都是为了系统介绍WCF事务处理体系而提供的相关的背景和基础知识。今天发最后一篇，介绍分布式事务采用的两种协议，即OleTx和WS-AT，内容比较枯燥，但对于后续对WCF事务处理框架进行深入剖析的系列文章来说，确是不可以缺少的。总的来说，基于WCF的分布式事务采用的是两阶段提交（2PC：Two Phase Commit）协议。具体来说，我们可以选择如下两种事务处理协议实现WCF的分布式式事务，它们按照各自的方式提供了对两阶段提交的实现。 OleTx：OleTx
WCF（Windows Communication Foundation）是由微软开发的一系列支持数据通信的应用程序框架，可以翻译为Windows通信开发平台
很多WCF的初学者是从之前的Web服务上转移过来的，他们非常怀念.asmx Web服务无配置的服务寄宿方式。你只需要在定义Web服务的时候再表示服务操作的方法上应用WebMethodAttribute特性就可以了，完全可以不需要手工进行相应的配置，因为Web服务运行时会自动为你添加默认的配置。但是对于WCF来说，在进行服务寄宿的时候，你必须以编程或者配置的方式为服务添加至少一个终结点，而终结点需要具备基本的ABC三要素。 对于最新版本的WCF编程人员来说，你也可以采用无配置的服务寄宿了，这主要得益于WCF提
在面向服务的应用系统中，最重要的概念就是消息，消息的传输是一个非常重要的问题。而在大多数情况下，消息要经历多个网络节点，这里会涉及到消息路由问题。WS规范很早就制定了对于消息路由问题的解决办法，这里最早的就是WS-Routing 。当然后来逐渐为更完善的规范WS-Addressing取代。 支持对于消息路由，WCF4.0之前的框架没有提供支持，在WCF4.0里又重新加入对于消息路由机制的支持。当然这里我们学习消息路由，首先还是来了解一下与消息路由相关的一些规范，下面我们就来依次看一下WS-Routing和W
客户端调用WCF服务的方式不外乎有两种：其一、通过代码生成工具（比如SvcUtil.exe）导入服务的元数据生成服务代理相关的类型；其二、通过ChannelFactory<TChannel>创建服务代理对象。对于前者，生成的服务代理是一个继承自ClientBase<TChannel>的类型。对于这样一个服务代理对象，其内部本质上还是借助于ChannelFactory<TChannel>创建真正用于进行服务调用的代理对象。对于WCF客户端应用编程接口来说，ChannelFactory<TChannel>是一个
今天介绍WCF 4.0的另外两个新特性：标准终结点（Standard Endpoint）和无(.SVC)文件服务激活（File-Less Activation）。前者实现了针对典型通信场景对终结点的定制，后者让你在进行IIS/WAS的服务寄宿中无须定义.svc文件。 一、标准终结点 我们知道，绑定的本质就是一系列相关绑定元素的有序集合，而系统绑定就是基于若干典型的通信场景对相关绑定元素的整合。WCF通过系统绑定对绑定元素进行了定制，那么能否在终结点级别对组成该终结点的ABC（地址、绑定和契约）也进行相应的定
近半年以来，一直忙于我的第一本WCF专著《WCF技术剖析（卷1）》的写作，一直无暇管理自己的Blog。在《WCF技术剖析（卷1）》写作期间，对WCF又有了新的感悟，为此以书名开始本人的第三个WCF系列。本系列的目的在于对《WCF技术剖析》的补充，会对书中的一些内容进行展开讲述，同时会囊括很多由于篇幅的原因忍痛割弃的内容。 [第1篇] 通过一个ASP.NET程序模拟WCF基础架构 本系列的第一篇，我将会对WCF的基本架构作一个大致的讲解。不过，一改传统对WCF的工作流程进行平铺直叙，我将另辟蹊径，借助于我
在WCF中，每个终结点都包含两个不同的地址——逻辑地址和物理地址。逻辑地址就是终结点Address属性表示的地址。至于物理地址，对于消息发送放来讲，就是消息被真正发送的目的地址；而对于消息的接收放来讲，就是监听器真正监听的地址。 一、服务端的物理地址 在默认的情况下，终结点的逻辑地址和物理地址是同一个URI。换句话说，终结的逻辑地址是必须的，如何物理地址没有指定的，默认使用逻辑地址作为物理地址。对于消息接收方的终结点来讲，物理地址就是监听地址，通过ServiceEndpoint的ListenUri表示：
服务通过 ServiceHost 进行寄宿。可以添加终结以暴露可被调用寻址和调用的资源。
本文参考自:http://www.cnblogs.com/wangweimutou/p/4422883.html,纯属读书笔记,加深记忆 一、服务协定简介: 1、WCF所有的服务协定层里面的服务接口,
经过WCF基础的ABC学习，已经可以构建简单的WCF的服务，使用不同的服务地址和绑定类型，根据业务提供所需的服务契约。但不禁想问，服务所使用的消息报文是什么样的形式么？蕴含什么样内容呢？WCF服务是否
作为WCF中一个核心概念，终结点在不同的语境中实际上指代不同的对象。站在服务描述的角度，我们所说的终结点实际上是指ServiceEndpoint对象。如果站在WCF服务端运行时框架来说，终结点实际上指代的是终结点分发器（EndpointDispatcher）。而ServiceEndpoint与EndpointDispatcher是一一匹配的，并且前者是创建后者的基础。而终结点分发器具有自己的运行，即分发运行时（DispatchRuntime）。 目录 一、终结点分发器（EndpointDisp
在设计和实现服务协定后，即可配置服务。在其中可以定义和自定义如何向客户端公开服务，包括指定可以找到服务的地址、服务用于发送和接收消息的传输和消息编码，以及服务需要的安全类型。
线上正式环境调用WCF服务正常，但是每次使用本地测试环境调用WCF服务时长就是出现：套接字连接已中止。这可能是由于处理消息时出错或远程主机超过接收超时或者潜在的网络资源问题导致的。本地套接字超时是“00:05:30” 这个问题，查阅了网上很多资料各种说法的都有，有的说是什么请求站点不在同一个域下，有的说什么应为datatable中有一个属性没有赋值各种答非所问的问题。其实从错误信息中就可以看出来其实就是调用超时了。
通过《上篇》介绍，我们知道了如何通过编程和配置的方式设置相应的最大并发量，从而指导WCF的限流体系按照你设定的值对并发的服务调用请求进行限流控制。那么，在WCF框架体系内部，整个过程是如何实现的呢？这就是本篇文章需要为你讲述的内容。实际上，整个限流控制体系，主要涉及到两个对象：信道分发器（ChannelDispatcher）和ServiceThrottle。 一、信道分发器（ChannelDispatcher）与ServiceThrottle 从服务端整个消息监听、接收、分发和处理框架体系角度来讲，限流控
最后一章将进行WCF扩展和新特性的学习，这部分内容有一定深度，有一个基本的了解即可，当需要自定义一个完整的SOA框架时，可以再进行细致的学习和实践。 服务端架构体系的构建主要包含接下来的几个要素：服
在这篇文章中，我们对信道分发器本身作一个深入的了解，首先来看看它具有哪些可供扩展的组件，以及我们可以针对信道分发器对WCF实现哪些可能的扩展。 目录： ErrorHandler & ServiceThrottle ChannelInitializer IncludeExceptionDetailInFaults ManualAddressing MaxPendingReceives ReceiveSynchronously
在介绍终结点的ListenUriMode时，我们提到了两个特殊的对象ChannelDispatcher和ChannelListener。这两个对象在整个WCF的消息分发系统中具有重要的地位，在这节里，我们对WCF的整个消息分发过程作一个简单的介绍。 一、连接请求的监听 当我们通过ServiceHost对某个服务进行寄宿的时候，实际上WCF是在为我们创建一个监听器，并监听来自外界的服务访问请求。我们举一个例子，比如针对服务CalculateService，具有如下的配置：该服务具有基于BasicHttpBi
1当客户端调用未返回结果时，服务不可用（网络连接中断，服务关闭，服务崩溃等） 客户端抛出异常 异常类型：CommunicationException InnerException: Message：
本文参考自http://www.cnblogs.com/wangweimutou/p/4367905.html Visual studio 针对服务配置提供了一个可视化的配置界面(Microsoft
WCF的服务端架构体系又可以成为服务寄宿端架构体系。我们知道，对于一个基于某种类型的服务进行寄宿只需要使用到一个唯一的对象，那就是ServiceHost。甚至在某种语境下，我们所说的服务实际上就是指的对应的ServiceHost对象。整个服务寄宿过程包括两个阶段，即服务描述的创建和服务端运行框架的建立。而第一个阶段创建的服务描述是为了第二个阶段对服务端运行时框架建立服务的，所以我们有必要在对服务描述进行简单的介绍。 目录： 一、从服务描述（Service Description）谈起
通过《如何将一个服务发布成WSDL[编程篇]》的介绍我们知道了如何可以通过编程或者配置的方式将ServiceMetadataBehavior这样一个服务形式应用到相应的服务上面，从而实现基于HTTP-GET或者WS-MEX的元数据发布机制。那么在WCF内部具体的实现原理又是怎样的呢？相信很多人对此都心存好奇，本篇文章的内容将围绕着这个主题展开。 一、 从WCF分发体系谈起 如果读者想对WCF内部的元数据发布机制的实现原理有一个全面而深入的了解，必须对WCF服务端的分发体系有一个清晰的认识。在这里我们先对
Windows Communication Foundation (WCF) 是一个框架，用于生成面向服务的应用程序。它取代了较旧的进程间通信技术，例如 ASMX Web 服务、.NET 远程处理、企业服务 (DCOM) 和 MSMQ。 WCF 将所有这些技术的功能汇集在一个统一的编程模型下，简化了开发分散式应用程序的体验。 使用 WCF，可以将数据作为异步消息从一个服务终结点发送到另一个服务终结点。 服务终结点可以是由 IIS 承载的持续可用的服务的一部分，也可以是应用程序中承载的服务。 终结点可以是从服务终结点请求数据的服务客户端。 简单消息可以是作为 XML 发送的单个字符或单个单词，复杂消息可以是二进制数据流。
上面一部分我们站在信道层的角度剖析了WCF为了实现可靠会话在信道层进行的一系列消息交换，或者说客户端和服务端的RS信道为了实现可靠消息传输所进行一轮又一轮的握手。这一切都是基于这样一个假设：两个RS信道均可以在适当的时机向对方发送消息，或者说两个RS信道之间是一个双工的通道。 如果我们站在传输层看待这个问题，该假设对于TCP传输是成立的，但是对于HTTP来说就有点问题了。HTTP本身就是一个基于请求|回复消息交换模式的应用层网络协议，并不能对双工通信提供支持。而WCF通过WSDualHttpBinding
今天写《WCF技术剖析（卷2）》关于“队列服务”部分，看了《WCF服务编程》相关的内容。里面介绍一个关于“终结点不能共享相同的消息队列”说法，个人觉得这值得商榷。撰写此文，希望对此征求大家的意见。[源代码从这里下载] 目录 一、“终结点不能共享相同的消息队列” 二、实践出真知 三、为什么同一个服务的终结点可以共享相同的消息队列 四、为什么不同服务的终结点不能共享相同的终结点 一、“终结点不能共享相同的消息队列” 在《WCF服务编程（第三版）》的第9章《
题外话：本以为我会WCF了，精通WCF了，毕竟刚做过一个WCF的项目，不就是写写契约接口，然后实现接口，改下配置。最后用控制台或者服务发布一下，不就能用了。不就是简单ABC吗？不是So Easy吗？做第二个项目的时候我悲剧了，被碰的头破血流！忽然发现什么什么都不会（第一个项目比照网上教程一步一步弄的），连写一个简单hello world都写不出来。我之前还以为自己很懂了…… 一、WCF文件配置 为了不重蹈覆辙，这次争取把他整懂整透（当然这才是入门而已）。WCF很强大，它的强大跟它的配置有很大的
终结点是整个WCF的核心，由经典的ABC三要素组成。作为表示地址的EndpointAddress，很多人仅仅将其看成是一个表示标识服务并且表示服务所在地址的Uri，其实服务标识和定位服务仅仅是EndpointAddress一个基本的功能，它不仅仅是Uri那么简单。 一、EndpointAddress的三个功能 作为终结点的三要素之一的地址（Address），在基于WCF的通信中不仅仅定位着服务的位置，而且还提供额外的寻址信息。除此之外，终结点地址还和安全有关系，因为它包含着用于进行服务认证的服务身份信息。这
为了使读者对基于WCF的编程模型有一个直观的映像，我将带领读者一步一步地创建一个完整的WCF应用。本应用功能虽然简单，但它涵盖了一个完整WCF应用的基本结构。对那些对WCF不是很了解的读者来说，这个例子将带领你正式进入WCF的世界。 在这个例子中，我们将实现一个简单的计算服务（CalculatorService），提供基本的加、减、乘、除的运算。和传统的分布式通信框架一样，WCF本质上提供一个跨进程、跨机器以致跨网络的服务调用。在本例中，客户端和服务通过运行在相同的同一台机器上不同进程模拟，图1体现了客户端
在一个典型的服务调用场景中，具有两个基本的角色，即服务的消费者和服务的提供者。从消息交换的角度讲前者一般是消息的最初发送者，而后者则是消息的最终接收者。在很多情况下，由于网络环境的局限，消息的最初发送者和最终接收者不能直接进行消息交换，这就需要一个辅助实现消息路由的中介服务，这就是我们接下来要介绍的路由服务。 目录 一、路由服务就是一个WCF服务 路由服务契约的定义 路由服务契约的定义 二、基于消息内容的路由策略
在《上篇》中，我通过一个具体的实例演示了WCF服务宿主的同步上下文对并发的影响，并简单地介绍了同步上下文是什么东东，以及同步上下文在多线程中的应用。那么，同步上下文在WCF并发体系的内部是如何影响服务操作的执行的呢？这实际上涉及到WCF的一个话题，即线程的亲和性（Thread Affinity），本篇文章将为你剖析WCF线程亲和机制的本质。 一、WCF线程亲和性（Thread Affinity） 对于服务端来说，WCF消息监听和接收体系通过IO线程池并发的处理来自客户端的服务调用请求，所以并发抵达的服务
动手了，WCF 开发WCF服务的终结点需要涉及下面几个任务： 开发服务契约：指定终结点可用的WCF服务的操作。 开发绑定：绑定指点终结点与外界通信的协议。 添加，删除，更新和配置端点：在配置文件中添加和绑定终结点（当然也可以用编码的形式，但是不推荐。） 添加行为：一个行为就是一个组件，能增强服务，终结点，和操作的运行时行为。 定义契约 契约就是一个用元数据属性[ServiceContract]修饰的.NET接口或类。每个WCF服务可以有一个或多个契约，每个契约是一个操作集合。请注意：[ServiceCont
为了使读者对基于WCF的编程模型有一个直观的映像，我将带领读者一步一步地创建一个完整的WCF应用。本应用功能虽然简单，但它涵盖了一个完整WCF应用的基本结构。对那些对WCF不是很了解的读者来说，这个例子将带领你正式进入WCF的世界。
WCF客户端和服务端的框架体系相互协作，使得开发人员可以按照我们熟悉的方式进行异常的处理：在服务操作执行过程中抛出异常（FaultException），在调用服务时捕获异常，完全感觉不到“分布式”的存在，如同典型的“本地”操作一般。为了实现这样的效果，WCF在内部为我们作了很多。 消息交换是WCF进行通信的唯一手段，消息不仅仅是正常服务调用请求和回复的载体，服务端抛出的异常，甚至是服务的元数据都是通过消息的形式传向客户端的。所以，实现异常与消息之间的转换是整个异常处理体系的核心，而WCF的异常处理框架就着
在[WS标准篇]中我花了很大的篇幅介绍了WS-MEX以及与它相关的WS规范：WS-Policy、WS-Transfer和WSDL，因为WCF元数据结构体系完全是基于WS-MEX等相关的规范之上。熟悉这些基本的WS规范，对于我们全面、深刻的理解WCF整个元数据架构体系具有十分重要的意义。不仅仅是针对元数据，对于后续章节陆续要介绍的内容，比如事务、可靠会话、安全等，我强烈建议读者在正式进行相关部分的学习之前，先对相关的WS规范作一个大致的了解。 通过对WS-MEX的介绍，我们知道：不论是采用WS-Trans
第一次邂逅WCF是在微软举办的一场关于Windows Vista技术推广培训上，时间大概是2005年10月份，当时对WCF可谓是一见钟情。如果读者也像我一样，之前习惯了采用.NET Remoting、XML Web Service、WSE、MSMQ来架构你分布式应用的话，应该不难想象我第一次接触WCF时心中的那份震撼。WCF是Windows平台下所有分布式技术集大成者，它将这一系列独立的分布式技术整合，提供一个统一的应用编程接口，这本身就是一项创举。这些被整合的分布式技术不仅仅包含提到的这些，还包括DCOM
这部分将介绍一些相对深入的知识点，包括通过并发限流来保证服务的可用性，通过可靠会话机制保证会话信息的可靠性，通过队列服务来解耦客户端和服务端，提高系统的可服务数量并可以起到削峰的作用，最后还会对之前的
任何一个程序都需要运行于一个确定的进程中，进程是一个容器，其中包含程序实例运行所需的资源。同理，一个WCF服务的监听与执行同样需要通过一个进程来承载。我们将为WCF服务创建或指定一个进程的方式称为服务寄宿（Service Hosting）。服务寄宿的本质通过某种方式，创建或者指定一个进程用以监听服务的请求和执行服务操作，为服务提供一个运行环境。 服务寄宿的方式大体分两种：一种是为一组WCF服务创建一个托管的应用程序，通过手工启动程序的方式对服务进行寄宿，所有的托管的应用程序均可作为WCF服务的宿主，比如C
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
