摘要:本系統主要針對電信系統的固定電話業務的收費設計研發了一套解決方案,通過對國內外同類電信系統的了解以及對電信業務流程的調研,整理出一套基于數據生命周期的計費模型,并將固定電話業務的計費統一到這一計費模型當中,實現費用的相對獨立的同時又能夠進行復雜的組合統計分析。采用J2EE作為系統實現的主要技術規范,使系統具有較強的可重用性、伸縮性和透明性。
關鍵詞:輕量級開發平臺 J2EE 固話計費
一、電信計費系統的研究現狀
隨著企業信息化系統的迅速普及,各企業逐步淘汰了原有的以紙質檔案為基礎的信息處理。此類系統在企業中的應用對于提高企業的管理水平和工作效率,降低人力及相關資源成本的消耗,提高業務處理效率,有著十分重要的意義。
與此同時,用戶對企業服務的需求量也在高速的增長中,傳統的企業信息處理方式已經完全不能滿足需求,繁雜低效率的業務處理會降低用戶的滿意度,影響企業形象。而信息化的企業管理系統能夠有效地縮短用戶申請辦理業務的等待時間,提升用戶體驗,正是對這一現狀的有力改善。
此外,在開發本項目的過程中,著重對與電信服務商業務處理系統相似的系統研發進行研究,探索同類項目的技術選型,開發過程模型,對未來可能出現的類似需求能夠及時應對并提出合理的解決方案。
二、固話計費系統的可行性分析和技術選型
1.系統的可行性分析
在業務員的終端是安裝了Windows環境的PC機,用戶也非常容易接觸到Windows環境的PC機。主要目的是向中國電信的服務器傳遞數據。當用戶在查詢自己個人信息、業務信息,業務員查詢客戶信息時,終端向服務器發出查詢請求,服務器根據用戶信息庫的實時數據,向終端發送數據,顯示在終端的屏幕上。當增加新用戶時,業務員需向終端向服務器提交正確的信息單(必填項必填),服務器核對后,存入客戶信息庫,并建立相應的客戶信息。當用戶需要查詢信息時,輸入賬號及客戶密碼后,終端向服務器發出查詢請求,服務器接收后,查詢用戶信息庫,核對后傳送給用戶,終端顯示所需信息。如果是業務員可以輸入管理員密碼,對用戶信息進行相關修改,修改后向數據庫提交并保存修改后數據。
由于企業信息管理系統的信息量龐大,并發性高,如果采用原有的C/S(客戶端/服務器)架構,則勢必需要在硬件設施上耗費大量成本才能滿足需求,采用基于J2EE平臺的B/S(瀏覽器/客戶端)架構能夠在保證性能需求的前提下降低硬件成本的消耗,這一方案在國內外已有大量成功的項目經驗。
2.系統的技術選型
J2EE平臺。本系統涉及電信運營商的業務數據,因此對于安全性,執行效率方面的要求較高,經過對當前業界流行的幾大技術平臺的橫向比對,決定采用J2EE平臺作為最終的技術平臺。由此可使本系統具備如下特征:
(1)高安全性。J2EE常年以來被應用于銀行金融等安全性要求十分嚴格的行業當中,平臺本身已經高度成熟化,具備一套完善的安全解決方案。而電信計費系統由于具備金融屬性,因此正需要J2EE平臺先天的安全屬性來省卻不必要的安全維護成本。
(2)高并發性。電信企業用戶數量龐大,J2EE系統在經過多年的行業檢驗后已十分成熟,可以經受大量用戶的高并發訪問。
DBCP數據庫連接池。在數據源方面,決定采用Apache的DBCP開源數據庫連接池實現。由于建立數據庫連接是一個非常耗時耗資源的行為,所以通過連接池預先同數據庫建立一些連接放在內存中,應用程序需要建立數據庫連接時直接到連接池中申請一個就行,用完后再放回去。
Struts1.3.8。為保證系統的可擴展性,整體架構的健壯性,需要引入一組MVC框架實現,通過對目前業界流行的MVC框架的比較,決定采用Struts1.3.8作為本系統中的MVC框架。
充分利用struts1.3.8內建的MVC實現系統之間的松耦合,使得處理電信計費這樣的復雜業務時不會過多增加代碼復雜度和維護難度。
Resin。為保證系統的運行效率因此在后期部署時需要采用Resin應用服務器來代替開發期的Tomcat。前者盡管在開發期的控制臺直至熱部署支持等方面還存在問題,但它在運行期的高效率始終是不能忽視的。
在開發過程中采用Tomcat,是為提高開發期效率,利用tomcat完善的日志和報錯機制,降低程序開發和調試的難度。而采用Resin代替tomcat主要是基于以下兩點考慮:
(1)Resin相對于tomcat而言,運行時效率更高;
(2)Resin的部署成本相對于WebLogic等大型服務器而言比較低。
三、系統核心計費模型的算法實現
本系統為了最大限度地保持持久層的輕量級,因此沒有加入獨立的持久層組件,而是通過統一的通用持久層工具來實現,提供配置文件的解析功能,在項目部署運行時可以按照實際情況調整數據庫的基本配置。
整個系統設計方案的重點放在了對電信業務流程和組織結構的分析和整理之上。固定電話,移動,寬帶,三大業務體系及相互隔離(流程),又緊密關聯(客戶信息處理,費用記錄統計)如何能夠更好的整理業務之間的關聯,在保證系統靈活性,能夠適應不斷發展的電信業務模型的基礎上,又能夠最大限度地減少二次開發的不必要成本。
同理,在本系統的核心費用記錄模型中也采用了這一實現,將當天產生,還未經過清算的數據放在費用記錄應收表中,而將該部分數據在生成后的短時間內有可能進行清算,取消計費,抹賬,報表查詢,統計中間數據分析等各項操作,這些操作大都只針對當天,或近幾天的數據進行。在這之后,以天、周或月為單位(具體周期依實際情況而定)對應收表中的數據進行結算,并轉移到費用記錄實收表中去。這樣一來,始終保持費用記錄應收表只存在很小量級的數據,從而大幅度提高了查詢效率。