.NET简谈组件程序设计之(详解NetRemoting结构)

简介: 在本人的上一篇文章中只是简单的介绍了一下.NETRemoting的一般概念和基本的使用。这篇文章我想通过自己的学习和理解将对.NETRemoting的整体的一个框架进行通俗的讲解,其中最重要的就是信道(管道)处理模型思想,这里面蕴含了很多的设计原理。

在本人的上一篇文章中只是简单的介绍了一下.NETRemoting的一般概念和基本的使用。这篇文章我想通过自己的学习和理解将对.NETRemoting的整体的一个框架进行通俗的讲解,其中最重要的就是信道(管道)处理模型思想,这里面蕴含了很多的设计原理。[王清培版权所有,转载请给出署名]
.NETRemoting远程处理架构是一个半成品,是.NET给我们的扩展框架,要想用于商业项目必须进行一些安全、性能方面的控制。要想进行一定深度的扩展那就要必须了解它的整体结构,各个点之间的关系才能很好的控制它。

网上讲解.NETRemoting的文章很多,但是通俗易懂的没有几篇,都是大概讲解了一下整体模型或者从MSDN上COPY过来,未能对各模型之间的接口做详细讲解。了解.NETRemoting的朋友都知道,它的实现基本上都是通过接口与接口之间的串联形成处理管道,这也让我们想起来了设计模式中首要提及的面向对象设计思想“面向接口编程”。

本人在学习.NETRemoting的时候还是比较痛苦的,由于中文资料缺乏只能通过搜索网上零零散散的知识点再通过拼命的理解、换位思考、提高抽象层次,才终于参透为什么那么多接口之间的关系,在这里小弟会一一讲解那些诸如IClientChannelSink、IClientChannelSinkProvider、IMessageSink等等接口到底是什么意思,提供程序与信道接收器之间又是啥关系,在信道处理模型中是怎么利用多态来设计的。


.NETRemoting处理管道

在.NETRemoting中它的整体处理模型有点像ASP.NET中的HTTP处理管道模型,消息从最上面的入口进入然后一个一个的传递到各个处理模块中,这样就形成了一个抽象的处理管道。

图1(客户端信道处理):

这是客户端信道处理模型的大概结构。任何客户端对跨远程处理都是通过代理进行的,代理分为两部分一种是透明代理,一种是真实代理;

透明代理是通过真实代理动态生成的,透明代理的所有成员都是客户端将要调用的远程对象的一个虚拟镜像。为什么要说是虚拟的,是因为透明代理只是方便客户端调用的,当我们NEW一个远程对象时,系统将为我们动态的生成一个继承自你NEW的那个对象的代码,然后动态生成内存透明代理对象。

透明代理包括了对真实代理的调用,真正的幕后主脑是RealProxy对象,它包括了对信道处理结构的引用。在上面的图1中为什么真实代理是用IMessageSink接口来启动整个信道处理模型的。这里也是最为难理解的入口点,下面我们将自己的抽象能力提升一个层次才能知道系统为什么要这样设计。[王清培版权所有,转载请给出署名]
图2:(服务器端信道处理)

.NETRemoting饶人的名词解释

不管是服务器端还是客户端都是通过信道处理模型来对双方的消息进行一系列的处理。客户端的信道处理和服务器端的信道处理有点区别,这些区别是来自它们的更高层次的抽象。这句话可能根本不好理解,从我上面的两幅图中我想读者多多少少能理解点意思来,在信道处理管道中都是通过每个信道接收器提供程序来创建有处理能的信道接收器。

我们先来解决一些会给我们理解带来困扰的英文单词:

Channel:在系统中它表示信道,也就是处理管道。

IChannel:表示一个抽象的处理管理,用来标识一个管道的信息,如管道名称,管道级别之类的。

Sink:接收器,也就是管道中的消息处理环节,系统通常用这个单词来组合,也会让初学者容易参数混淆(看过这篇文章后你就不会在混淆了)。

Provider:一般表示为提供程序,在.NETRemoting里面的提供程序这是某些环境的一个入口点,比如在系统中序列化环节,系统通过SoapClientFormatterSinkProvider提供程序来创建SoapClientFormatterSink信道接收器,这里的提供程序是表示即将进入处理过程,这个处理过程表示某一个处理环节,在这个处理环节中可能包括很多用来接收要处理的信息,所有叫做信息接收器,也就是sink结尾的接口。

