|
实现的功能:定期搜索发送任务表,按照指定的电话号码,发送指定内容,支持小灵通。
涉及到的内容:程序对短信设备的控制,pdu编码解码,设计模式
遇到的问题:
1、短信设备提供的是串口接口,因为倾向于跨平台运行这个软件,所以采用了java作为开发工具,但是带来的问题是java对window和linux平台提供的串口api不同,方法也不一样,而且如果以后根据需要,增加短信设备的话,也受到服务器提供的串口的限制。所以采用了以太网控制方式,为短信设备增加了一个RS232转RJ45的32口串口服务器这样就可以通过以太网来控制串口设备了,而且串口设备可以无限增加。但是这样又带来了另一个问题:发送什么格式的数据包才能被串口设备识别呢?我在这个地方花了些时间,串口以太网转换器随机附带了一个串口模拟软件,运行后可以从超级终端控制短信设备,然后根据这个线索,使用wireshark抓包工具对通讯中的包进行了分析,找到了对短信设备初始化的格式包,问题解决。
2、设计模式真是个好东西,优雅的解决事务问题。使用观察者模式负责对短信设备的监听,代码简约干净,使用工厂模式,解决了对象创建混乱的问题。
3、项目初步完成后,领导又连续提出了新的要求,需要短信设备完成的功能更多了,幸亏当时把短信监控发送单独抽取了出来,哈哈,只要把需要短信设备完成的工作添加入发送表就可以了,但是如何管理这些增加的任务呢?每提出一个要求就写一个程序也太累了,而且以后如果数量增加了,管理也是一个难题。我充分利用了java的反射功能,首先写了几种模式的任务类,然后在xml配置文件里对这些类进行配置,任务程序运行时首先读取xml,根据配置生成任务组,并且实例化,以多线程的方式运行这些类。嘿嘿,顺便配了个短信闹钟,每天早晨给我发短信叫我起床。
心得:摆脱数据库对思维的限制,摆脱写软件先设计表,考虑表结构的思想,运用面向对象的思维方式,把主要精力转移到完成主要功能上来,另外任务模块在设计上还不完善,找时间改成组合模式,这样任务的耦合度就更小了,还有,是不是增加个网络服务功能呢?开个端口监听请求,根据请求完成任务,或者是采用ejb的方法,分布式?各有优缺点,网络服务方式好处是通用性好,无论采用什么语言开发的,都可以调用,方便其他同事以后的开发,分布式的好处是可以远程调用java对象,以后开发起来更灵活,功能更强大,可以组合各种功能组件快速实现任务,而且组件积累到一定的量,就会从量变到质变,到时候会发生什么呢?没想好,继续!继续!!
|
|