規則引擎在基礎軟體,或者在很多系統中已經不是稀奇的玩意,最近這幾年,國内不斷興起很多的規則引擎,至于什麼是規則引擎,在這篇文章中,就不做介紹了,我想能看以下内容的,多少對規則引擎也都有所了解了。
國内在2003年的時候,出了第一款商業規則引擎—旗正商業規則引擎(VisualRules),為什麼這麼說呢,因為再此之前,國内所用的規則引擎,都是國外産品,或者開源産品,純自主研發旗正是第一款,直至目前為止,純自主研發的規則引擎少之又少。那麼旗正商業規則引擎到底怎樣?今天,給大家介紹一下,順便,我們拿出和DROOLS和其它幾款規則引擎跑出的資料來一起看看。
我們通過實際測試操作,讓旗正規則引擎(VisualRules)和其它幾款主流規則引擎進行性能分析對比,并展示處理速度,記憶體占用,正确率等各項名額,分别來觀察規則引擎的綜合性能。
一、本地化
1.中文化需求
VisualRules相關的各個軟體以及相關的教育訓練和幫助材料等,以全部中文化的方式進行描述,在各個詞彙以及功能的設計上,都是從中文的特點來出發進行設計的。
這一點在規則引擎的核心功能(業務語言描述業務邏輯)上展現的特别明顯,VisualRules采用全中文化的語言來描述業務邏輯。不像JRules等采用純英文(TRL是純英文、教育訓練和教程為全英文)、BRL(一般是英文,通過處理可以是翻譯後的中文)等方式來描述業務邏輯,在表述上總會有一些牽強。
2.對使用者的要求
由于VisualRules從中文出發來設計和實作,并且從一開始就考慮了業務人員使用的要求,是以學習曲線非常低,對使用者的要求低。在業務規則的查閱以及修改方面,普通的有大專以上水準的人就可以快速的學會使用。在業務對象的設定以及業務規則的建立方面,學過計算機進階語言的人都可以快速學習掌握。這在使用者教育訓練上占用很大的優勢,大大的節約了教育訓練的成本。
而JRules等産品,一般除了要求使用者有較高的英文水準之外,還需要學習其專業的規則語言,需要經過一個比較長時間的教育訓練才能掌握。
二、安全性
1.政治風險
旗正公司是完全的國内企業,而且得到了國際科技部和财政部的創新基金支援,不存在政治風險。而國際公司會受到外國政府的關于高新技術出口政策的限制,會有一定程度上的政治風險。
2.洩密風險
業務規則管理系統不像資料庫,是一個完全獨立成熟的産品,可以不涉及業務。業務規則管理系統的行業型特色非常強,總是需要針對行業的特點做一些完善和優化。特别在實作一些特殊需求或者涉及到性能優化等問題時,肯定需要規則引擎廠家的支援。由于國家稅務是涉及國家安全的東西,是以如果采用國際産品,洩密的可能性會增加。
3.源代碼
考慮到國稅系統的安全性考慮,旗正公司可以根據國稅部門的需要開放與業務規則運作相關的源代碼,以保證國稅系統可以安全放心地用規則引擎來執行各業務規則和政策。
而國際産品一般不會提供規則引擎的源代碼,這樣由于國稅部門的特殊性,使用後可能會存在一定的風險。
三、性能測試對比
場景說明:準備10萬條基礎資料,生成中間資料300萬條,執行20條規則,寫入資料庫20萬條,通過不同的幾款主流規則引擎對比,可以看出旗正規則引擎的優勢。
1.規則執行速度