IClientChannelSinkProvider:客户端信道接收器提供程序,也就是图1中表示的每个对消息的处理环节部分。该接口有一个NEXT属性用来连接下一个提供程序,这样就串联起一个抽象的处理管道。我们要记住提供程序这是创建处理环节的入口点,真正用来处理消息的是sink结尾的接口,这里也就是IClientChannelSInk对象。

IClientChannelSink:客户端消息接收器,用于在管道处理中对消息的传递进行个性化修改,我们可以在这个里面进行一些消息传递的压缩、编码等等。

IServerChannelSinkProvider:服务器端信道接收器提供程序,和客户端是相同的功能,都是用来创建信息接收器用的,只不过这里是服务器端的信息处理。

IServerChannelSink:服务器端消息接收器,用来在服务器端进行消息的处理,可以对传输过来的消息进行解压缩、反编码等等,与客户端功能是对应的。

IMessageSink:入门的朋友可能会对这个接口参数误解,这是啥接口啊?我不是有了Sink类型的接口了吗?为什么还要消息接口?其实这里也很好理解,为什么需要各种各样的接口,这就是我上面所说的“将自己的抽象能力提升一个高度”才能理解。如果对接口编程不是很熟悉的朋友可能是不太好理解。每种接口表示某种抽象,我打个比方,如果有一个对象它既实现了IMan接口,又实现了IDog接口,它在与人交流的时候我们知道它是实现了人类接口的对象,所以我们认识它并且能与它进行交流,如果它与狗交流的话那么狗狗也是认识它的因为它也实现了狗的接口。从这里讲,实现多个接口的对象具有很深的抽象层次,在某些场合它被视为一种类型,在另外一些场合它又被视为另一种类型。下面我们讲到具体的接口实现时,就明白我所说的意思了。

.NETRemoting信道接收器

上面的名词解释的差不多了,我们来动动手吧;

按照上面的客户端信道模型图,我们先来实现一个IClientChannelSinkProvider接口,我们将利用这个接口来创建一个能处理消息的IClientChannelSink接口。

 

using System;
using System.Collections.Generic;
using System.Collections;
using System.Text;
using System.Runtime.Remoting;
using System.Runtime.Serialization.Formatters;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Lifetime;
using System.Runtime.Remoting.Channels.Http;
using System.Runtime.Remoting.Channels.Tcp;
using System.Runtime.Remoting.Channels.Ipc;

namespace MyClassLibrary.CustomProvider
{
    public class ClientCustomProvider : IClientChannelSinkProvider
    {
        #region IClientChannelSinkProvider 成员
        /// <summary>
        /// 创建该提供程序的信道接收器,所有的信道接收器提供程序均要实现CreateSink方法,保证所有的信道接收器能串联起来。
        /// </summary>
        /// <param name="channel">上下文发送接口</param>
        /// <param name="url">对象的终结点</param>
        /// <param name="remoteChannelData">信道数据</param>
        /// <returns>IClientChannelSink客户端信道接收器接口</returns>
        public IClientChannelSink CreateSink(IChannelSender channel, string url, object remoteChannelData)
        {
            return new ClientCustomSink(Next.CreateSink(channel, url, remoteChannelData));
        }
        /// <summary>
        /// 获取下一个信道接收器提供程序。通过这里的NEXT属性将所有的信道接收器连接起来。
        /// </summary>
        public IClientChannelSinkProvider Next { get; set; }

        #endregion
    }
}

 

这里是我们创建客户端接收器提供程序的代码,在这里我们创建个一个ClientCustomSink信道接收器对象,但是在构造函数中我们用NEXT属性又创建了一个信道接收器作为参数传入到对象,这样做的目的就是能保证每一个消息接收器处理完成后能接着传递给下一个信息接收器处理。

using System;
using System.Collections.Generic;
using System.Collections;
using System.Text;
using System.Runtime.Remoting;
using System.Runtime.Serialization.Formatters;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Lifetime;
using System.Runtime.Remoting.Channels.Http;
using System.Runtime.Remoting.Messaging;
using System.Runtime.Remoting.Channels.Tcp;
using System.Runtime.Remoting.Channels.Ipc;

namespace MyClassLibrary.CustomProvider
{
    public class ClientCustomSink : BaseChannelSinkWithProperties, IClientChannelSink
    {
        IClientChannelSink nextchannelsink;
        public ClientCustomSink(IClientChannelSink nextchannel)
        {
            nextchannelsink = nextchannel;
        }
        #region IClientChannelSink 成员

