WCF
摘要: 当使用WCF寄宿时它能带来很大的灵活性。特别的，WCF服务可以在任何操作系统进程中寄宿。服务宿主，或者仅仅成为"宿主"， 负责启动和关闭服务并为控制服务提供基本的管理函数。为一个基于操作性能要求比如可用性，可信赖性和可管理性的服务选择正确的寄宿环境。 IIS和Windows 进程激活服务(WAS)有用来寄宿WCF服务的内建结构。先前特性只在IIS中可用，比如进程激活，回收和身份管理，已经被移植到WAS中并对除了 HTTP协议的所有协议可用。这让WAS成为一个IIS的超级替代者，但是IIS对寄宿基于HTTP的WCF服务是很理想的。WCF通过ASP.NET 兼容模式支持很多AS阅读全文
摘要: 一个WCF服务是一系列终结点集合，每个终结点有一个独一无二的地址。终结点地址和绑定确定了终结点在哪里以及如何监听进入请求。除了终结点地址，服务本身也有地址，称为基地址。 一个服务的基地址用来作为可能在终结点中定义的相对地址的基地址。使用相对地址，而不是绝对地址，终结点地址让在一个服务中管理终结点变得更加容易。通过相对地址，你可以在一个服务中仅通过改变服务基地址就改变所有终结点地址。 当在一个终结点中使用一个相对地址时，相对地址附加到基地址来形成服务基地址。例如，如果一个服务基地址是http://localhost/foo 而终结点地址是bar,终结点将会在http://localhost/fo阅读全文
摘要: 寄宿WCF服务最常用的环境是IIS或者WAS。在一个公共架构上创建，它们都提供鲁棒性进程控制和生命周期回收服务，还有一个熟悉的管理接口。当IIS架构已经在使用时这是对大多数场景来说最合适的解决方案。 然而，也有一些情况你不想在IIS或者WAS中寄宿一个服务。你可能想显式控制事件的启动和停止。或者你可能想提供一个自定义管理接口而不是使用IIS或 者WAS工具。为了实现这个，你可以使用System.ServiceModel命名空间中的ServiceHost类来在任何程序中寄宿一个服务。当你 做这个时，你正在使用一个自我寄宿的WCF服务。 寄宿一个WCF服务最常用的场景是在一个随系统启动和停止的Wi阅读全文
摘要: 将应用程序功能聚集到正确的服务层次是系统设计的一个必须元素。创建一个有很多接口的系统，这个系统也会变得很令人迷惑。创建只有很多接口的一个系统，这个系统会是变成一个很难改变的整体。 在第二章”契约”，我们描述了如何将多个类接口集成到一个单一的终结点中。这是通过.NET接口集成完成的。我们也描述了如何在一个单一服务内部暴露多个 终结点。这一部分提供了一个可供选择的方案。不是通过将两个接口合并为一个然后将聚合作为一个服务暴露出来，这里我们描述的是如何在一个单一的操作系统进 程内分别暴露两个服务。 一个ServiceHost 仅暴露一个服务。所以，为了在一个操作系统进程内暴露多个服务，你需要实现多个S阅读全文
摘要: 在WCF之前，ASMX是ASP.NET Web 服务中一个公共处理方式。它对公共Web服务需求提供了出色的支持并通过ASP.NET HTTP管道提供了鲁棒性扩展能力。在WCF中，服务被设计为不需了解它们的寄宿模且独立传输。所以WCF服务不能依赖于HTTP管道内部的实现，比如 HTTP.SYS。 和ASMX一样，WCF也提供一个鲁棒性扩展模型。但是除了使用HTTP管道，它也采用信道栈。WCF中的信道非常灵活。它们了解传输协议，比如HTTP，但是也了解其他的协议元素比如安全和事务。信道栈在第三章”信道”和第四章”绑定”中描述。 WCF支持IIS中的一个特殊寄宿模型: ASP.NET 兼容模式。当运阅读全文
摘要: IIS6在Windows 2003和Windows XP SP2中存在，应用程序池作为一个运行时容器来寄宿应用程序。这允许对启动和关闭的控制，在每一个进程的基础上进行身份认证和回收服务。它原本就提供了跨 应用程序的进程隔离功能，这个功能带来了很大的可信赖性。总的来说进程管理是由应用程序池架构处理的。 IIS7在Windows Vista和Windows Server 2008 中存在，进程管理已经实现对多种协议支持并移植到WAS中。ASP.NET也扩展来支持进程激活和WAS中的服务寄宿。 图片7.4 描述了在WAS架构上的IIS7. 在IIS7中寄宿一个服务的三个最小的步骤在第一章描述了。简短阅读全文
摘要: Windows进程激活服务(WAS)是Vista和Windows Server 2008 自带的寄宿基础。先前的特性只在IIS中才有，比如进程激活，回收和身份标识管理，已经加入到WAS中而且支持所有的协议除了HTTP。 WAS允许你在一个不依赖HTTP协议的鲁棒环境中寄宿服务。HTTP协议被广泛部署和理解，但是有一些情况它并不是最好的选择。 例如，想象有一个为跟踪和分析的目的而接受一条单向消息的服务，消息由客户端发送并最终从网络中断开。为了提供在断开网络时的消息发送能力，需要一个队列 结构。MSMQ协议将会完成这个，而HTTP协议将不会完成这个。或者，想象一个非常"不正式"阅读全文
摘要: 一个服务宿主就是用来管理一个WCF服务的生命周期和上下文服务的一个操作系统进程。服务宿主，或者仅称为”宿主”，负责启动和停止WCF服务并提供一些基本的管理函数来控制WCF服务。除了这方面，宿主对运行在它的内存空间里的WCF服务知道的很少。阅读全文
摘要: 之前，你有很多创建分布式应用程序的选择。其中的两个选择是.NET Remoting和ASP.NET 网络服务。.NET Remoting 很适合.NET 应用程序间的通信因为它使用二进制编码传输数据。这比ASP.NET 网络服务提供更好的性能，ASP.NET 网络服务在交互中使用文本编码。由于文本编码允许跨平台交互所以它在ASP.NET 网络服务中是被广泛接受的。WCF将编码架构抽象出来并允许同时使用两种编码格式的绑定存在。这使得WCF可以同时取代.NET Remoting和ASP.NET 网络服务。阅读全文
摘要: DataContractSerializer是WCF中优先选择的序列化方法。然而，有时你需要使用默认序列化方法以外的方法。一个改变序列化方法的选项是使用XmlSerializer,包括实现自定义序列化的能力，共享类型和支持原有网络服务的能力。对DataContractSerializer,XmlSerializer是WCF集成的一部分。这部分主要查看下XmlSerializer并讨论它如何用来控制XML输出。阅读全文
摘要: WCF支持两种消息处理模式: 缓冲和流模式。缓冲是WCF中处理消息的默认模式。在这个模式下，整个消息在发送和接收之前被放入内存中。在大多数场景，缓冲消息是重要的而且有时需要支持一些诸如可信赖消息和数字签名的特性。然而，缓冲大消息将很容易导致系统资源耗尽并限制可扩展性。WCF支持另外一种使用流处理消息的模式。在这个模式中，在客户端和服务端的数据使用一个System.IO.Stream.Streaming。流模式一般在一个绑定或一个传输信道上使用。阅读全文
摘要: 有时你可能需要完成一个不可序列化或者需要对序列化内容进行改变的序列化过程。一个例子是由第三方组件提供者提供或者一个你不再拥有源码的组件中的一个类型。阅读全文
摘要: 对支持面向服务的架构来说，数据契约版本化会随着时间推移称为面向服务的一个重要方面。随着时间推移，比如创建了新的服务，它生成了一个数据契约的新版本，通过添加额外的信息。而不是重编译所有之前使用老的数据契约版本的客户端和服务端，你可能希望它们可以平滑的升级以便于可以共享公共数据，这也正是DataContractSerializer 要做的事情。如果有额外的数据，DataContractSerializer 将会抛弃额外的信息。但这并不是在所有情况下都能正常工作。如果数据被接受后又发送回给客户端，忽略任何额外数据意味着可能会丢失信息。一个例子是一个新的客户端发送数据给一个将信息存储在一个数据库中以用来在未来的某个时刻访问的旧服务。在这种情况下，如果客户端发送给服务端过程中有任何额外信息，它将在数据发送回给客户端时丢失。这也是IExentsibleDataObject接口要解决的问题。它提供一个接口给不知道数据契约的外部数据。它通过将反序列化过程中的未知数据存储到一个ExtensibleDataObject类中实现的。阅读全文
摘要: WCF 中的默认序列化方法是DataContractSerializer. 这是WCF开发组想要大部分开发人员使用的序列化方法因为它强制进行契约共享而非类型共享。这是创建面向服务架构的一个原则。然而，如果你的想法是支持类型一致并在客户端和服务端间共享类型信息那么这个方法并不会为你的设计引入问题，你可以使用NetDataContractSerializer来序列化。就像在之前的”比较WCF序列化选项”章节描述的那样，NetDataContractSerializer与DataContractSerializer本质是类似的，但是额外支持了类型信息共享和引用保留。阅读全文
摘要: 循环引用是指一个对象维持对子对象的引用，子对象还会对其引用。关于循环引用的一个例子是一个子对象维持到父对象的父子关系。这些情况的类型在面向对象编程中很常用。对象维护循环引用的问题是序列化不可能没有对引用保留的支持。任何序列化结构将会在一个试着序列化对象的无终止循环中终止。引用保留允许对使用的数据添加一个引用而不是对数据反复序列化。阅读全文
摘要: DataContractJsonSerializer支持使用以JavaScript 对象标记作为序列化格式并添加到.NET 3.5 Framework 中。如果从一个使用JavaScript 的网络应用调用服务序列化会工作的很好，特别是ASP.NET AJAX 和Silverlight 网络应用。当使用WebScriptEnablingBehavior行为时会使用DataContractJsonSerializer。对应的，如果WebHttpBehavior行为配置成使用JSON编码也可以使用DataContractJsonSerializer。这些终结点行为指导WCF支持REST/POX 类型服务。你可以查看第十三章"可编程站点"来获得关于属性的信息。现在我们将查看如何直接使用DataContractJsonSerializer并与先前提到的其他序列化结构进行比较。阅读全文
摘要: XmlSerializer 是WCF中可以用来序列化的第三种方法。XmlSerializer 是已经被.NET2.0 架构内建支持的一个序列化方法。使用XmlSerializer有好几个优势，包括对已有.NET类型的支持，与ASP.NET Web 服务的兼容，和改变XML输出的能力。
WCF支持XmlSerializer以便于它可以与已有的类型一起使用，而DataContractSerializer是特别用于新类型的。对已有类型的支持通常是对已有的应用程序或者那些你没有源码或者你不能重编译的你应用程序来支持DataContract序列化的第三方组件。XmlSerializer也是使用ASP.NET Web 服务使用的序列化方法。这意味着XmlSerializer可以用来帮助将ASP.NET Web 服务转换到WCF中。最后， XmlSerializer对序列化XML的输出提供更多控制并可以用在那些DataContractSerializer不适合对序列化XML形状进行改变的场景中。阅读全文
摘要: NetDataContractSerializer是WCF中一个可以替代的序列化方法，它允许类型共享。这个类可以再System.Runtime.Serialization命名空间中找到。当类型必须在客户端和服务端保持正确时会使用这个序列化方法。NetDataContractSerializer通过对CLR类型添加额外信息并保存引用来支持类型精确。除了这个，在NetDataContractSerializer和DataContractSerializer之间没有任何不同。阅读全文
摘要: 使用WCF有很多种方式来序列化对象。确定使用哪种方法来序列化取决于一系列因素。这些因素包括你是否想要与契约共享类型，支持现有的.NET类型，保留引用以及更多。
DataContractSerializer
WCF中默认的序列化方法是DataContractSerializer.这个类存在于System.Runtime.Serialization命名空间里。DataContractSerializer是用来支持基于XSD元数据的契约共享的。它将公共语言运行时(CLR)类型映射成XSD定义的类型。这意味着XSD是可以用来在两个应用程序间交换数据的公共元数据。例如，你可以使用XSD在一个.NET应用程序和一个Java应用程序间交换数据。我们使用一个字符串来举个例子。阅读全文
摘要: 使用DataContract序列化器在客户端和服务端之间将CLR类型转换成基于标准的XML的序列化。然而有很多场景并不适合使用DataContract序列化器。这包括不支持DataContract序列化器的对已存在的CLR类型的序列化，原有的Web 服务，交互系统，代码合并(比如.NET Remoting)和数据形状。数据形状是指控制一个用来性能优化和契约优先开发的序列化成XML的.NET类型的过程。在这些情况下，了解如何使用WCF和.NET Framework提供的序列化工具是很重要的。
编码是另外一个与序列化相关的重要主题。WCF在对象序列化和将消息转换成可以使用一个传输协议发送的字节间做了很多区别。阅读全文
摘要: 行为是WCF架构中一个重要的扩展点。它们在客户端或者服务端运行时(runtime)被构造时以及每个服务调用时使用。当运行时启动时，它通过检测传递给ClientChannel的类型结构或者ServiceHost来寻找行为，然后在配置文件中寻找。行为也可以在代码中和在打开ServiceHost之前添加到ServiceDescription 对象中定义，或者通过在代码中使用属性，或者在配置文件中。阅读全文
摘要: 实现了对在服务端配置中安装的软件授权码的一个验证行为。如果它不存在或者它不合法，服务将不会启动。它显示了服务运行时创建的用来验证配置信息的一个终结点行为。它也显示了当服务运行时创建时调用的一个行为扩展和扩展是如何将行为加入到服务运行时的。结果就是一个自定义行为在配置文件中(app.config 或者web.config)使用并被添加到服务运行时中以便于配置信息可以在服务启动时被验证。阅读全文
摘要: 有一些重要的用来处理安全的行为。这些会在第八章”安全”中讲述，但是理解他们作为行为的作用是很值得的。
ServiceCredentials 行为是一个用来确定一个服务的认证的服务行为。这个类对访问客户端安全信息是有用的，比如用户的Windows验证设置和客户端证书。它以一个行为的形式实现以便于它可以按照它们的安全信息检测进入的消息。阅读全文
摘要: 类myParameterInspector实现了IParemeterInspector接口。类存储了两个本地属性，_pattern和_message,用来在BeforeCall方法中验证参数。在那个方法中，使用正则表达式来匹配参数值和参数pattern.如果值与pattern不符合，会抛出一个错误。阅读全文
摘要: 实际应用时，如果你需要为诊断的目的实现一个消息检测器，请查看第十章”异常处理”以获得跟踪技术。
myMessageInspector 类实现了IDispatchMessageInspector接口。在它的BeforeSendRequest和AfterReceiveReply方法中它把消息打印到控制台。类myEndpointBehavior实现了IEndpointBehavior接口。在它的AddDispatchBehavior方法中它把myMessageInspector类添加到消息检测器列表中以便于可以被每一条消息调用。最后，主程序将myEndpointBehavior类添加到所有终结点的行为列表中。注意因为服务也有一个MEX终结点，对终结点的请求和回复也会被myEndpointBehavior打印出来。阅读全文
摘要: 自定义行为可以在WCF创建运行时和消息处理管道时让你在重要的地方插入代码。行为可以添加到代码中，通过属性或配置文件手动实现服务描述。在所有的情况中，代码可以做一些辅助动作，比如在一个目录中寻找信息或者为了审计的目的记录数据。阅读全文
摘要: 定义在操作层的行为TransactionScopeRequired和TransactionAutoComplete。在服务层，有两个额外的行为需要考虑: TransactionIsolationLevel和TransactionTimeout.阅读全文
摘要: 事务管理器负责协调多个部分间的工作并通过资源管理器提交工作。资源管理器负责处理可信赖，持续存储。取决于使用的资源和服务或应用跨越的边界，WCF将使用三个事务管理器中的一个来完成事务处理。轻量级事务管理器(LTM)用来在一个应用程序域中管理资源。核心事务管理器(KTM),仅仅存在于Vista 和Windows Server 2008 系统中，用来管理文件系统和注册表资源的事务。分布式事务管理器(DTC)用来管理跨程序，进程或者机器边界的事务。应用程序不控制具体使用哪一个事务管理器；WCF将会选择最合适的事务管理器并在没有应用程序干预的情况下按需要逐步扩大。阅读全文
摘要: 当在分布式系统中工作时，事务有时必须要跨越服务边界。例如，如果一个服务管理客户信息而另一个服务管理订单，一个客户提交一个订单并想产品可以发送到一个新的地址，系统将需要调用每个服务上的操作。如果事务完成，用户将会期待两个系统上的信息都被合适的更新。
如果基础架构支持一个原子事务协议，服务可以像刚才描述的那样被组合到一个复合事务中。WS-AT(网络服务原子事务)提供在参与的服务间共享信息的平台来实现ACID事务必须的两步语义提交。在WCF中，在服务边界间的流事务信息被称作事务流。阅读全文
摘要: 为了在WCF中实现这个行为，服务操作必须使用[OperationBehavior(TransactionScopedRequired=true)]属性来标记为是可事务化的。这指导WCF创建一个新的事务并在将控制权给那个方法前把执行线程入列。如果操作在它完成前失败了，所有在事务中进行的对事务资源的部分更新都将被回滚。阅读全文
摘要: 有两个场景一般用作事务的参考。多步骤商业过程是典型跨度分，天，月的长时间运行过程。它们可以涉及多个组织和基于人的工作流。短期运行事务是那些在几秒钟完成并很少有外部依赖的商业操作。尽管它们都有定义的很好的接口和确定的工作流，它们是根本不同的事物。WCF支持短期运行的事务。它通过借助.NET和Windows基础结构来实现运行在只有微软环境平台的事务同时通过使用WS-*标准事务来支持跨平台。阅读全文
摘要: 既然是面向服务，那么如何定义服务，如何提供服务，如何寻找服务，如何使用服务呢？ WCF 主要关注如何如何提供服务，如何使用服务，而服务一般都不在本地，但你可以知道服务的地址(WCF),也可以不知道服务的地址(云)，而WCF就是为了让分布式服务对开发人员就像本地服务一样，负责处理了通信，编码，安全，可信赖，事务等具体事宜。通信，编码，安全和事务不是我们本篇要讨论的内容，这里我们主要讨论一下可信赖消息。阅读全文
摘要: 一个服务的ABCs-它的地址，绑定和契约-是以元数据的形式表示的以便于潜在的客户端知道到哪里，该如何与谁去通信。信息统称为服务元数据。服务行为元数据是大多数程序员遇到的第一个行为，因为当你创建WCF工程时它被引用于由Visual Studio 2008生成的配置文件里。这个行为与一个元数据终结点一起工作以便于元数据可以被客户端访问。阅读全文
摘要: 当InstancingMode被设置成PerSession时，WCF为每个连接到服务端的会话创建一个实例。为了控制连接到一个服务端的会话数量，可以使用maxConcurrentSessions行为。当达到最大值时，下一个客户端尝试创建的会话将会阻塞直到另外一个会话关闭。这个设置对限制可以连接到服务端的用户(或客户端或服务器端)的数目是很有用的。阅读全文
摘要: 当InstancingMode设置成Single时，WCF在宿主内创建一个单一的实例，不考虑有多少客户端被创建。当ConcurrencyMode设置成Multiple时，WCF为每个请求创建一个线程(取决于系统上限)以实现服务方法的并行执行。为了减少这个，maxConcurrentCalls行为控制有多少个并发调用可以激活。阅读全文
摘要: 默认情况下，WCF 宿主将会启动尽可能多的实例来处理请求消息。如果一个服务的实例和并发行为并没有确定，WCF将会为每个进入的请求创建一个服务实例同时将按照需要分配线程来反应请求。总体来说这是一个对性能和扩展性都很好的解决方案因为服务将会最大化扩展硬件性能。
但是有很多情况你可能想舍弃使用这种行为。为了这个目的，有三种在并发和实例上的设置可以实现。这些定义在配置文件的行为组分的serviceThrottling元素里。
maxConcurrentInstances行为控制有多少个服务实例可以被一个服务创建。这个设置是有用的如果ConcurrencyMode是PerCall或者PerSession,因为这两个设置都可以指导WCF按照要求创建实例。通过定义WCF可以创建的实例的最大数目，你设置的实例数目的上限将会存储在内存中。当限制达到时，不会有更多的实例被创建除非其他实例被回收或重用。阅读全文
摘要: 会话在分布式应用程序中广泛用于维护每个用户的状态。在站点或者基于站点的应用中，将每个用户的状态存储于会话中很常见。这这些情况中，用户和会话间有一个1:1比例。WCF以一个类似的概念支持服务。使用InstanceContextMode.PerSession设置，WCF可以直接为每个会话创建一个服务实例。阅读全文
摘要: 有很多情形需要一个服务对应一个服务实例，而且实例仅可以运行一个线程。任务应该严格的按照FIFO(先进先出)顺序执行，没有并发。尽管这个严重降低吞吐量，这有利于那些状态在所有调用者间共享且它们没有足够的锁定机制存在的场景。
为了创建一个仅有一个单一线程的单一服务实例，InstanceContextMode.Single 应该与ConcurrencyMode.Single一起使用。InstanceContextMode.Single设置意味着仅有一个实例应该被创建，而ConcurrencyMode.Single设置指导WCF在某一时刻只能在一个线程中执行一个实例。这些设置指导WCF按照FIFO(先进先出)顺序分发请求。阅读全文
摘要: 默认的InstanceContextMode行为设置指导WCF为每个请求创建一个新的服务实例。然后在很多情况下，这不是最好的解决方案。例如，如果一个服务有一个代价很高的例行初始化(比如，一个构造器从一个数据库读取数据或者创建一个大的内存结构)，它对每个服务请求的实例创建都不是很高效。为了创建一个被当前线程共享的单一服务实例，InstanceContextMode.Single应该与ConcurrencyMode.Multiple结合使用。InstanceContextMode.Single意味着只能有一个实例被创建，而ConcurrencyMode.Multiple设置指导WCF在那个实例中同时执行多个线程。这可以提供一个重要的扩展性改进，但是服务代码必须处理同步来保护TLS(本地线程空间)。阅读全文
摘要: ConcurrencyMode.Single和InstanceContextMode.PerSession.当使用这些设置和一个不支持会话的绑定时，比如basicHttpBinding,WCF创建为每个它接收到的请求创建一个新的服务实例并在它自己的线程里执行代码阅读全文
摘要: 并发是一个多少个任务可以同时执行的度量，以任务(请求，工作，事务，以及类似的)的形式度量。执行时间是一个任务多长时间完成的度量，以时间(毫秒，秒，其他的时间单位等)度量。吞吐量是在一个指定时间里可以完成多少个任务的度量，以任务/时间(请求/秒， 事务/分，等等)的形式度量。吞吐量是关于并发和执行时间的函数。
有两种方式来增加吞吐量:减少执行时间或者增加并发量。减少一个独立任务的执行时间可以通过改变任务调度间隔算法或者添加额外的硬件资源，所以WCF对这些都无能为力。并发可以通过并行执行任务来实现。WCF有两种控制并发的行为: InstanceContextMode 和 ConcurrencyMode.阅读全文
摘要: 行为是WCF影响运行时操作的类。行为作为WCF运行时被调用，在客户端和服务端运行并作为消息在两者之间流转。因为行为运行在这些重要的时间，它们被用来实现很多WCF的内建特性。它们也是一个重要的自定义扩展点。
例如，ServiceHost用来定义一个服务端的实例和并发方面，另外也分发消息给适当的操作。当一条消息被一个服务接收到并分发给一个类的特定方法时，ServiceHost应该为每次请求创建一个类的实例还是重用实例？但ServiceHost调用类的方法时，它需要加入到一个事务的列表中吗？这些都在行为中定义并且在初始化中使用。阅读全文
摘要: 信道架构把一系列分布式编程技术统一为一个单独的编码模型。这个架构允许服务独立于传输协议和编码协议而创建，因此支持多种通信形式。绑定是支持特殊通信类型的预先设置好的信道栈。WCF提供9种预定义绑定。阅读全文
摘要: 通过在一个服务中使用多个终结点，你可以配置一个服务通过多个绑定暴露它的能力，这就像在第二章”一个服务中的多个契约和终结点”描述的那样。这意味着客户端可以使用更多被支持的可选绑定来连接到服务端。通用的场景是使用netTcpBinding绑定把一个服务暴露给一个.NET应用程序，使用wsHttpBinding绑定把同样的服务暴露给一个Java应用程序，使用basicHttpBinding绑定再次把服务暴露给原有的旧的客户端。阅读全文
摘要: WCF在预设绑定中提供了很多信道和编码器。这些信道提供了在自定义绑定中使用的绑定元素。这一部分提供WCF内部绑定元素列表以及它们的使用方面。传输信道存在于TCP,HTTP,命名管道，HTTP(SSL/TSL加密)，MSMQ和对等网络。阅读全文
摘要: 有很多时候预先设置好的绑定不满足你的服务的需求。一般的场景包含了自定义安全和额外传输协议，都不被WCF支持。一个例子是WCF中不支持UDP协议。对UDP协议的支持是以Windows SDK 中的例子来实现的。考虑到这些情况所以WCF提供了创建自定义绑定的能力。自定义绑定可以由代码或配置文件创建。一个自定义绑定的代码使用System.ServiceModel.Channels命名空间中的CustomBinding 类来生成。这个类暴露了一个你可以添加绑定元素的绑定元素集合。这允许你构造一个基于一系列现有绑定元素的新的绑定。阅读全文
摘要: msmqIntegrationBinding 绑定用来在一个WCF应用程序和一个直接利用MSMQ的应用程序间通信-比如，使用System.Messaging.这允许开发人员利用WCF同时也使用他们已有的MSMQ应用程序。msmqIntegrationBinding绑定允许MSMQ消息映射到WCF消息。这通过在MsmqMessage类中对MSMQ消息包装来实现的。类位于System.ServiceModel.MsmqIntegration命名空间里。实例可以使用单向契约被发送或接收。阅读全文
摘要: MSMQ 为使用队列创建分布式应用程序提供支持。WCF支持将MSMQ队列作为netMsmqBinding绑定的底层传输协议的通信。netMsmqBinding绑定允许客户端直接把消息提交到一个队列中同时服务端从队列中读取消息。客户端和服务端之间没有直接通信过程；因此，通信本质是断开的。也意外着所有的通信必须是单向的。因此，所有的操作必须要在操作契约上设置IsOneWay=true属性阅读全文
摘要: WCF使用微软消息队列(MSMQ)来提供基于队列的通信能力。有两个使用MSMQ的绑定: netMsmqBinding和msmqIntegrationBinding. netMsmqBinding绑定一般在创建以WCF和MSMQ作为传输方式的应用程序时使用。msmqIntegrationBinding绑定用来于一个已有的MSMQ应用程序进行交互。阅读全文
摘要: 开发人员需要知道绑定的性能和可扩展性特点。当你在与现实中的应用程序打交道时，性能和可扩展性对服务层次的协议和用户体验很重要。用户会对性能表现差的应用抱怨。应用通常不扩展意味着商业对象的需求没有被满足。服务在四个不同的绑定上暴露出来: netNamedPipeBinding, netTcpBinding, wsHttpBinding和basicHttpBinding.一个测试客户端依次调用Get256Bytes操作50,000次来比较绑定间的不同。阅读全文
摘要: wsDualHttpBinding绑定类似于wsHttpBinding绑定，它额外支持双向通信但不支持传输级别的安全。双向通信通过两个形状改变绑定元素完成: OneWayBindingElement和CompositeDuplexBindingElement绑定元素。CompositeDuplexBindingElement绑定元素在两个单向信道上加了一个双向通信信道。wsDualHttpBinding绑定使用HttpTransportBindingElement绑定元素。这是传输仅支持请求-回复消息交换模式。OneWayBindingElement 绑定元素允许HttpTransportBindingElement绑定元素与CompositeDuplexBindingElement绑定元素一起使用。
wsDualHttpBinding绑定不支持传输层次的安全。这意味着在使用wsDualHttpBinding绑定时不可以使用SSL/TLS加密。阅读全文
摘要: .NET Framework 3.5 介绍了一种用于Web 服务交互称为ws2007HttpBinding绑定的新的绑定。这个绑定类似于ws2007HttpBinding绑定除了它支持最新的WS-* 消息，安全，可信赖消息和事务标准。阅读全文
摘要: 对WS-* 标准的支持一直贯穿于WCF架构中。wsHttpBinding绑定是这个支持的一个例子。这个绑定提供了在异构平台上交互通信的能力同时提供了高级架构级别的协议，比如安全，可信赖消息和事务。wsHttpBinding绑定是.NET Framework 3.0 的默认绑定，当你需要基于网络服务的交互通信时。阅读全文
摘要: Web 服务时异构系统之间进行通信的基础。高级Web 服务是那些使用WS-*规格(显著的WS-星号)的Web 服务。WCF已经支持WS-*标准，包括安全，可信赖消息和事务。阅读全文
摘要: Web 服务时异构系统间相互通信的基础。比如，基于JAVA平台创建的IBM Websphere或者BEA WebLogic服务必须与基于.NET 平台创建的客户端和服务端进行无缝连接。基于.NET平台创建的服务必须与基于JAVA平台创建的客户端和服务端进行无缝连接。在WCF出现之前，ASP.NET Web 服务(ASMX)和高级Web 服务在.NET平台上提供了这种能力。在.NET 3.0时，WCF直接取代了这些技术并提供了一个单独的统一的架构来创建Web 服务。WCF包括了很多种暴露交互式Web 服务的绑定，包括basicHttpBinding, wsHttpBinding, wsDualHttpBinding和wsFederationHttpBinding绑定。阅读全文
摘要: 进程间，跨进程，通信就是在同一台机器上的两个独立进程间的通信。进程内，或者在进程中，通信就是在一个进程内两个软件模块的通信。这些通信类型一起组成了我们所称的本机通信。
应用程序域是通过进一步对一个Windows进程拆分并将多个.NET应用程序在安全性和活动范围层次进行隔离的.NET中的架构。这意味着应用程序域是另一个可以被.NET程序跨越的边界。因为这些我们定义了两个额外的名词: 应用程序域间和内部应用程序域。
应用程序域间或者跨应用程序域。在同一个Windows进程内运行的独立应用程序域是两个.NET应用程序进行通信的场所。也可以在一个单独的设计可以运行多个应用程序域的.NET应用程序中进行通信。阅读全文
摘要: WCF把所有在.NET应用程序之间使用的绑定加上”net”前缀。绑定名字的前缀是一个暗示，让我们知道应该选择一个特定的绑定来使用。这意味着这些绑定有特殊的仅能用于.NET应用程序的特性。相反的，所有以”ws”为前缀的绑定意味着使用Web Services的非.NET应用程序。阅读全文
摘要: WCF 第四章 绑定 选择一个合适的绑定
2011-06-26 19:40 by DanielWise, 32 visits, 收藏, 编辑
WCF中有9个预设绑定。这些绑定中的每一个都满足一个特殊分布式计算的需求。很多因素决定了为一个特殊应用选择哪一个绑定，包括安全，互通性，可信赖，性能和事务需求。阅读全文
摘要: 信道栈是一个由一个或多个信道组成用来处理消息的层次通信栈。绑定是预先设置的信道栈。它们代表了在客户端和服务端之间的线上契约。每个绑定由通信中涉及的传输，编码和协议确定。WCF使用绑定为多样化通信场景集合配置信息。最普通的通信场景，比如网络服务，REST/POX 服务和基于队列的应用都在盒子外面提供。例如，basicHttpBinding绑定意味着使用基于ASP.NET Web Services的服务或者与WS-I 基础协议1.1 相适应的服务。ws2007HttpBinding 和wsHttpBinding 绑定类似于basicHttpBinding绑定，但是它们支持更多的特性，比如可信赖消息和事务，而且使用新的标准WS-Addressing. ws2007HttpBinding 绑定继承自.NET 3.5而且比wsHttpBinding基于更新的标准。阅读全文
摘要: 信道栈是由一个或者多个信道组成用来处理消息的分层通信栈。信道可以是协议信道或者传输信道。传输信道位于信道栈的最底层用来在一个传输协议(比如，HTTP,TCP,MSMQ)上传输消息。协议信道(又名层次信道)通转发和修改消息来实现协议(安全，可信赖消息，事务，等等)。阅读全文
摘要: ICommunicationObject 接口(查看列表3.8)是WCF中所有通信对象(信道，信道工厂，信道监听器，等等)的基础。打算创建自定义信道或者直接使用信道的开发人员需要了解这个接口。WCF中的通信对象需要实现一个特殊的状态机。状态机表示了所有通信对象的状态变化。这种情况就像其他通信对象(比如，套接字)所处理的那样。ICommunicationObject接口(还有与它相关联的方法，状态和事件)的目的是为了实现状态机。这允许WCF能够将按同样的方式处理通信对象，并让他们下层实现与抽象层分离。阅读全文
摘要: 信道通过信道形状来完成它们所支持的多种类型消息交换模式。比如，一个基于Tcp的传输信道将会实现IInputChannel和IOutputChannel,因为这些通道都是固有单向的。其他的传输信道基于其他协议比如TCP可能需要实现多个信道形状。开发人员不直接与信道形状打交道。对应的，WCF选择一个服务的基于OperationContract的信道形状。阅读全文
摘要: WCF支持不同的消息交换模式:单向，双工和请求-回复。为了实现每种方式，WCF提供了10种不同的称作信道形状的接口。其中五个形状称作IOutputChannel, IInputChannel, IDuplexChannel, IRequestChannel和IReplyChannel.每个形状都有一个等效的支持会话的形状。它们包括IOutputSessionChannel, IInputSessionChannel, IDuplexSessionChannel, IRequestSessionChannel和IReplySessionChannel.这些接口在一个信道栈中实现了不同的消息交换模式。在这一部分，我们将查看每一个通信模式以及与它们关联的多种接口。阅读全文
摘要: 信道就是WCF应用程序接收和发送所有信息的通道。它负责在一个持续的方式中准备并传输消息。信道是为传输，协议和消息交换定义的。信道被放到一起来创建信道栈。信道栈是处理消息的分层通信栈。比如，一个信道栈可以由一个TCP传输信道和一个事务协议信道组成。这样的一个信道栈允许使用在网络中的客户端和服务端之间使用TCP协议和事务流转来发送/接收消息。阅读全文
摘要: WCF高度利用SOAP于契约定义中。特别的，它使用WSDL来描述服务终结点，使用XSD来描述数据。定义在WSDL中的服务操作用来在运行时把收到的请求转发给正确的.NET类。类似的，通过XSD契约定义的XML文件在运行时被反序列化成.NET类型而且发送给服务操作。合二为一，WSDL和XSD定义提供了对服务实现中的.NET类型一种基于标准的实现。三种类型的契约的详细定义:
服务契约。服务契约描述了由服务实现的功能性操作。
数据契约。数据契约描述了服务通信所依赖的数据结构。一个数据契约把CLR类型序列化成XML并严格选择它们的数据成员。
消息契约。消息契约与类型化和非类型化数据且提供了对SOAP消息头和消息体的精确控制。阅读全文
摘要: 消息契约描述了发送给一个服务以及从一个服务接收的SOAP消息的结构，并且允许你检测和控制SOAP消息头和消息体中大部分细节。而且数据契约能够让使用XML元数据定义(XSD)标准的系统之间互通，消息契约能够让任何通过SOAP通信的系统互通。
使用消息契约能够通过直接访问SOAP消息头和消息体提供对发送给一个服务以及从一个服务接收的SOAP消息的完全控制。这允许使用简单或复杂的类型来定义SOAP部分的精确内容。就好比当你需要对数据序列化的完全控制时你可以从DataContractSerializer转换到XmlSerializer，当你需要对SOAP消息完全控制时你可以从DataContracts转换到MessageContracts.阅读全文
摘要: 如果你在使用WCF暴露服务而且使用svcutil.exe来为创建访问服务代码，一般情况下你不需要关心在客户端和服务端间传输的消息的线上表示。数据契约知道WCF把一个.NET类型序列化成一个XML信息集和讲一个XML信息集反序列化成一个.NET类型。XML信息集可能在线上以文件或者二进制形式编码，这些取决于通信过程中所使用的绑定，但是再次，.NET代码不会意识到编码的存在。这种方式就好比你在代码中使用.NET类型但是一个基于标准的XML信息集的编码表示在线上具体传输。阅读全文
摘要: 变化是不可避免的。企业改变，技术改变，法律改变，软件契约也会改变。在面对软件的变更时，一个坚实的版本控制是必须的。我们必须为不可避免的变化做好提前准备同时对已经存在的客户端进行向后兼容处理。
对数据契约版本控制来说，最常见的需求是想已有的数据契约中添加成员。通过这一部分描述的不间断的描述，你可以自由的做任何改动而不会破坏现有客户端。但是如果你需要打破现有客户端的向后兼容性，你必须通过改变数据契约的名字或者命名空间来定义另一个版本的数据契约。
一个小的注意是要注意不间断的变化。不间断，从WCF的标准来看，可能会打破与其他系统的兼容性。例如，如果与一个要求元数据验证的系统通信，系统可能会拒绝消息如果接收到的XML实例中有不可预期的元素。这一章中提到的不间断周期是指那些不会影响WCF到WCF通信的改变。阅读全文
摘要: 如果数据类型满足任何先前描述的条件，那么它们会在WSDL中暴露出来。有一些额外的可能，当然，你也可能想强制一个类型包含在WSDL契约中。
举一个类继承的例子。如果一个序列化的派生类到达一个期待得到一个序列化的基类的终结点时，WCF不会知道如何反序列化这个派生类因为它不是契约的一部分。另外一个例子是一个hashtable 类，存储了其他的类作为自己的元素。WSDl将会定义hashtable类，但是不是那么存储在hashtable内部的类。
在这些情况下，你必须告诉WCF这些应该显示包含在WSDL契约中的类。这是使用KnownTypes完成的。它可以在四种方式下完成:通过添加一个KnownType属性到[DataContract],通过在[ServiceContract]或者[OperationContract]的属性，通过在配置文件中添加一个引用给它以及它的程序集，或者通过在生成WSDL时定义它。阅读全文
摘要: 复杂类型一般在代码中以类的形式实现。复杂类更进一步通过增加特殊结构的继承关系来定义。这种方式，一个通用类型比如”price” 可以派生出为一个更加特殊的类型如”stock price” 或者 “house price”.WCF支持通过在WSDL中合适的表示的类的继承关系，在类结构和XML之间序列化和反序列化它们同时从每个类中取出属性并加入到一个集合中。阅读全文
摘要: 在一个服务内部，功能性的应用由代码实现的。在服务外部， 功能性服务在WSDL中定义。在一个WCF服务中，应用程序数据在简单和复杂类型表示；而在服务外部，应用程序数据由XML元数据定义表示。WCF数据契约提供了对代码定义的.NET CLR类型与W3C组织定义用来在服务外部通信的XML元数据定义之间的映射。阅读全文
摘要: WCF 根据服务端源代码中定义的内部类名称和属性来生成外部暴露服务实现。这些实现通过服务中的MEX终结点暴露出来并在设计阶段时被客户端以WSDL形式使用。接下来在客户端，WSDL会被用来写一些代码来建立可以与服务端通信的适当的消息格式。所以你选择的类，方法和参数的名字与服务范围潜在相差很远。
然而，在服务的接口暴露内部名字和外部细节是很不好的形式。比如，你可能有一个叫BurgerMaster的分配算法，你想在外部以Resources名字暴露这个算法。或者可能有内部的编码标准要求你应该命名接口。幸运的是，你可以通过修改[ServiceContract]，[OperationContract], [ServiceBehavior]来控制所有服务暴露的名字。阅读全文
摘要: 一个服务作为一系列终结点被定义的。每个终结点都有一个地址，绑定和契约。契约就是暴露终结点能力的。地址就是这些应用或服务从网络的哪个地址可找到，契约是关于如何访问他们的。
在终结点和契约间有一对多的关系。一个终结点可以只有一个契约，但是一个契约可以被很多终结点引用。尽管一个终结点可以仅仅确认一个契约，接口聚合使能一个单独的契约来暴露多个接口。另外，多个有同样绑定但是不同契约的终结点可以位于同一个地址，给一个单独终结点实现所有契约的假象。阅读全文
摘要: 为了参与到一个双工消息交换模式中，客户端必须实现WCF的ABCs-必须在客户端定义服务要把消息发送到的地址，指导服务端如何把消息发送给客户端的绑定，定义消息内容和格式的契约。幸运的是，当你生成一个客户端代理而且在运行时使用信道结构时，WCF很大程度上考虑到了这些。阅读全文
摘要: 一个双向契约包含服务终结点和客户端终结点的接口实现。在契约类型中，服务端契约在客户端实现。阅读全文
摘要: 你可以通过两个不同消息交换模式来解决双向通信问题。你可以使用两个单向契约，或者你可以使用一个双工契约。阅读全文
摘要: 请求-回复通信是客户端与服务端最普遍的消息交换模式。通信在客户端被初始化，客户端发送一个请求消息给服务端，然后服务端发送一个返回消息给客户端。如果返回消息很快，那么通信过程可以是同步的，所以客户端应用程序阻塞等待反馈。如果请求和回复之间会有延时，请求-回复模式可以在客户端使用标准.NET技术实现异步调用。在那种情况下，WCF会在发送请求给服务端后立即把控制返回给客户端应用程序。当服务接收到反馈以后，一个.NET回调方法被调用来完成WCF回复。阅读全文
摘要: 当一个客户端需要向一个服务端发送消息但是不接受返回消息时，但不消息交换模式很有用。使用这个模式，客户端只需要消息成功传递的确认；它不需要服务端返回一个精确的消息。有时单步模式被错误的称作"发后不理"。在实际应用中，它是"发送和理解"因为调用者接收到一个消息成功提交到通信信道的确认。阅读全文
摘要: 好的设计会降低用户必须等待一个任务结束然后初始化另一个任务之前的情况。例如，当一个e-mail客户端正在下载新邮件，你仍然可以读或者删除已经下载下来的邮件。或者当一个浏览器正在下载一个网页上引用的图片时，你仍然可以拖动网页或者跳转到任何地方。在客户端程序中的多任务形式是通过异步设计模式来完成的。阅读全文
摘要: WCF使得在客户端和服务端进行请求-回复通信非常容易。在设计阶段，你使用添加服务引用或者svcutil.exe来调用服务元数据终结点而且生成一个客户端代理来模仿服务操作的签名。这允许客户端代码像本地函数调用一样调用代理上的方法。代理把方法名字和参数序列化成一个SOAP消息，然后发送SOAP消息到服务端，然后创建一个.NET类型来表示从服务返回的回复消息。
列表2.1显示一个服务契约定义。一个服务契约和一个操作契约被定义到代码中。操作契约代表一个可以被客户端调用的方法，或者更准确一些的说，一条消息可以被客户端发送并被服务端理解。注意契约在接口中定义，而不是类定义。阅读全文
摘要: WCF在设计时和运行时使用服务契约。在设计阶段，它们确定应该在WSDL理暴露为终结点的代码的类。一个使用[ServiceContract]标记的类和使用[OperationContract]标记的类中方法在WSDL中暴露以便于它们可以被客户端访问。类以wsdl:service确定，操作以wsdl:operation确定。在运行时，当WCF分开器接收到消息时，它查看wsdl:operation 的名字来确定类中的以[OperationContract]标记的哪个方法需要接受反序列化消息。阅读全文
摘要: 在原子和金钱世界中，契约是两个或多个组织以一个已知的价格提供商品和服务的合同。在比特和服务的世界中，契约有类似的功能:它是两个或多个组织之间确定消息交换和消息条款及条件的合同。
契约是由服务终结点发送或接收的消息的描述。每一个终结点都由ABCs定义:一个消息发送到的网络上的地址，一个描述消息如何发送的绑定，一个描述消息格式的契约。阅读全文
摘要: 在这一章，我们主要讲述WCF的基础内容，简洁的描述了ABCs.一个服务暴露终结点，每个终结点都有ABCs:地址，绑定和契约。服务也有描述它们的操作语义的行为，比如多线程和同步，但是这些将会在接下来的章节里讲述。阅读全文
摘要: 就像调用一个WCF服务，你可以使用添加服务引用(ASR)或者Svcutil.exe来创建代理类和配置文件来调用ASMX服务操作。在这些被创 建以后，客户端通过实例化代理调用方法来与ASMX网络服务通信。同样的，你可以使用添加网络服务引用(AWR)或者wsdl.exe 来生成代理类和配置文件。然后在实例被创建以后，客户端在代理上调用方法来和服务通信。阅读全文
摘要: 一个WCF服务可以在操作系统中运行的任何托管进程中寄宿。服务本身一般并不知道或者关心它是怎么被寄宿的，尽管它可以通过丰富的APIs来找 出来。它可以寄宿到一个不被注意的随机器初始化时启动随机器关闭时关掉的Windows 服务上，或者在一个最小化到Windows系统托盘的客户端应用程序。最普通的用法，就是在IIS里托管一个WCF服务。阅读全文
摘要: WCF中的元数据是精确描述如何与服务通信的消息。客户端可以向一个运行的服务请求元数据来了解它们要求的终结点和消息格式。在设计时，客户端发送由 WS-MetadataExchange 标准定义的消息并接收返回的WSDL。WSDL可以被客户端用来定义一个将要用来在运行时与服务通信的代理类和配置文件。图片1.4显示了这个交流过程。阅读全文
摘要: 当需要和服务通信时WCF为客户端提供了丰富的API。通过Service.ServiceModel实现的API处理将.NET类型转换成 XML然后从客户端向服务端发送消息。你可以直接用API编程，或者你可以使用工具生成一个代理类和配置文件。在这一部分，我们将首先说明如何使用代码直 接调用服务，然后我们将使用工具实现这个过程。前一种方法使用较少的代码并不使用配置文件。后一种方式有更少的依赖性而且在调用时有更好的微控性。每种解 决方案都有很多最佳适用情况。阅读全文
摘要: 服务控制文件web.config 或是 app.config 依赖于服务是如何被寄宿的，它们必须包含一个节点。在这个节点下，服务，绑定，行为，客户端，诊 断，扩展，寄宿环境和COM+互操作都可以被特殊设置。最低限度必须有一个节点用来包含终结点，也至少有一个非基础架构 的节点在节点下面。在节点内，ABCs会被定义在每 一个终结点上。阅读全文
摘要: WCF为在配置文件中定义服务属性提供了丰富的支持。你仍然需要为你将要在服务中暴露的特性或者算法编码，但是终结点地址，绑定和行为可以从代码中移动到配置文件中。阅读全文
摘要: 完成一个WCF服务，你要完成一个.NET 类然后使用System.ServiceModel 属性来修饰这个类。System.ServiceModel 命名空间与.NET 3.0 一起安装而且包含了大多数WCF实现。当代码编译时，CLR(公共语言运行库)解释这些属性，使用运行时代码取代它们。对于.NET来说属性并不是新事 物; 在.NET 1.0 时它们已经存在了。WCF，就像.NET 1.0,1.1和2.0 中的ASMX，当写服务时使用属性来提高我们的生产力。阅读全文
摘要: 在一个高的等级里，写一个WCF服务就像写其他服务一样，不考虑内部实现。你首先要写一些代码来实现一个功能；然后你在一个操作系统进程中运行这些代码， 这个进程监听请求回复。WCF将这些步骤正式化而且使程序员能够更加容易的处理每一个节点。比如，使用系统提供的绑定和编码器，WCF 服务将可以与标准的SOAP消息通信。默认情况下，多线程，并发和实时也可以很好的实现而且有可预见的行为。阅读全文
摘要: 微软通信基础是关于服务的。主要是指创建，寄宿，使用以及安全性。WCF是基于标准和互通性的。可以提高开发人员的生产力。简短的说，WCF就是让每一个专业软件开发人员能够使用分布式计算服务。阅读全文