|
|
實現的功能：定期搜索發送任務表，按照指定的電話號碼，發送指定內容，支持小靈通。
涉及到的內容：程序對短信設備的控制，pdu編碼解碼，設計模式
遇到的問題：
1、短信設備提供的是串口接口，因為傾向于跨平臺運行這個軟件，所以采用了java作為開發工具，但是帶來的問題是java對window和linux平臺提供的串口api不同，方法也不一樣，而且如果以后根據需要，增加短信設備的話，也受到服務器提供的串口的限制。所以采用了以太網控制方式，為短信設備增加了一個RS232轉RJ45的32口串口服務器這樣就可以通過以太網來控制串口設備了，而且串口設備可以無限增加。但是這樣又帶來了另一個問題：發送什么格式的數據包才能被串口設備識別呢？我在這個地方花了些時間，串口以太網轉換器隨機附帶了一個串口模擬軟件，運行后可以從超級終端控制短信設備，然后根據這個線索，使用wireshark抓包工具對通訊中的包進行了分析，找到了對短信設備初始化的格式包，問題解決。
2、設計模式真是個好東西，優雅的解決事務問題。使用觀察者模式負責對短信設備的監聽，代碼簡約干凈，使用工廠模式，解決了對象創建混亂的問題。
3、項目初步完成后，領導又連續提出了新的要求，需要短信設備完成的功能更多了，幸虧當時把短信監控發送單獨抽取了出來，哈哈，只要把需要短信設備完成的工作添加入發送表就可以了，但是如何管理這些增加的任務呢？每提出一個要求就寫一個程序也太累了，而且以后如果數量增加了，管理也是一個難題。我充分利用了java的反射功能，首先寫了幾種模式的任務類，然后在xml配置文件里對這些類進行配置，任務程序運行時首先讀取xml，根據配置生成任務組，并且實例化，以多線程的方式運行這些類。嘿嘿，順便配了個短信鬧鐘，每天早晨給我發短信叫我起床。
心得：擺脫數據庫對思維的限制，擺脫寫軟件先設計表，考慮表結構的思想，運用面向對象的思維方式，把主要精力轉移到完成主要功能上來，另外任務模塊在設計上還不完善，找時間改成組合模式，這樣任務的耦合度就更小了，還有，是不是增加個網絡服務功能呢？開個端口監聽請求，根據請求完成任務，或者是采用ejb的方法，分布式？各有優缺點，網絡服務方式好處是通用性好，無論采用什么語言開發的，都可以調用，方便其他同事以后的開發，分布式的好處是可以遠程調用java對象，以后開發起來更靈活，功能更強大，可以組合各種功能組件快速實現任務，而且組件積累到一定的量，就會從量變到質變，到時候會發生什么呢？沒想好，繼續！繼續��！
|
|
