構建電信計費系統、保險系統、金融等交易系統之所以復雜,除了對諸如高性能、高可靠性、高可用性、高安全性、高擴展性的要求外,另外至關重要的原因是這些 領域存在大量的業務規則,這些規則千差萬別,甚至是相互沖突的(瞧瞧電信資費就知道有多么復雜)。在市場驅動的情況下,系統架構和模型必須對客戶、競爭對 手、合作伙伴和整個市場情況的各種變更及時響應,同時將這些變更產生的需求作為業務規則體現到系統中去。從業務的角度看,業務規則是一種原則,包含在特定 活動或范圍內關于指導、操作、實踐或過程的行為規范;從信息系統的角度看,業務規則是一個定義或限制業務某些方面的聲明。一個業務規則包含一組條件和在此 條件下執行的操作,它們表示業務規則應用程序的一段業務邏輯。業務規則通常應該由業務分析人員和策略管理者開發和修改,但有些復雜的業務規則也可以由技術 人員使用面向對象的技術語言或腳本來定制。業務規則的理論基礎是:設置一個或多個條件,當滿足這些條件時會觸發一個或多個操作。
1、應用場景:
- 電信計費費率模型
一次批價:根據預處理提供的標準格式話單,結合費率表、號段表、區號表等計費資料對話單進行計費。費率表中記錄的信息主要有:基本計費單元、基本通 話費率、長途計費單元、長途通話費率、優惠時段起始時間、優惠時段終止時間、優惠時段費率等等。號段表記錄了IMSI號、MSISDN號所對應的歸屬地, 以此來判定用戶的歸屬地,進而判定出用戶是否漫游、是否撥打了異地手機而應收取長途費等等。區號表記錄了各個長途區號,用以從用戶所撥的對方號碼中提取出 長途區號供計費使用。
二次批價:在一次批價的基礎上,根據用戶入網所享受的各項優惠對話單進行重計費,以最終生成向用戶收費的話單。用戶所享受的各項優惠記錄存在營業系 統的用戶資料中,因此二次批價必須結合營業資料進行。二次批價使是一個耗時耗資源的過程,一般在合帳前集中完成,為了提高速度,將二次批價中需要頻繁用到 的營業資料載入內存中。
- 信用卡積分規則
憑XX信用卡消費1元人民幣,即可獲得1分的消費積分,在汽車類商戶每消費100元人民幣積8分,在房地產類商戶每消費100元人民幣積6分。 兌獎規則:100分~300分:兌換150元禮品,300分~500分兌換300元禮品,500分以上兌換400元禮品。
2、規則引擎
規則引擎的設計目的是使得規則的創建和維護變得簡單,方便和代價低。好的規則引擎應該將業務邏輯的定義從一個系統中分離出來,而不是在代碼中固化。 同時規則引擎也將系統開發或者集成過程中不同角色的工作耦合程度大大降低,使得業務邏輯開發人員和具體系統開發等人員的工作可以接近并行的進行。在參考文 檔中有業務規則引擎基礎較為詳細的描述。
3、規則引擎使用思考
基于drools+MVEL或ognl來構建核心的業務規則處理部分。
需要考慮解決的幾個問題:
- 性能及壓力測試。對于像企業應用問題還不大,但對于在線實時交易系統,盡管可以預先編譯規則,但規則引擎是否會成為性能瓶頸。
- drools與db的結合、內存數據庫(berkeleydb)的結合
Loading and managing rules dynamically from a database
- 與mule及SoA框架結合,用于做對外接口
- 規則引擎用于系統部署及內容分發
5、參考資料
http://java-source.net/open-source/rule-engines
http://www.manageability.org/blog/stuff/rule_engines/view
http://www.ibm.com/developerworks/cn/java/j-drools/index.html
http://java.ccidnet.com/art/3737/20060427/531321_1.html
http://www.onjava.com/pub/a/onjava/2005/08/03/drools.html
http://www.infoq.com/articles/Brasilian-Healthcare-System
Technorati 標簽:
業務規則引擎
,
rule engine
,
電子商務
,
drools
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號聯系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
