在设计和实现服务协定后，即可配置服务。在其中可以定义和自定义如何向客户端公开服务，包括指定可以找到服务的地址、服务用于发送和接收消息的传输和消息编码，以及服务需要的安全类型。
文本参考自:http://www.cnblogs.com/wangweimutou/p/4365260.html 简介:WCF作为分布式开发的基础框架,在定义服务以及消费服务的客户端时可以通过配置文件的方式,来进行设置,这充分的体现了WCF的伸缩性和自定义性。当然WCF也提供硬编程的方式，通过在代码中直接设置相关对象的属性来完成服务端与客户端的配置，然而这种方式并不利于后期程序的更改和扩展。 一、WCF配置文件结构如下图所示,包含三个部分,services(服务)、bindings(绑定)、behavior
服务是一个构造，它公开一个或多个终结点，其中每个终结点都公开一个或多个服务操作。
为了使读者对基于WCF的编程模型有一个直观的映像，我将带领读者一步一步地创建一个完整的WCF应用。本应用功能虽然简单，但它涵盖了一个完整WCF应用的基本结构。对那些对WCF不是很了解的读者来说，这个例子将带领你正式进入WCF的世界。
为了使读者对基于WCF的编程模型有一个直观的映像，我将带领读者一步一步地创建一个完整的WCF应用。本应用功能虽然简单，但它涵盖了一个完整WCF应用的基本结构。对那些对WCF不是很了解的读者来说，这个例子将带领你正式进入WCF的世界。 在这个例子中，我们将实现一个简单的计算服务（CalculatorService），提供基本的加、减、乘、除的运算。和传统的分布式通信框架一样，WCF本质上提供一个跨进程、跨机器以致跨网络的服务调用。在本例中，客户端和服务通过运行在相同的同一台机器上不同进程模拟，图1体现了客户端
线上正式环境调用WCF服务正常，但是每次使用本地测试环境调用WCF服务时长就是出现：套接字连接已中止。这可能是由于处理消息时出错或远程主机超过接收超时或者潜在的网络资源问题导致的。本地套接字超时是“00:05:30” 这个问题，查阅了网上很多资料各种说法的都有，有的说是什么请求站点不在同一个域下，有的说什么应为datatable中有一个属性没有赋值各种答非所问的问题。其实从错误信息中就可以看出来其实就是调用超时了。
老的Windows通讯开发平台有：WebService和.net Remoting等。
上面一部分我们站在信道层的角度剖析了WCF为了实现可靠会话在信道层进行的一系列消息交换，或者说客户端和服务端的RS信道为了实现可靠消息传输所进行一轮又一轮的握手。这一切都是基于这样一个假设：两个RS信道均可以在适当的时机向对方发送消息，或者说两个RS信道之间是一个双工的通道。 如果我们站在传输层看待这个问题，该假设对于TCP传输是成立的，但是对于HTTP来说就有点问题了。HTTP本身就是一个基于请求|回复消息交换模式的应用层网络协议，并不能对双工通信提供支持。而WCF通过WSDualHttpBinding
为什么要用 Netmaker？Netmaker 和 WireGuard 的关系是什么？
今天介绍WCF 4.0的另外两个新特性：标准终结点（Standard Endpoint）和无(.SVC)文件服务激活（File-Less Activation）。前者实现了针对典型通信场景对终结点的定制，后者让你在进行IIS/WAS的服务寄宿中无须定义.svc文件。 一、标准终结点 我们知道，绑定的本质就是一系列相关绑定元素的有序集合，而系统绑定就是基于若干典型的通信场景对相关绑定元素的整合。WCF通过系统绑定对绑定元素进行了定制，那么能否在终结点级别对组成该终结点的ABC（地址、绑定和契约）也进行相应的定
客户端调用WCF服务的方式不外乎有两种：其一、通过代码生成工具（比如SvcUtil.exe）导入服务的元数据生成服务代理相关的类型；其二、通过ChannelFactory<TChannel>创建服务代理对象。对于前者，生成的服务代理是一个继承自ClientBase<TChannel>的类型。对于这样一个服务代理对象，其内部本质上还是借助于ChannelFactory<TChannel>创建真正用于进行服务调用的代理对象。对于WCF客户端应用编程接口来说，ChannelFactory<TChannel>是一个
开篇，简单知识介绍： 最近开始用WCF，一直仅限于初级阶段，整理了下思路，深入研究一下。 开始时，在看一个叫Artech写的系列文章，结果。。。 1、长篇大作，有絮叨之嫌 2、“专业术语”横行，这还可以接受，也许这就是面向高端人员看的 3、广告太多，卖书就卖书，没必要博文的每一段都加个链接 4、夹生英文词太多，而且还是很多特别简单的，比如blog、link之类的，看着别扭，额。。。个人喜好，不过多做评价。 没办法，只能愤而关之，另寻他途。于是乎，找到了这个，参考着看，这里有一部分是复制，一部分是自己的想法。
本章节将进行元数据和异常处理的介绍，这部分内容概念型比较强，可以快速浏览一下就好。 客户端和服务器借助于终结点进行通信，服务的提供者通过一个或者多个终结点将服务发布出来，服务的消费者则通过创建与之匹
整个WCF框架由两个基本的层次构成，即服务模型层和信道层。对信道层的扩展主要通过针对绑定的扩展实现，具体来说就是自定义绑定元素，以及相关的信道管理器（信道监听器和信道工厂）、信道来改变对消息的处理和传输方式。 而对于服务模式型层的扩展则主要体现服务端和客户端运行时框架的定制，进而让WCF按照我们希望的方式进行运作。由于整个运行时框架由一系列的可扩展组件构成，并且大部分运行时属性也可以改写，所以针对服务模型层的扩展具体体现在：根据具体的需要定义相应的组件，并以某种情形将这些自定义的组件应用到运行时框架相应的地
1、创建WCF客户端应用程序需要执行下列步骤 (1)、获取服务终结点的服务协定、绑定以及地址信息 (2)、使用该信息创建WCF客户端 (3)、调用操作 (4)、关闭WCF客户端对象 二、操作实例 1、
今天写《WCF技术剖析（卷2）》关于“队列服务”部分，看了《WCF服务编程》相关的内容。里面介绍一个关于“终结点不能共享相同的消息队列”说法，个人觉得这值得商榷。撰写此文，希望对此征求大家的意见。[源代码从这里下载] 目录 一、“终结点不能共享相同的消息队列” 二、实践出真知 三、为什么同一个服务的终结点可以共享相同的消息队列 四、为什么不同服务的终结点不能共享相同的终结点 一、“终结点不能共享相同的消息队列” 在《WCF服务编程（第三版）》的第9章《
转眼微软的WCF已走过十个年头，它是微软通信框架的集大成者，将之前微软所有的通信框架进行了整合，提供了统一的应用方式。记得从自己最开始做MFC时，就使用过Named Pipe命名管道，之后做Winform时，使用过Remoting，再之后做B/S架构时，就会经常使用.NET平台下的Web Service，直到使用上WCF。看上去有了一些WCF的使用经验，实则不然，比如对安全、分布式事务、可靠会话等主题仍然接触甚少，因而决定重新回顾学习一下相关知识，尤其是对WCF框架的理解（已于2015年开源，可下载源码，h
1当客户端调用未返回结果时，服务不可用（网络连接中断，服务关闭，服务崩溃等） 客户端抛出异常 异常类型：CommunicationException InnerException: Message：
终结点是整个WCF的核心，由经典的ABC三要素组成。作为表示地址的EndpointAddress，很多人仅仅将其看成是一个表示标识服务并且表示服务所在地址的Uri，其实服务标识和定位服务仅仅是EndpointAddress一个基本的功能，它不仅仅是Uri那么简单。 一、EndpointAddress的三个功能 作为终结点的三要素之一的地址（Address），在基于WCF的通信中不仅仅定位着服务的位置，而且还提供额外的寻址信息。除此之外，终结点地址还和安全有关系，因为它包含着用于进行服务认证的服务身份信息。这
任何一个程序都需要运行于一个确定的进程中，进程是一个容器，其中包含程序实例运行所需的资源。同理，一个WCF服务的监听与执行同样需要通过一个进程来承载。我们将为WCF服务创建或指定一个进程的方式称为服务寄宿（Service Hosting）。服务寄宿的本质通过某种方式，创建或者指定一个进程用以监听服务的请求和执行服务操作，为服务提供一个运行环境。 服务寄宿的方式大体分两种：一种是为一组WCF服务创建一个托管的应用程序，通过手工启动程序的方式对服务进行寄宿，所有的托管的应用程序均可作为WCF服务的宿主，比如C
这部分主要涉及企业级应用的安全问题，一般来说安全框架主要提供3个典型的安全行为：认证、授权和审核。除了典型的安全问题，对于一个以消息作为通信手段的分布式应用，还需要考虑消息保护(Message Pro
本文参考自:http://www.cnblogs.com/wangweimutou/p/4422883.html,纯属读书笔记,加深记忆 一、服务协定简介: 1、WCF所有的服务协定层里面的服务接口,
Windows Communication Foundation (WCF) 是一个框架，用于生成面向服务的应用程序。它取代了较旧的进程间通信技术，例如 ASMX Web 服务、.NET 远程处理、企业服务 (DCOM) 和 MSMQ。 WCF 将所有这些技术的功能汇集在一个统一的编程模型下，简化了开发分散式应用程序的体验。 使用 WCF，可以将数据作为异步消息从一个服务终结点发送到另一个服务终结点。 服务终结点可以是由 IIS 承载的持续可用的服务的一部分，也可以是应用程序中承载的服务。 终结点可以是从服务终结点请求数据的服务客户端。 简单消息可以是作为 XML 发送的单个字符或单个单词，复杂消息可以是二进制数据流。
近半年以来，一直忙于我的第一本WCF专著《WCF技术剖析（卷1）》的写作，一直无暇管理自己的Blog。在《WCF技术剖析（卷1）》写作期间，对WCF又有了新的感悟，为此以书名开始本人的第三个WCF系列。本系列的目的在于对《WCF技术剖析》的补充，会对书中的一些内容进行展开讲述，同时会囊括很多由于篇幅的原因忍痛割弃的内容。 [第1篇] 通过一个ASP.NET程序模拟WCF基础架构 本系列的第一篇，我将会对WCF的基本架构作一个大致的讲解。不过，一改传统对WCF的工作流程进行平铺直叙，我将另辟蹊径，借助于我
本随笔参考自WCF编程系列(一)初识WCF,纯属读书笔记,加深记忆。 1、简介:Windows Communication Foundation(WCF)是微软为构建面向服务的应用程序所提供的统一编程模型。在WCF之前，.NET Framework提供了多种分布式技术，如ASP.NET Web服务、.NET Framework远程处理、企业服务、WSE以及Microsoft消息队列。一般我们在编写一个应用程序时通常会同时使用多项技术,所以,微软将这些分布式应用程序集成到了一起,形成了WCF这个框架。即通过W
在采用TLS/SSL实现Transport安全的情况下，客户端对服务证书实施认证。但是在默认情况下，这种认证仅仅是确保服务证书的合法性（通过数字签名确保证书确实是由申明的CA颁发）和可信任性（证书或者CA证书存储于相应的可信赖存储区）。而WCF提供服务证书并不限于此，客户端对服务认证的模式应该是这样的：服务端预先知道了服务的身份，在进行服务调用之前，服务端需要提供相应的凭证用以辅助客户端确认调用的服务具有预先确定的身份。对于这样的服务认证模式，具有两个重要的概念，即服务凭证和服务身份。 目录：
最后一章将进行WCF扩展和新特性的学习，这部分内容有一定深度，有一个基本的了解即可，当需要自定义一个完整的SOA框架时，可以再进行细致的学习和实践。 服务端架构体系的构建主要包含接下来的几个要素：服
在MSDN上有一篇入门教程。讲解的十分基本，十分详细，详细到每一个细节，然我彻底了解入门的每一个细节，整个教程结构清晰，代码简洁，讲解细致，值得推荐。 做这分5部来讲解创建一个最基本的基于B/S构架的WCF应用。服务是根据输入的两个数字，返回这两个数字的加减乘除运算结果。地址是：http://msdn.microsoft.com/zh-cn/library/ms734712.aspx 如何：定义 Windows Communication Foundation 服务协定 描述如何使用用户定义的接
作为WCF中一个核心概念，终结点在不同的语境中实际上指代不同的对象。站在服务描述的角度，我们所说的终结点实际上是指ServiceEndpoint对象。如果站在WCF服务端运行时框架来说，终结点实际上指代的是终结点分发器（EndpointDispatcher）。而ServiceEndpoint与EndpointDispatcher是一一匹配的，并且前者是创建后者的基础。而终结点分发器具有自己的运行，即分发运行时（DispatchRuntime）。 目录 一、终结点分发器（EndpointDisp
在《上篇》中，我通过一个具体的实例演示了WCF服务宿主的同步上下文对并发的影响，并简单地介绍了同步上下文是什么东东，以及同步上下文在多线程中的应用。那么，同步上下文在WCF并发体系的内部是如何影响服务操作的执行的呢？这实际上涉及到WCF的一个话题，即线程的亲和性（Thread Affinity），本篇文章将为你剖析WCF线程亲和机制的本质。 一、WCF线程亲和性（Thread Affinity） 对于服务端来说，WCF消息监听和接收体系通过IO线程池并发的处理来自客户端的服务调用请求，所以并发抵达的服务
经过WCF基础的ABC学习，已经可以构建简单的WCF的服务，使用不同的服务地址和绑定类型，根据业务提供所需的服务契约。但不禁想问，服务所使用的消息报文是什么样的形式么？蕴含什么样内容呢？WCF服务是否
服务通过 ServiceHost 进行寄宿。可以添加终结以暴露可被调用寻址和调用的资源。
信道管理器是信道的创建者，一般来说信道栈的中每个信道对应着一个信道管理器。基于不同的消息处理的功能，将我们需要将相应的信道按照一定的顺序能组织起来构成一个信道栈，由于信道本身是由信道管理器创建的，所以信道对应的信道管理器也构成一个信道管理器栈，栈中信道管理器的顺序决定由它所创建信道的顺序。 对于WCF的信道层来说，信道管理器在服务端和客户端扮演着不同的角色，服务端的信道管理器在于监听来自客户端的请求，而客户端的信道仅仅是单纯的创建用于消息发送的信道。因此，客户端的消息管理器又称为信道监听器（Channel
第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
通过配置文件来设置Host、Endpoint、Binding等是WCF中推荐的方法，这样可以使发布尽量灵活。其实配置文件中的值，最终还是要体现到代码中的，只不过这部分工作由底层帮你做了。我们今天来尝试去掉配置文件，用纯代码实现发布过程，同时加深一下对层次关系的理解。
WCF客户端和服务端的框架体系相互协作，使得开发人员可以按照我们熟悉的方式进行异常的处理：在服务操作执行过程中抛出异常（FaultException），在调用服务时捕获异常，完全感觉不到“分布式”的存在，如同典型的“本地”操作一般。为了实现这样的效果，WCF在内部为我们作了很多。 消息交换是WCF进行通信的唯一手段，消息不仅仅是正常服务调用请求和回复的载体，服务端抛出的异常，甚至是服务的元数据都是通过消息的形式传向客户端的。所以，实现异常与消息之间的转换是整个异常处理体系的核心，而WCF的异常处理框架就着
和传统的分布式远程调用一样，WCF的服务调用借助于服务代理（Service Proxy）。而ChannelFactory<T>则是服务代理的创建者。WCF采用基于终结点（Endpoint）服务消费方式：WCF服务通过一个或者多个终结点暴露给潜在的服务消费者，服务的消费中通过与之匹配的终结点与之交互。在客户端，我们具有两种典型的服务代理创建方式，其一是通过诸如SvcUtil.exe这样的工具导入服务的元数据生成相应的服务代理（一个继承自ClientBase<T>的类型）代码和相关配置；其二是直接通过相应的终结
Windows® Communication Foundation (WCF) 提供了许多扩展点，供开发人员自定义运行时行为,从而实现服务调度和客户代理调用。您可以通过编写能以声明方式应用到服务中的自定义行为来使用这些扩展点。本月将为您介绍这一流程的工作原理。 WCF 可扩展性 在上期专栏中，我重点介绍了 WCF 绑定概念，您可以为 WCF 服务上的各个终结点指定绑定。绑定控制该终结点的消息传递详细信息（发生在网络上的情况）。这是 WCF 建立一个能够在字节流（网络上的消息）和 WCF 消息间转换的通道堆栈
在基于TCP/IP协议簇的对等网络通信下，相互通信的应用程序运行各自的进程中，出于应用层的进程将数据局封装成数据报，并通过传输层的TCP或者UDP进行网络通信。而TCP和UPD则通过一个16bit的端口来识别不同的应用程序。
在一个典型的服务调用场景中，具有两个基本的角色，即服务的消费者和服务的提供者。从消息交换的角度讲前者一般是消息的最初发送者，而后者则是消息的最终接收者。在很多情况下，由于网络环境的局限，消息的最初发送者和最终接收者不能直接进行消息交换，这就需要一个辅助实现消息路由的中介服务，这就是我们接下来要介绍的路由服务。 目录 一、路由服务就是一个WCF服务 路由服务契约的定义 路由服务契约的定义 二、基于消息内容的路由策略
本文参考自http://www.cnblogs.com/wangweimutou/p/4367905.html Visual studio 针对服务配置提供了一个可视化的配置界面(Microsoft
在《再谈IIS与ASP.NET管道》介绍各种版本的IIS的设计时，我们谈到IIS 7.0因引入WAS提供了对非HTTP协议的支持。这个对于WCF的服务寄宿来说意义重大，它意味着我们通过IIS/WAS寄宿的服务终结点不仅仅可以采用BasicHttpBinding、WSHttpBinding/WS2007HttpBinding等基于HTTP协议的绑定，也可以采用NetTcpBinding、NetNamedPipeBinding和NetMsmqBinding。 在默认的情况下，IIS 7.0针对非HTTP支持的特
现代企业的 IP 网络都连接到了全球 Internet，它们使用 Internet 实现自己的数据传输需求，并且通过 Internet 为客户和业务合作伙伴提供各种服务。为了满足这些不同的需求，人们必须能够从世界各地访问多种系统—从 Web 服务器到大型机，再到工作站。
在上面一篇文章中，我们对不同版本的IIS，以及ASP.NET得的实现机制进行了详细而深入的分析。在介绍IIS7.0的时候，我们谈到，HTTP.SYS+W3SVC实现了基于HTTP的请求监听，在此基础上引入了以下三组网络监听器（Listener）和监听适配器（Adapter），实现了基于TCP、Named Pipes和MSMQ的网络监听，图1揭示了IIS7的总体结构。 TCPListener|TCP Listener Adapter NamedPipes Listener|Named Pipes Liste
最近在学习WCF技术，闲来做了一个小小的WCF三层架构模式的Demo,对传统的C-S架构模式有了全新的诠释和新的理解！
在定义和寄宿WCF服务的时候会面临三个名称/命名空间，它们分别是ServiceContractAttribute、ServiceBehaviorAttribute和Binding的Name和Namespace属性，很对人对此不能很好地区分。 一、ServiceContractAttribute的名称/命名空间 每个服务契约都有一个确定的名称，当在一个接口或类上应用了ServiceContractAttribute特性，默认的名称就是接口或类的名称。我们可以通过Name属性显式地指定需要的名称，这在某些场景中
作为一个通信基础平台,WCF必须保证通信的可靠性。由于消息交换是WCF采用的通信手段，通信可靠性的保障体现在确保消息的可靠传输。WCF本质上是一个消息处理框架，作为整个消息交换系统的两个终端，即发送端和接收端。换句话说，WCF仅仅负责对消息的发送和接收，一旦消息通过WCF的信道层进入了网络，就脱离了WCF的控制范围。但是，由于网络环境的限制，网络层不能百分之百地确保对消息的有效交付。如何克服中间环节的制约，确保从一端发送的消息能够被有效地交付给另一端，这就是可靠消息传输（Reliable Messaging
通过《如何将一个服务发布成WSDL[编程篇]》的介绍我们知道了如何可以通过编程或者配置的方式将ServiceMetadataBehavior这样一个服务形式应用到相应的服务上面，从而实现基于HTTP-GET或者WS-MEX的元数据发布机制。那么在WCF内部具体的实现原理又是怎样的呢？相信很多人对此都心存好奇，本篇文章的内容将围绕着这个主题展开。 一、 从WCF分发体系谈起 如果读者想对WCF内部的元数据发布机制的实现原理有一个全面而深入的了解，必须对WCF服务端的分发体系有一个清晰的认识。在这里我们先对
本文参考自http://www.cnblogs.com/wangweimutou/p/4516224.html,纯属读书笔记,加深记忆 一、WCF会话简介 1、在WCF应用程序中,回话将一组消息相互关联,从而形成一个回话(回话可以理解为一段时间内的通话,有开始,有结束),会话是服务端和客户端的终结点在在开始回话和结束回话这段时间内的所有消息的一个集合。 2、WCF中的回话机制通过设置服务协定ServiceContract上的SessionMode的枚举值来设置服务协定是否要求、允许或者拒绝基于回话的绑定.枚
本文将定义一个 WCF 终结点行为扩展，以在 WCF 中使用更高效的 BinaryFormatter 进行二进制序列化，并实现对是否使用传统二进制序列化功能的可配置。 介绍 实现步骤 使用方法 效果 介绍 在 OEA 框架中，是使用 WCF 作为数据传输框架。但是使用 WCF 内部的二进制序列化，序列化后的数据大小，要比使用传统的 System.Runtime.Serialization.Formatters.Binary.BinaryFormatter 类进行序列化后的数据大小要大得多。作为使用 .NET
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
