WCF后续之旅(2) 如何对Channel Layer进行扩展——创建自定义Channel

在上一篇文章中,我们通过一个直接借助BasicHttpBinding对象实现Client和Server端进行通信的例子,对WCF channel layer进行了一个大致上的介绍。由此引出了一些列通信相关的概念和对象,比如Channel,Output channel, Input channel,Request channel, Reply Channel,Duplex channel, Channel Shape,Channel manager,Channel factory, Channel listener, Binding element 等。通过这些元素,我们很容易地实现对WCF channel layer进行扩展。

对channel layer进行扩展一般适用于当你的需求通过现有的Binding,或者channel不能实现,而需要自定义一些channel来实现你所需的功能。不如现在的WCF系统定义的Channel中没有实现对Message body的压缩功能。你可以就需要将此功能定义到一个custom channel中,然后将其注入到channel stack中。一般来说,仅仅创建custom channel是不够的,因为在runtime, channel是通过Channel manager进行创建的,所以你需要创建对应的Channel factory(如何对发送方进行扩展)或者Channel listener(如果对接受方进行扩展)。而Channel factory和channel listener最终又是通过Binding element进行创建的,所以你还需要创建相应的Binding element。(Binding element=〉Channel factory&Channel listener=>Channel)

在本章节中,我们将继续讨论WCF channel layer。我们将通过如何创建和应用custom channel来介绍channel layer一些知识。

1、ICommunicationObject 和 CommunicationObject

我们知道WCF channel layer的绝大部分对象,比如Channel,Channel factory,Channel listener,从功能上讲都是用于通信(Communication)的对象,对传统的communication object,比如socket,他们往往都具有通过状态和状态转化规则(状态机:State machine)。这些状态包括Creating、Created、Opening、Opened、Closing、Closed等等。为了统一管理这些状态和状态之间的转化,WCF定义个一个特殊的Interface:ICommunicationObject

public interface ICommunicationObject
{
  // Events
  event EventHandler Closed;
  event EventHandler Closing;
  event EventHandler Faulted;
  event EventHandler Opened;
  event EventHandler Opening;

  // Methods
  void Abort();
  IAsyncResult BeginClose(AsyncCallback callback, object state);
  IAsyncResult BeginClose(TimeSpan timeout, AsyncCallback callback, object state);
  IAsyncResult BeginOpen(AsyncCallback callback, object state);
  IAsyncResult BeginOpen(TimeSpan timeout, AsyncCallback callback, object state);
  void Close();
  void Close(TimeSpan timeout);
  void EndClose(IAsyncResult result);
  void EndOpen(IAsyncResult result);
  void Open();
  void Open(TimeSpan timeout);

  // Properties
  CommunicationState State { get; }
}

ICommunicationObject定义了3种成员:

Property:State, 得到当前的状态,返回值是一个CommunicationState 枚举。

Method:同步、异步Open和Close方法。

Event:通过注册这些状态相关的Event,当时对象转化到对应的状态时执行相应操作。

WCF定义了一个abstract class: CommunicationObject直接实现了该Interface。CommunicationObject的实现统一的State machine。WCF channel layer的很多的class都直接或者间接的继承了这个class。你也可以让你的class继承该class。当你让你自己的class继承CommunicationObject的时候,在override 掉base相应的method的时候,强烈建议你先调用base对应的方法,CommunicationObject会帮你进行相应的State转换和触发相应的事件。

时间: 2024-11-02 21:05:21

WCF后续之旅(2) 如何对Channel Layer进行扩展——创建自定义Channel的相关文章

WCF后续之旅(7):通过WCF Extension实现和Enterprise Library Unity Container的集成

松耦合.高内聚是我们进行设计的永恒的目标,如何实现这样的目标呢?我们有很多实现的方式和方法,不管这些方式和方法在表现形式上有什么不同,他们的思想都可以表示为:根据稳定性进行关注点的分离或者分解,交互双方依赖于一个稳定的契约,而降低对对方非稳定性因素的依赖.从抽象和稳定性的关系来讲,抽象的程度和稳定程度成正相关关系.由此才有了我们面向抽象编程的说法,所以"只有依赖于不变,才能应万变". 然后,对于面向对象的思想来讲,我们的功能通过一个个具体的对象来承载.对象是具体的,不是抽象的:创建对象

WCF后续之旅(8):通过WCF Extension 实现与MS Enterprise Library Policy Injection Application Block 的集成