        public void AsyncProcessRequest(IClientChannelSinkStack sinkStack, IMessage msg, ITransportHeaders headers, System.IO.Stream stream)
        {
            nextchannelsink.AsyncProcessRequest(sinkStack, msg, headers, stream);
        }

        public void AsyncProcessResponse(IClientResponseChannelSinkStack sinkStack, object state, ITransportHeaders headers, System.IO.Stream stream)
        {
            nextchannelsink.AsyncProcessResponse(sinkStack, state, headers, stream);
        }

        public System.IO.Stream GetRequestStream(IMessage msg, ITransportHeaders headers)
        {
            msg.Properties.Add("自定义消息", "自定义消息值");
            return nextchannelsink.GetRequestStream(msg, headers);
        }

        public IClientChannelSink NextChannelSink
        {
            get { return nextchannelsink; }
        }

        public void ProcessMessage(IMessage msg, ITransportHeaders requestHeaders, System.IO.Stream requestStream, out ITransportHeaders responseHeaders, out System.IO.Stream responseStream)
        {
            nextchannelsink.ProcessMessage(msg, requestHeaders, requestStream, out responseHeaders, out responseStream);
        }
        public IDictionary NextProperise
        {
            get { return nextchannelsink.Properties; }
        }
        #endregion
    }
}

 

有一这里的代码太长我就不加注释了。这个对象主要实现了IClientChannelSink接口,也就是信道接收器接口,在这个接口面明前比Provider提供程序多了很多东西。这里才是真正处理的地方,系统为了代码的整洁性将提供程序与信息接收器分离开,其实也可以将这两个接口进行合并。在构造函数里面我们用一个私有的IClientChannelSink保存了下一个Sink。该对象还实现了BaseChannelSinkWithProperties抽象类,这个类是用来获取下一个信道接收器的内部属性用的。如果我们没有实现这个抽象类就要自己实现NextProperise属性。[王清培版权所有,转载请给出署名]

其实在IClientChannelSink里面比较重要的就是GetRequestStream和ProcessMessage两个方法,一个是用来获取即将要发送的Stream流,一个是进行发送的方法。为了便于大家的理解,请看图3:

我上面的处理流程不一定就是GetRequestStream是第一步,但是它是ProcessMessage方法的上一步,所以我用1、2表示。当GetRequestStream到了最后一个Sink时,系统将进行最后的调用,也就是进行远程发送了。
在GetRequestStream中我们加入了一些自己定义的数据,我们在通过服务器端的IServerChannelSink获取这消息。

using System;
using System.Collections.Generic;
using System.Collections;
using System.Text;
using System.Runtime.Remoting;
using System.Runtime.Serialization.Formatters;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Lifetime;
using System.Runtime.Remoting.Channels.Http;
using System.Runtime.Remoting.Messaging;
using System.Runtime.Remoting.Channels.Tcp;
using System.Runtime.Remoting.Channels.Ipc;

namespace MyClassLibrary.CustomProvider
{
    public class ServerCustomSink : BaseChannelSinkWithProperties, IServerChannelSink
    {
        private IServerChannelSink iserverchannelsink;
        public ServerCustomSink(IServerChannelSink serverchannel)
        {
            iserverchannelsink = serverchannel;
        }
        #region IServerChannelSink 成员

        public void AsyncProcessResponse(IServerResponseChannelSinkStack sinkStack, object state, IMessage msg, ITransportHeaders headers, System.IO.Stream stream)
        {
            if (iserverchannelsink != null)
                iserverchannelsink.AsyncProcessResponse(sinkStack, state, msg, headers, stream);
            throw new NotImplementedException();
        }

        public System.IO.Stream GetResponseStream(IServerResponseChannelSinkStack sinkStack, object state, IMessage msg, ITransportHeaders headers)
        {
            if (iserverchannelsink != null)
                iserverchannelsink.GetResponseStream(sinkStack, state, msg, headers);
            throw new NotImplementedException();
        }

        public IServerChannelSink NextChannelSink
        {
            get { return iserverchannelsink; }
        }

        public ServerProcessing ProcessMessage(IServerChannelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders requestHeaders,
            System.IO.Stream requestStream, out IMessage responseMsg, out ITransportHeaders responseHeaders, out System.IO.Stream responseStream)
        {
            sinkStack.Push(this, "ok");
            return NextChannelSink.ProcessMessage(sinkStack, requestMsg, requestHeaders, requestStream, out responseMsg, out responseHeaders, out responseStream);
        }

