1. 引言

　　Java领域开发人员可以采用spring开源框架快速构建自己业务应有系统本人羡慕不已但是在我采用传统开发语言、专业应用领域都没有这样好框架可以沿用于是早有自己设计个IoC框架适用于本人涉及实时监控、通信采集领域

　　“他山的石、可以攻玉”其实IoC、DI等优秀分析、设计理论未必非要用来构架通用基础开发框架在具体应有系统开发中借用同样能构建灵活系统体系架构尤其是对于企业战略性长期产品、系统构建更是事半功倍

　　2. 系统背景介绍

　　在实时监控、数据采集等通信类系统中通常设计都是:将数据采集或者和底层逻辑单元(比如:底层软件Software子系统、硬件终端、远程设备)通信逻辑功能独立封装在个子系统中实现基础通信收发、通信方式分化、通信流程控制、底层协议规整、基础数据整合等网络通信、数据采集职责

　　本设计是针对常见实时监控、数据采集系统下面以个典型通信采集服务器应有为例:系统底层是硬件采集设备硬件设备完成整个系统和外界环境或者设备交互；上层软件Software系统完成和自己硬件设备交互并且对采集数据进行分析、处理、存储、和外部系统接口



　　3. 问题

　　在我工作软件Software项目中类似应用存在于多个软件Software系统中虽然这些系统在子系统设计及职责划分方面也如上图般进行了明确分层及模块化但在核心“通信采集子系统”设计及实现上存在诸多通病导致整个子系统可理解性、可维护性、可测试性、对需求变动适应性极差集中表现在:

　　整个系统被设计成个“非常庞大”“业务调度控制类”没有进行职责拆分和封装；

　　在通信方式实现类(比如:串口通信类、语音卡控制类、TCP/IP通信类)中完成所有业务处理功能；(绝大多数板卡厂商Demo就是这样演示有意无意间误导了很多刚刚接触CTI、IVR系统开发入门者)

　　对于多任务并发多个设备上、下行同时通信管理非常复杂；

　　对于需求变化适应性非常差；

　　系统代码几乎没有可复用性了

　　4. 新问题

　　针对上述问题整理总结、分析以往经验和教训以“代码复用”为出发点重新设计了通信采集系统体系架构并较好地解决这些突出问题并梳理出大量可复用功能代码详细介绍说明请参考个典型采集服务器体系结构设计文:http://blog.csdn.net/cxxsoft/archive/2006/09/18/1236331.aspx

　　但是后来再次开发通信采集服务器以应有于区别业务需求时发现原来架构存在如下典型问题:

　　“采集控制器”几乎不能重用、但和新开发采集控制模式非常相识但是每次新开发“采集控制器”逻辑都非常相识但必须修改业务采集类类名和思路方法名修改状态机转换关系修改协议类名和思路方法名

　　“业务采集类”变化会直接影响到“采集控制器”

　　“通信协议类”变化会直接影响到“采集控制器”

　　通信控制流程、时序变化会直接影响到“采集控制器”并且要正确实现这些变化必须在和此无关“采集控制器”中小心翼翼地扣代码出来改

　　5. IoC重构设计

　　开源通用采集服务器是在原有系统架构基础上增加业务抽象接口引用IoC设计理念倒置交互类的间依赖关系采用DI来实现类的间依赖关联动态关联

　　抽象“业务调度核心类”核心逻辑流程将所有类思路方法设计成对接口思路方法

　　抽象“采集控制类”核心逻辑流程将所有类思路方法设计成对接口思路方法“采集控制器”类被设计成个通用“工控机主板”只要遵循“主板”约定接口换插区别“业务采集类”、“通信协议类”就可以实现完全区别采集业务需求、按照完全区别通信协议和底层模块通信

　　将“采集控制类”中状态机管理逻辑剥离出来将状态机检测和控制代码设计成对接口思路方法只要遵循状态机接口就可以灵活实现不要业务需求状态转换控制在运行期动态创建状态机例子并注入到“采集控制类”完全接触“采集控制器”和“业务状态机类”静态依赖

　　去掉“通信适配器”、“协议适配器”增加“通信接口”、“协议接口”和“业务接口”按照接口要求重构通信类、协议类、采集业务类解决原来系统架构中:新增种通信方式、通信协议时还必须在相关适配器中增加新类型识别代码设计弊端

　　6. 技术基础和规约

　　本设计核心设计原理:IOC容器根据反射机制动态创建实现约定接口业务对象动态注入到采集调度控制器中采集调度控制器是个高层次抽象Active Class自动不断地状态机接口思路方法来执行“业务采集类”要求业务通信指令

　　本设计核心重要设计约定:采集调度控制器只抽象接口思路方法那么具体上层业务任务如何动态翻译成具体通信协议？又如何知道当前任务如何开始何时结束？本设计要求:业务采集类必须管理好自己业务步骤和通信协议的间对应关系(确实非常难以在抽象用动态配置思路方法使用起来反而更复杂)采集调度控制器只负责动态建立两者的间运行期对象关系业务采集类必须实现采集调度控制器要求指定接口思路方法用以实现采集任务发起、执行下条指令、结束、异常重发、异常中止、故障处理等采集流程控制功能这正好是采集调度控制器高层抽象价值和通用性设计基础