在上一篇文章中,我们通过自定义InstanceProvider实现了WCF和微软Enterprise Library Unity Application Block的集成, 今天我们已相同的方式实现WCF与Enterprise Library的另一个Application Block的集成:Policy Injection Application Block (PIAB). PIAB,通过Method Interception的机制实现了AOP(Aspect Oriented Programin

WCF后续之旅(13): 创建一个简单的WCF SOAP Message拦截、转发工具[上篇]

WCF是.NET平台下实现SOA的一种手段,SOA的一个重要的特征就基于Message的通信方式.从Messaging的角度讲,WCF可以看成是对Message进行发送.传递.接收.基础的工具.对于一个消息交换的过程,很多人只会关注message的最初的发送端和最终的接收端.实际上在很多情况下,在两者之间还存在很多的中间结点(Intermediary),这些中间结点在可能在实际的应用中发挥中重要的作用.比如,我们可以创建路由器(Router)进行消息的转发,甚至是Load Balance:可以创

WCF后续之旅(13):创建一个简单的SOAP Message拦截、转发工具[下篇]

在Part I 中,我们创建了一个InterceptService,并且通过一个特殊的EndpointBehavior,ClientViaBehavior实现了message的拦截.转发功能.在本节中,我们将讨论另外一种不同的实现方式.如何说ClientViaBehavior是基于Client端的实现方式,那么我们今天讨论的是基于Service的实现方式. 在对新的实现方式展开介绍之前,我们先来介绍一下关于逻辑地址和物理地址. 一.逻辑地址和物理地址 我们知道,WCF通过Endpoint进行通信

《WCF后续之旅》博文系列总结[共17篇]

<我的WCF之旅>系列自开篇以来,得到了园子里很多朋友的厚爱,并荣登了博客园2007年度系列博文Top 10.由于工作原因,沉寂了一阵,两个月前开始WCF新的旅程.如果说<我的WCF之旅>主要是对WCF基本原理概括性介绍,而对于这个新的系列,我将和大家分享我对WCF的一些实现机制.设计原理的理解,以及我在实际的项目开发中的一些实践经验(比如在后续的一些文章中,我将介绍通过WCF Extension实现一些在真正的分布式项目开发中很有现实意义的功能). [第1篇] WCF是如何通过B

WCF后续之旅(9): 通过WCF双向通信实现Session管理[下篇]

一.Session Management Service的实现 现在我们来看看Session Management真正的实现,和我以前的例子不同,我不是把所有的实现都写在WCF service上,而是定义了另一个class来实现所有的业务逻辑:SessionManager.我们分析一下具体的实现逻辑. 1: namespace Artech.SessionManagement.Service 2: { 3: public static class SessionManager 4: { 5: p

WCF后续之旅(4):WCF Extension Point 概览

在本系列的每篇文章中,我多次提到WCF是一个极具可扩展性的分布是消息通信框架.为了让读者对WCF Extension有一个总体的的认识,在这里我会简单列举了我们经常使用的绝大部分的扩展点,以及通过这些扩展点能够解决实现项目开发中的那些问题. 有一点需要特别提醒的是:对WCF extensions的灵活应用依赖于你对channel layer和service mode dispatching system的深入理解.所以,如果你对channel layer不甚了解,可以参阅本系列的第一个部分(WC

WCF后续之旅(9):通过WCF的双向通信实现Session管理[上篇]

我们都知道,WCF支持Duplex的消息交换模式,它允许在service的执行过程中实现对client的回调.WCF这种双向通信的方式是我们可以以Event Broker或者订阅/发布的方式来定义和调用WCF Service.今天我们就给大家一个具体的例子:通过WCF的duplex communication方式现在Session管理. 一.Session 管理提供的具体功能 我们的例子实现了下面一些Session Management相关的功能: Start/End Session:可以调用s

[原创]WCF后续之旅(12): 线程关联性(Thread Affinity)对WCF并发访问的影响

在本系列的上一篇文章中,我们重点讨论了线程关联性对service和callback的操作执行的影响:在service host的时候,可以设置当前线程的SynchronizationContext,那么在默认情况下,service操作的执行将在该SynchronizationContext下执行(也就将service操作包装成delegate传入SynchronizationContext的Send或者Post方法):同理,对于Duplex同行方式来讲,在client调用service之前,如果