ESFramework介绍之(13)-- 功能插件处理器工厂

    上文讲述的是AS中的基于连接池的消息处理器,现在我们把焦点转移到功能服务器FS上来,看看FS上消息分派的过程。当FS接收到到一个请求后,会从已加载的功能插件列表中选择一个合适的插件来处理这个消息,而每一个功能插件就相当于一个消息处理器。FS和AS的结构一致:

    要注意的是,功能服务器FS上收到的所有消息都应该交给功能插件来处理,不存在其它的处理方式。这是使得FS“纯粹”的必须要求。上图已经很清楚的表示了功能插件处理器工厂的位置和作用。它借助插件管理器实现“工厂”的功能。其实现非常简单,如下所示:

 1     /// <summary>
 2     /// AddinDealerFactory 功能插件处理器工厂,每一个功能插件能转换为一个处理器
 3     /// </summary>
 4     public class FunAddinDealerFactory :IDataDealerFactory
 5     {
 6         private IAddinManagement addinManagement ;
 7 
 8         public FunAddinDealerFactory()
 9         {            
10         }
11 
12         #region property
13         public IAddinManagement AddinManagement
14         {
15             set
16             {
17                 this.addinManagement = value ;
18             }
19         }
20         #endregion
21 
22         #region IDataDealerFactory 成员
23         public IDataDealer CreateDealer(int requestType, int serverTypeKey)
24         {
25             foreach(IAddin addin in this.addinManagement.AddinList)
26             {
27                 if((addin.ServiceKey == requestType) && (addin.Enabled))
28                 {
29                     return (IDataDealer)addin ;
30                 }
31             }
32 
33             return null;
34         }
35 
36         #endregion
37     }

    前面已经提到过,每个功能插件都必须是自给自足的,有的可以有自己的配置文件、有的可能需要访问数据库或外部的WebService等等。暂时,FS还不支持功能插件之间的依赖――每个插件必须是相互独立的。
    前面有个天气预测服务的例子,对应的功能插件需要访问国外的http://www.webservicex.net/globalweather.asmx的Web服务。就像下图这样:

    本文的内容非常简单,上面的图示也基本上描述的FS的主体结构。后面我们会关注,AS与FS之间的非功能通信,并说明整个平台是如何实现FS的动态添加/移除的,并解释如何在网络不稳定的情况下,保证AS和FS之间的良好通信的机制。感谢关注。

 上一篇:ESFramework介绍之(12)―― 基于Tcp连接池的消息处理器 

 转到  :ESFramework 可复用的通信框架(序) 

时间: 2024-09-20 01:41:18

ESFramework介绍之(13)-- 功能插件处理器工厂的相关文章

ESFramework介绍之(14)-- AS与FS通信方案

    前面我们已经多次提到,每个AS都有一组FS为之服务(回顾),AS将接收到的功能请求通过Tcp连接池 或Remoting转发给某个FS处理.下面我们将深入讨论AS和FS之间的通信机制.     首先要解决第一个问题,AS如何知道每个为之服务的FS的地址?    最常见的一种解决方案是,AS处的配置文件中有一个FS地址列表,AS每次启动时,就读取这个列表,然后与列表中的每个FS建立Tcp连接池.这种方案很容易实现,但是有很多缺点.最主要的是当动态的添加/移除FS时,都需要修改AS配置文件中的

ESFramework网络通信框架介绍之(3)――消息处理器和处理器工厂

一.ESFramework网络通信框架与消息处理器   无论是服务端还是客户端,都需要对接收到的消息进行处理,在ESFramework网络通信框架中,处理消息的组件称为消息处理器,所有的消息处理器都实现了接口IDataDealer:    1     public interface IDataDealer2     {        3         NetMessage  DealRequestMessage(NetMessage reqMsg) ;        4     }    

ESFramework介绍之(31)―― 消息分类及对应的处理器

    这是一篇迟到了很久的文章,要不是今天看到Mediar朋友写的"基于ESFramewok的 客户端和客户端通迅"的文章,我也许还不会想起写这篇应该很早就发表的Blog,它可以帮助ESFramework的研究者/使用者们更好的使用ESFramework.Mediar朋友的那篇文章中介绍了通过服务器转发P2PMessage,Mediar手动实现了一个自己的处理器,实际上ESFramework已经内置了P2PMessage的处理器,那就是P2PMessageDealer,P2PMess