        #endregion

    }
}

 

图4:

 

总结:

.NETRemoting是一个非常成熟的CLR远程处理框架,其实现的原理也很复杂,基本上每一部分都可以扩展,它的内部实现都是通过面向接口来的,接口的粒度也非常小。从IXXXChannelSinkProvider和IXXXChannelSink两种接口就可以看出来,里面的空间很大。

本篇文章只是本人在学习.NETRemoting过程中的一点小小的感悟献给那些还没有搞清楚Remoting的基本框架的朋友。谢谢

目录
相关文章
|
9月前
|
消息中间件 存储 监控
高弹性、低成本的云消息队列RabbitMQ 版
本次课程由阿里云消息队列产品专家杨文婷分享,主题为高弹性、低成本的云消息队列RabbitMQ。内容涵盖四个方面:1) 产品优势,包括兼容开源客户端、解决稳定性痛点和高弹性低成本;2) 架构实现原理,如分布式架构和弹性调度系统;3) Serverless系列带来的按量付费模式和资源池优势;4) Serverless适用场景,如开发测试环境、峰谷流量业务等。最后解答了关于顺序消费、与普通MQ对比、自动扩容及API支持等常见问题。
356 46
|
8月前
|
存储 关系型数据库 MySQL
MySQL进阶突击系列(06)MySQL有几种锁?| 别背答案,现场演示一下
本文详细解析了MySQL InnoDB存储引擎的锁机制,涵盖读锁、写锁、意向锁、记录锁、间隙锁和临键锁等8种锁类型。重点探讨了不同锁类型的加锁与释放方式,以及事务并发场景下的实战验证。通过具体示例,展示了在不同情况下锁的行为及其对事务的影响。文章还特别强调了锁的作用范围主要是索引,并解释了锁如何影响数据的读写操作。最后总结了并发事务中加锁规则,帮助读者深入理解MySQL的锁机制。
|
JSON JavaScript 中间件
Express.js:构建轻量级Node.js应用的基石
**Express.js 概览**:作为Node.js首选Web框架,Express以其轻量、灵活和强大的特性深受喜爱。自2009年以来,其简洁设计和丰富中间件支持引领开发者构建定制化应用。快速开始:使用`express-generator`创建项目,安装依赖,启动应用。示例展示如何添加返回JSON消息的GET路由。Express适用于RESTful API、实时应用等多种场景,社区支持广泛,助力高效开发。
254 1
|
SQL Java 数据库
MyBatis-Plus 条件构造器
MyBatis-Plus 条件构造器
342 0
|
弹性计算 安全 网络安全
阿里云游戏服务器租用费用一年价格表
游戏服务器租用需要高性能、高主频及大带宽等特性,阿里云服务器多线BGP优质网络,公网带宽储备充足,多款云服务器ECS实例规格可选
1364 0
阿里云游戏服务器租用费用一年价格表
|
存储 JSON JavaScript
“Jwt认证在前后端分离架构中的应用与优化“
“Jwt认证在前后端分离架构中的应用与优化“
275 0
|
Linux Windows
linux中的 ln 软链接、history 查看已经执行过历史命令linux中的> 输出重定向和 >> 追加、时间日期类、date 显示当前时间linux中的tail 输出文件尾部内容linux的rm 删除文件或目录、mv 移动文件与目录或重命名
linux中的 ln 软链接、history 查看已经执行过历史命令linux中的> 输出重定向和 >> 追加、时间日期类、date 显示当前时间linux中的tail 输出文件尾部内容linux的rm 删除文件或目录、mv 移动文件与目录或重命名
linux中的 ln 软链接、history 查看已经执行过历史命令linux中的> 输出重定向和 >> 追加、时间日期类、date 显示当前时间linux中的tail 输出文件尾部内容linux的rm 删除文件或目录、mv 移动文件与目录或重命名
|
11天前
|
弹性计算 关系型数据库 微服务
基于 Docker 与 Kubernetes(K3s)的微服务:阿里云生产环境扩容实践
在微服务架构中,如何实现“稳定扩容”与“成本可控”是企业面临的核心挑战。本文结合 Python FastAPI 微服务实战,详解如何基于阿里云基础设施,利用 Docker 封装服务、K3s 实现容器编排,构建生产级微服务架构。内容涵盖容器构建、集群部署、自动扩缩容、可观测性等关键环节,适配阿里云资源特性与服务生态,助力企业打造低成本、高可靠、易扩展的微服务解决方案。
1225 5