VisualRules從一開始就關注性能的問題,目前已經将規則的執行,從解析執行發展到編譯後執行,這樣的執行速度在所有的規則引擎的實作中是最快的。JRules等産品,雖然目前也做了此方面的優化,但是隻是做到了部分編譯後執行,是以在速度方面并不具有優勢。
2.記憶體占用
為了能讓性能發揮更好,我們在軟體開發之初就制定了高标準要求,經過多年的不斷研發和改善,旗正規則引擎在記憶體使用上成功超越了其它主流産品,這也是保證了我們産品擁有更好的穩定性。
3.CPU使用率
4.資料處理正确率
四、服務和支援
由于旗正公司是完全的國内企業,在服務以及技術支援上會更加的便利。
1.二次開發,業務系統內建性
由于業務規則管理系統不同于資料庫等産品,業務規則管理系統肯定會根據具體業務規則的特點,在管理上會有所不同。是以管理系統會需要和業務系統結合,以滿足業務系統的需要。
旗正公司可以派核心的開發人員和業務系統的開發人員一起制作和完善特定行業的規則管理系統。并且将規則管理系統和業務系統更好的內建。
2.服務價格,維護更新
由于旗正公司為完全的國内公司,在服務價格上會明顯的低于國際公司。而且在後期維護更新上,也會優先考慮國稅部門的需求。
而國際産品可能會優先考慮自己國家的要求,并不會像旗正公司一樣重視國稅部門的需求。
五、易用性
VisualRules從産品最初設計開始,就非常關注如何使使用者使用簡便,減少使用者的工作量。
在使用者的操作界面上,VisualRules對不同的操作員針對性的提供一些特定的功能。比如為開發人員提供了生成開發人員所熟悉的java語言,讓開發人員可以用自己熟悉的語言更加深入的了解業務邏輯;為業務人員和管理人員提供了業務語言和流程圖,可以用業務人員自己的語言來了解業務邏輯。另外VisualRules還提供了規則樹的功能,就是可以以樹狀的形式定義了相關規則的互相關系,包括公共條件關系、循環關系、先後關系等。讓使用者在編輯規則階段,就清晰的指導了規則執行的流向。
VisualRules針對國内項目基本都是基于資料庫系統的特點,內建了資料庫層,并且實作了資料庫層的随時變更。還增加了大量的向導功能,以幫助使用者可以非常友善的在規則中操作資料庫。另外又可以讓使用者可以直接在編輯界面執行規則,這些規則執行的資料可以是測試資料。同時又提供了資料查閱的功能,可以直接在編輯界面就可以看到原始資料和規則執行後的結果資料。這些功能都使得使用者可以非常友善的定制規則。
VisualRules針對規則變化時,可能導緻規則包接口的變化。将接口采用map方式來存儲,這樣就使得所有規則包的接口都可以随時修改。同時結合了代碼生成技術,可以為技術人員生成其他相關的程式代碼,包括jsp代碼、以及其他的java類代碼。這樣可以讓技術人員僅僅通過配置頁面,就可以生成一個完成的調用規則的應用。
VisualRules針對不同的使用者,提供了不同的版本,下面講述具體版本中VisualRules有具有的優點。針對技術人員,VisualRules提供了規則編輯器開發人員版,開發版有如下優點:
1.單個檔案集中管理規則包相關的所有規則和業務對象
開發人員可以在同一個規則包中,處理和此規則服務相關的所有參數、資料來源、技術和業務詞彙、業務規則。
而JRules等産品,卻需要在不同的地方定義XOM、BOM、RULESET、RULE等,你很難在一個統一的地方全面的把握住該規則服務所需要的所有的業務規則和業務對象。集中統一的管理,可以極大地為使用者提供便利,減少開發工作。
2.面向規則包的版本控制
同時集中統一的管理也為規則包的整體版本控制提供了可能。很多實際業務要求,同一規則服務,會在不同的時間段或者不同的條件下,會調用不同的版本(也就是具體其中某幾個規則會有所不同),而這幾個版本可能是同時都要有效的。是以需要針對規則包進行統一的版本控制。
而目前像JRules等産品,隻能提供規則級别的版本控制,不能做到整個規則包級别的版本控制。
3.規則分值、循環類規則
在實際的業務規則實踐中,總是會出現某些規則是隻有滿足某個公共條件才觸發的,也會出現某些規則是在某個循環中的。VisualRules可以在規則集中設定公共條件或者是循環條件,以滿足規則集下面的所有規則必須滿足公共條件才能執行,或者是循環執行的。
而像JRules等産品的規則集,不能設定工作條件和循環條件,是以JRules不能對規則的執行進行有效的分支控制。很多時候其需要通過為每個規則設定大量的條件或者通過臨時變量等變通的方式來解決,這樣的解決方式非常牽強,就不能展現業務語言表述業務邏輯的特點了。
4.編輯階段的java代碼對照生成
由于技術人員使用規則編輯器,其更多的關注實際業務邏輯對應的技術映射是否正确,是以技術人員更加關注業務邏輯對應生成的java程式代碼,而技術人員如果已經有java語言的基礎的話,那麼檢視生成的java代碼會比看中文化業務邏輯更加直覺和便于了解。其原因也顯而易見,因為中文描述的業務邏輯,同樣一句話可能在不同的環境下,是不同的技術實作。是以如果要關注具體的實作細節,則需要檢視實際的代碼。VisualRules可以自動實時的生成對應的java代碼,這會在測試以及查錯方面給予很大的幫助。
而JRules等産品,隻能看到TRL語言,這就要求技術人員重新學習一種新的語言,也不好了解。
5.規則包整體測試
VisualRules可以在編輯環境下,直接對規則包進行整體測試。測試時隻需輸入所需的參數的值,就可以檢視到輸出結果,以及可以看到整個規則執行路徑以及對應的資料變化情況。這樣就可以非常友善的對規則包進行測試檢查,或者對下面的某個規則或者規則集單獨進行檢查。
而JRules等産品必須要在eclipse等開發工具下,單獨編寫相應的java程式來驅動規則包的執行以及進行調試測試,這使得測試等工作變得非常困難(比當初采用編碼方式實作業務邏輯進行調試一樣困難)。
6.規則集、規則的單元測試
VisualRules可以在編輯環境下,對規則集、規則、決策表等進行單元測試。這樣就使分塊查錯變得非常容易。
而JRules等産品根本不支援單元測試等操作,除非另外增加一個隻包含需要測試的規則的規則包來進行測試,這樣就變得非常困難。
7.規則執行軌迹跟蹤
當規則包被調用時,有時候使用者需要知道這次調用到底激活了那些規則,他們的先後執行順序,以及調用此規則時,對業務對象的修改情況(進規則之前,業務對象什麼狀态,經過規則執行之後,業務對象變成了什麼狀态)。VisualRules可以将所有當次運作的這些規則執行軌迹記錄下來,供使用者進行查閱,或者存儲在資料庫中,供以後查閱。這在使用者進行規則的查錯時非常有用,可以馬上定位到底是運作到那個規則時,發生了錯誤。
而JRules等沒有提供這方面的功能。他隻能通過調試來實作。
8.規則異常處理
VisualRules可以針對規則定義多種異常處理方式,通過設定規則屬性就可以。這樣就可以在規則内部處理異常情況。
而JRules等隻能在規則包級别進行異常的處理情況。
9.動态的規則包調用接口
VisualRules支援外部調用直接以數值、字元串、類對象等多種方式将參數傳入到規則包中,這樣就使得接口的參數動态化。特别是當采用規則服務方式時,如果變動接口,不用去修改原先調用它的各個程式。
而JRules等必須要以類屬性的方式來傳遞參數,這樣就使得參數的傳遞不能動态化,規則服務接口不能友善的發生變化。
10.動态or映射
VisualRules從一開始就充分考慮基于資料庫的項目的特點,大量的規則判斷依據(比如參數以及原始資料、或者結果資料)都需要來源于資料庫,是以VisualRules在業務規則處理的業務對象中,無縫內建了資料庫層的操作。讓規則操作資料庫中的資料就像處理一個普通的業務對象一樣友善,并且讓資料庫對象也像規則一樣,可以随時改變。
而JRules等産品,卻通過類對象來通路資料庫,這樣就不能使得資料庫對象不能輕易進行變動,也使得操作和通路資料庫變得非常困難。
11.基于JSP的業務系統操作界面自動生成
VisualRules可以在規則編輯界面配置生成調用此規則包的JSP頁面,這樣就可以輕松的完成操作界面的生成工作。這有點類似工作流中的表單設計器。隻不過工作流中的表單設計器,相對參數比較固定,格式也統一。而VisualRules的頁面配置器,卻可以根據模闆設計的不同,而生成針對不同項目特點的頁面。JSP頁面的生成使得測試規則變得更加容易,甚至可以用此功能輕松的開發完成一個完整的基于資料庫的管理系統。
而JRules等工具卻并不提供這類功能。
VisualRules專門針對業務人員提供了 規則配置器編輯人員版,編輯版具有如下特點:
12.帶有使用者身份認證的完整的規則編輯功能
編輯版由業務人員進行使用,必須經過使用者名和密碼的身份認證。這種身份認證可以和業務系統結合。并且通過規則的權限配置設定,使用者隻能檢視和修改自己具有權限的規則。這就保證了規則修改的安全性。
而像JRules等工具并不能為業務人員直接提供一個完整的具有嚴格的身份認證的規則編輯器。其隻能通過其自身的規則管理系統來進行操作。這就使得技術人員和業務人員的操作界面等不一緻,增加了溝通的難度。
13.支援業務人員直接測試規則包和規則
對于規則包的整體測試,或者對于規則、規則集的單元測試,也在編輯版中提供。這樣就使得業務人員直接可以在修改規則的過程中測試規則設定的正确性。
而JRules等産品需要通過調試等手段來檢驗規則的正确,這樣就隻能由技術人員才能測試規則以及驗證其正确性。
14.編輯階段可檢視來源資料
編輯版不能對對象庫中的資料庫層進行操作,也就是說不能直接操作資料庫。但是可以提供功能供使用者直接檢視來源資料,這樣業務人員在編輯規則時,如果需要查詢資料,就不需要通過報表系統去查詢,直接在編輯界面就可以檢視對應的資料庫中的來源資料,這樣可以大大減輕開發的工作。
而JRules等産品,并不提供這類功能。
15.支援多種樣式的決策表
VisualRules針對國内決策表的特殊情況,設計了多種決策表,包括表格類決策表、多元決策表、關聯決策表。當然也可以根據業務系統的實際需要進行擴充。這些不同類型的決策表,使得業務人員可以更加簡單友善的表述業務邏輯。
而JRules隻提供了一種決策表的實作,而且這種決策表在描述國内的業務需求時,并不能很好的進行描述。
16.支援規則包的流程圖顯示
VisualRules可以在編輯階段直接生成一個包含了全部業務邏輯以及流向的流程圖,這個流程圖可以導出成html,發送給相關的人員查閱或者審批。這使得業務人員可以在一副圖中,看到所有相關的資訊,非常符合中國人的思路,易于國人了解。在具體的流程顯示時,還可以将隻有技術人員才關心的一些規則隐藏起來,讓流程圖隻顯示和業務相關的邏輯。
而JRules隻能提供局部流向圖,并不能将具體的規格内容包含在其中,也不能在一副圖中描述整個流向圖。
17.支援使用者修改軌迹記錄
VisualRules在規則編輯階段,在修改使用者的資訊記錄在被修改的規則檔案中。這樣就可以跟蹤到某個規則,在什麼時候被誰進行了修改。
而JRules等産品,卻并沒有對編輯使用者的資訊進行記錄。
總的來說,VisualRules針對國内使用者的特點以及基于資料庫項目的特點,增加了很多易用性方面的功能。這些功能大大的簡化了使用者的工作,真正的将業務規則的編寫可以由業務人員來設定和審閱。另外VisualRules可以針對國稅系統的情況,完善國稅系統所需要的各項功能,以求最大限度地滿足國稅系統的需要。