ESFramework介绍之(17)―― 支持漫游用户和跨区域功能请求

    对于漫游用户的支持和跨区域功能请求的支持是ESFramework最基本的目的之一(回顾),在详细讲述解决方案之前,先了解一下关于这个问题的上下文.    在我们前面讲述的4层C/S架构中,每个AS负责一块区域.比如上海AS负责处理所有目标城市为上海的功能请求和管理所有在上海AS上注册的用户(比如PDA用户或手机用户).如果一个本是在上海注册的用户出差来到了武汉,最方便的,他会连上武汉的AS,这样对于武汉AS来说,这个用户就是漫游用户了.    如果上海的用户登陆上了上海的AS,但是他需要

ESFramework介绍之(8)-- 客户端插件IPassiveAddin

    前文已经提到了,在IServerAgent的基础上,客户端也可以采用插件的结构形式,客户端插件需要实现IPassiveAddin接口.    我的想法是,当客户端主程序加载一个新的PassiveAddin时,可以在某个菜单的子Items上添加一项,当双击这个子菜单项时,则弹出该客户端插件提供的"业务操作窗体".这只是使用客户端插件的可行方式之一,你完全可以根据你的应用来决定使用形式.IPassiveAddin接口定义如下:  1     /// <summary> 

ESFramework介绍之(9)-- 插件对(Addin Pair)调试“框架”

    使用ESFramework开发C/S(通常为4层.3层也没问题)应用,当需要增加一项新的业务时,我们需要做的仅仅是开发两个插件,一个是服务端的业务功能插件(FunAddin),一个是客户端插件(PassiveAddin),这两个插件合在一起称为Addin Pair.开发这两个插件,只需要关注于业务,而其它与业务无关的比如网络通信.加密.数据安全,都不用管.ESFramework很好的将这些关注点分离开来,使得写"业务"插件的程序员的工作变得非常单纯,在ESFramework介绍

ESFramework介绍之(26)-- 支持复杂插件(InnerDealer 和 InnerDispatcher)

    (本文内容适合于 ESFramework V0.2+)    通常,最单纯的情况是一个插件对应某一特定类型的功能请求,但是,在有的应用中也会出现这样的情况,有多种类型的功能请求相互关联.并且可能交叉,如果是这样,对应每种类型的请求都开发一个插件可能会非常困难,因为这可能会牵涉到插件之间的相互引用/访问,这违背了插件的"自治"性.最好的办法还是将它们放在一个插件中,通过ServiceItemIndex(你一定还记得消息头定义中除了ServiceKey外还有个ServiceItem

ESFramework介绍之(29)―― 插件公共设施 AddinUtil

    (本文适用于 ESFramework V0.2+)    不知你是否还记得,前面我们讲过,ESFramework规定了插件有如下特点: (1)一个插件是一个独立的物理单元.它可以独立的提供一项完整的服务(功能),而不需要依赖于其它插件. (2)插件能自我描述 ―― 插件的所有对外的发布信息都由插件自己内部提供,而不依赖于外部文件或注册表. (3)插件能自我管理 ―― 插件如果需要配置信息,则插件自己能读取和修改配置信息,而不是框架来完成这些事情.(4)插件自我独立   ―― 一个插件不得

ESFramework介绍之(20)―― 插件自动升级

    当我们的服务平台搭建成功后,所需要做的主要事情就是开发服务端功能插件(IFunAddin)和客户端插件(IPassiveAddin),每个插件对(AddinPair)实现了一组相似或相近的需求/功能.     好了,我们已经开发了十多对插件对,然后分别XCopy到了各个服务器节点上,"整个系统"已经投入了运行.通过前面的介绍(回顾),相信大家对我们的"整个系统"有了个大致的映像.我们的IRAS服务器通常只存在于一个节点上,而我们的AS和对应的多个FS通常分布