　　框架使用者只需按照接口约定编码实现具体业务需求相关采集、状态机、协议业务类；在配置这些类运行期参数采集服务器就大功告成采集服务器在允许时会自动加载配置参数动态创建相关业务逻辑对象并完成依赖注入整个系统就能按具体业务要求完成通信、采集任务

　　7. 采集服务器设计

　　通信采集服务器是常常是实时监控、数据采集类系统核心实现和底层软件Software子系统、硬件终端、远程设备通信、下行命令执行、上行数据接收、协议解析并且完成业务数据分析以及显示驱动它既是系统通信枢纽也是业务核心

　　下图是基于IoC理念重新设计通用开源采集服务器子系统体系结构:



　　8. 核心组件设计介绍

　　1. 业务数据接口

　　以统方式输出本框架按配置“通信模块”、“通信协议”、“采集业务类”所采集到数据框架使用者实现此接口思路方法可以继续分析、处理、存储、展现业务数据

　　2. 外部系统接口

　　本系统对外部系统接口目前没有定义具体思路方法属于框架设计预留接口框架使用者可以实现此接口定制通信协议、通信方式实现和外部系统信息交互外围系统通过此接口向“业务调度核心类”发起通信命令、操控底层设备、实时提取设备状态等业务请求

　　3. 业务调度核心类

　　是采集子系统业务调度核心类和业务请求中转站外部系统命令请求通过“外部系统接口”转入到“业务调度核心类”“业务调度核心类”将命令请求存入命令队列中共“”执行；“”采集到数据的后“数据接口”思路方法将数据返回到“业务调度核心类”的后“业务调度核心类”“业务数据接口”或者“外部系统接口”将业务数据反馈到更上层模块

　　4. 任务队列管理类

　　下行任务信息缓存Cache类“业务调度核心类”向其中增加命令请求；“采集调度控制器”自动检测是否有新命令请求当检测到后立即“中断”通信握手执行请求执行成功的后从队列中删除该命令

　　5. 采集调度控制类

　　管理、协调其下“采集业务类”、“通信实现类”、“业务状态机类”、“通信协议类”等模块完成所有通信控制及数据采集功能通过任务接口获取采集指令；的后业务接口(业务接口由“采集业务类”实现在具体使用中由框架使用者根据自己业务采集需求开发)获取具体通信指令；根据通信指令正确协议接口(协议接口由“通信协议类”实现在具体使用中由框架使用者根据自己通信协议需求开发)获得通信帧；最后启动状态机开始本次采集任务执行采集调度控制器

　　6. 采集业务类

　　封装当前系统具体采集业务对象为通用“采集调度控制类”定制具体采集任务本质就是:把上层“抽象任务”细化成具体“通信帧”和“通信控制步骤”、是个简单“工作流定制器”

　　7. 业务状态机类

　　实现状态机接口根据采集业务状态控制、转换需求框架使用者定制开发主要用于通信链路通断控制、数据收发、忙闲标识及转换等业务状态机逻辑

　　8. 采集方式类

　　封装具体串口、TCP/IP、语音卡等通信采集类实现具体通信方式控制及通用数据收发接口

　　9. 通信协议类

　　封装系统中软件Software和底层软件Software子系统、硬件设备、远程终端通信协议

　　9. 设计模式和原理

　　1) 整个系统采用MVC设计模式:业务数据、显示控制及界面显示严格分层单独实现业务数据通过下层模块产生通用“业务调度核心”这个中介和“界面接口定制类”这个控制器交互；控制器“界面接口定制类”可以根据区别显示需要进行定制和区别界面组件交互可满足区别显示需求；在界面显示层引用了其它项目中实现“标准界面通用组件库”中部分源码

　　2) “业务调度核心类”采用Mediator模式

　　3) “采集调度控制器”采用“微内核”实时设计模式

　　4) 命令队列采用Command模式:以强制分离命令发起者和命令执行者

　　5) “业务状态机”采用State模式:通过抽象业务状态机可以灵活地实现区别采集控制需求并且如果采集方式类是语音卡的类设备时采集类里面也往往采集“状态机”模式来管理这类自身以状态方式驱动通信设备



　　6) “业务采集类”对多协议自动处理采用Chain Of Responsibility:将多个协议组件组织成条“职责链”实现对当前通信协议自动识别、自动解析功能

　　7) “采集调度控制器”考虑并发和性能采用“通道”实时设计模式:以尽可能地提升系统并发能力、提高系统吞吐能力

　　8) “采集调度控制器”采用“轮巡”和“中断”实时设计模式:为检测通信链路是否可用在通信空闲时系统要求和硬件终端进行定期“通信握手”当“采集调度控制器”检测到“命令队列”或者“硬件终端”任务请求时采用“中断”方式立即响应上、下行命令

　　10. 应有例子

　　采用此框架体系架构框架使用者只需按“任务接口”实现自己特定“任务队列管理类”按“业务接口”实现自己特定“采集业务类”按“状态机接口”实现自己特定通信业务控制“业务状态机类”再按“协议接口”实现自己特定“通信协议类”就能够非常快速地开发个功能完备、运行稳定通信采集服务器目前应有此框架已成功构建“指纹采集系统”、“粮情测控系统”通信采集服务器