这个设计是一个服务器——客户分布式计算系统的一部分,以前已经说了客户端程序的设计过程(http://www.cnblogs.com/lane_cn/articles/116536.html),下面说说服务器端的设计。服务器端程序是建立在一个通讯服务模块的基础上的,我准备以后把这个框架整理一下,在以后的项目中进行发展,可以不断在这个框架上添东西,形成开发.net项目的一个通用的框架。
下面介绍一下这一块程序,大家看看有没有什么好的意见。这里介绍的是和网络通讯有关的部分,至于分布式计算的业务,无非是计算任务的分割、分配、收集、合并,都是一些业务代码,设计做的也比较dirty,首先看一下配置文件,从这里应该能看出整个服务器端的结构。
先是数据库的配置:
<!-- 数据库连接池
自带的数据库连接支持Sql Server和Oracle(oracle的连接实现不完整,不能处理事务和存储过程)
可以扩充数据库连接类型,新的连接实现Aqua.DB.IDBConnection接口
connection节点: 数据库连接实例
type属性: 数据库连接类
name属性: 表示一个数据库连接的唯一名称
connectionstring属性: 数据库连接字符串
size属性: 连接的数量(暂时没有作用,以后待实现池化的连接)
--> <connectionpool> <connection type="Aqua.DB.SqlDBConnection" name="数据库1" size="1" connectionstring="server=localhost;user id=d_user;password=xxiaos;initial catalog=d_db"/> <connection type="Aqua.DB.SqlDBConnection" name="数据库2" size="1" connectionstring="server=xdpan;user id=pmarket;password=pmarket();initial catalog=worker"/> <connection type="Aqua.DB.OracleDBConnection" name="外部数据源" size="1" connectionstring="Data Source=hfdmis;user id=uid;password=pwd"/> </connectionpool> 这个部分的设计还比较简单的,提供了oracle和sql server两种类型的数据库联接,一个factory根据配置文件中connection——type属性产生具体的数据库类,向外界提供了IDBConnection接口的数据库连接。现在这个连接池还是假的,每个池子里只能有一个连接,以后的项目如果有合适的机会,再发展这个连接池,既要增加支持的数据库连接类型,也要完善数据库连接的分配和管理机制。
下面是服务器和客户端的连接:
<!-- 服务池
支持的服务种类: Socket连接服务
可以扩充新的服务,新的服务实现Aqua.Remote.IService接口
service节点: 网络服务实例
type属性: 服务类
sessiontype属性: 处理这个服务消息的会话类,该类是Aqua.Remote.ISession的实现,用户根据自己的业务进行实现
name属性: 表示一个服务的唯一名称
startupstring属性: 服务启动字符串
--> <servicepool> <service type="Aqua.Remote.SocketService" sessiontype="TestServer.FooSession" name="计算分配服务" startupstring="port=9007;maxthread=75;comm=asyn"/> <service type="Aqua.Remote.SocketService" sessiontype="TestServer.FooSession2" name="计算请求服务" startupstring="port=9008;maxthread=25;comm=syn"/> </servicepool> 系统启动的时候,Service pool进行初始化,各个服务在指定的端口进行监听,当客户连接时,为这个客户启动一个线程,建立一个Session对象。当客户发出请求的时候,Service对象将请求内容交给Session对象进行处理,处理完毕后,将Response发回到客户。服务的启动字符串中含有下面这样一些信息:port是服务所在的端口,maxthread是服务所能处理的最大客户数量,comm为通讯形式,提供了同步和异步两种通讯形式。同步的情况下类似web方式,服务器和客户之间的交互是由请求驱动的,在异步方式下,session可以主动向客户端发出消息。
静态视图基本上象下面这样:
在今后的开发工作中,我打算进一步稳定现有的功能,然后再扩充别的形式的服务。客户端的代码要进行整理,也融入这个框架。
目前这个实现也还是有很多缺点的,一个服务的业务全部是在同一个Session对象中处理,造成处理业务的模块比较复杂。要是有可能的话,应该继续拆分业务任务,将任务继续细节化,并且要设法消除各个小任务时序上的偶合关系,Session对象可以将一个请求扔进一个处理链,由链中的各个对象对其进行处理,如下面的样子:
for each processor
in processor_list
processor.Do(
ref response, request);
next
这样能够加强系统的灵活性,很多服务之间共有的功能,比如权限的控制和检查,日志的操作,都可以通过增加一个Processor进行实现。
总结一下,我觉得我在造一个轮子,这次是用c#
本站仅提供存储服务,所有内容均由用户发布,如发现有害或侵权内容,请
点击举报。