業務規則管理系統的基本原理是：用一個或多個規則引擎替換以程序代碼“固化”在應用系統中的業務邏輯。一個完善的BRMS可以對業務規則的整個生命周期實現全程管理。

業務規則的全生命周期管理如圖1所示。BRMS在應用系統中的地位與數據庫管理系統（DBMS）類似，處于比較基礎的位置，是其他高端應用的基石。圖2是GIGA Information Group 給出的IT架構中BRMS的位置圖。

業務規則管理如何實現？

業務規則

一個業務規則包含一組條件和在此條件下執行的操作，它們表示業務規則應用程序的一段業務邏輯。業務規則通常應該由業務分析人員和策略管理者開發和修改，但有些復雜的業務規則也可以由技術人員使用面向對象的技術語言或腳本來定制。業務規則的理論基礎是:設置一個或多個條件，當滿足這些條件時會觸發一個或多個操作。

規則引擎

這是一種嵌入在應用程序中的組件，它的任務是把當前提交給引擎的數據對象與加載在引擎中的業務規則進行測試和比對，激活那些符合當前數據狀態下的業務規則，根據業務規則中聲明的執行邏輯，觸發應用程序中對應的操作。

目前主流的規則引擎組件多是基于Java和C++程序語言環境。在2000年11月，Java Community Process（簡稱JCP） 組織開始著手起草Java規則引擎的API標準，即JSR 94 規范。參與JSR 94起草的有BEA、IBM、ILOG、甲骨文、Novell、ATG、Unisys、Fujitsu等著名的軟件企業。JSR 94 在2003年11月25日正式定稿，支持JSR 94標準的規則引擎也幾乎同時推向市場，包括ILOG 的JRules和Blaze的Advisor。

規則引擎的使用方式

由于規則引擎是軟件組件，所以只有開發人員才能夠通過程序接口的方式來使用和控制它，規則引擎的程序接口至少包含以下幾種API：加載和卸載規則集的API；數據操作的API；引擎執行的API。開發人員在程序中使用規則引擎基本遵循以下5個典型的步驟：創建規則引擎對象；向引擎中加載規則集或更換規則集；向引擎提交需要被規則集處理的數據對象集合；命令引擎執行;導出引擎執行結果，從引擎中撤出處理過的數據。使用了規則引擎之后，許多涉及業務邏輯的程序代碼基本被這五個典型步驟所取代。

一個開放的業務規則引擎應該可以“嵌入”在應用程序的任何位置，不同位置的規則引擎可以使用不同的規則集，用于處理不同的數據對象。此外，對使用引擎的數量沒有限制。

規則引擎的內部實現

規則引擎的基本機制是：對提交給引擎的數據對象進行檢索，根據這些對象的當前屬性值和它們之間的關系，從加載到引擎的規則集中發現符合條件的規則，創建這些規則的執行實例。這些實例將在引擎接到執行指令時、依照某種優先序依次執行。一般，規則引擎內部由下面幾個部分構成：工作內存，用于存放被引擎引用的數據對象集合；規則執行隊列，用于存放被激活的規則執行實例;靜態規則區，用于存放所有被加載的業務規則，這些規則將按照某種數據結構組織，當工作區中的數據發生改變后，引擎需要迅速根據工作區中的對象現狀，調整規則執行隊列中的規則執行實例。規則引擎的結構示意圖如圖3所示。

任何一個規則引擎都需要很好地解決規則的推理機制和規則條件匹配的效率問題。

當引擎執行時，會根據規則執行隊列中的優先順序逐條執行規則執行實例，由于規則的執行部分可能會改變工作區的數據對象，從而會使隊列中的某些規則執行實例因為條件改變而失效，必須從隊列中撤銷，也可能會激活原來不滿足條件的規則，生成新的規則執行實例進入隊列。于是就產生了一種“動態”的規則執行鏈，形成規則的推理機制。這種規則的“鏈式”反應完全是由工作區中的數據驅動的。

規則條件匹配的效率決定了引擎的性能，引擎需要迅速測試工作區中的數據對象，從加載的規則集中發現符合條件的規則，生成規則執行實例。1982年美國卡耐基·梅隆大學的Charles L. Forgy發明了一種叫Rete算法，很好地解決了這方面的問題。目前世界頂尖的商用業務規則引擎產品基本上都使用Rete算法。

BOM賦予規則行業特性

業務規則一定是針對某種業務的，不同的業務有自己特有的業務模型——業務對象模型（Business Object Mode，簡稱BOM）。BOM為業務規則語言提供了絕大多數的詞匯，多由業務系統分析員設計，由開發人員具體實現。從面向對象的編程角度來看，BOM就是一個簡化的類圖，類圖中有類名、類的屬性、類的方法等。這些要素都將是業務規則語言中的基本“詞匯”。BOM的來源可以是Java對象模型、C++對象模型、XML Schema、Web服務定義等。

假定我們有一個簡單的寵物商店購物車應用程序，在這個應用程序中，顧客能夠在購物車中放入各種寵物和相關物品對象。這個應用程序的業務對象集合就可以有ShoppingCart(購物車)、Customer(用戶)、Item (條目)和ItemType(條目類型)這幾個類。

表述業務規則的語法就是業務規則語言。由于規則語言的使用者主要有兩類:業務人員和技術人員，所以規則語言一般也分為兩類：“面向程序技術”的規則語言，它技術性很強，可讀性較弱，比較適合IT 技術人員使用，一般每個規則引擎開發商都有自己的一套“面向程序技術”的規則語言語法，不過OASIS組織定義了不同應用情況下的規則語言規范，包括SRML（Simple Rule Markup Language），BMRL(Business Markup Rule Language)和RuleML（Rule Markup Language）等；“面向業務”的規則語言，它是業務人員使用的語言，必須具備非技術性和可定制性，通常它需要經過“翻譯”之后才能被規則引擎解析。BRMS必須提供這種“翻譯”機制，而開發人員要實現從“面向業務”規則語言到“面向程序”規則語言的映射。

“面向業務”的規則語言無論從語法上還是語句結構上都可能千變萬化，不同行業可能有自己的“行話”。一個好的BRMS應該提供一個完善的規則語言框架，能夠迅速地為業務人員定制不同的“行話”，否則業務人員還是無法真正成為業務規則的主人。

“單純”的規則如何互連?

業務規則有一個非常明顯的特性：單純性。每個業務規則只描述自己特有的條件和滿足條件的操作，業務規則本身并不關心它與其他規則的關系，如優先關系、互斥關系、包含關系等。每個業務規則本身可以有自己的屬性，稱元信息，可以用來處理規則之間相關性，例如引擎可以使用規則的優先級來依序執行規則的操作。

有些BRMS還提供一種稱為“規則流”的定制功能。規則流是一個圖表，定義了解決問題或執行業務流程的順序。類似于統一建模語言（UML）的活動圖，由一組任務以及定義這些任務之間執行順序的轉換邏輯組成。一個轉換由條件控制，只有當該限制條件為“真”時才能完成這種轉換。

這些任務可以是規則任務、函數任務或子規則流任務。規則任務包含一組要作為任務主體執行的規則，規則的執行邏輯由用戶設置的任務屬性嚴格控制。這些屬性決定規則的排序、規則觸發策略、執行算法等；函數任務包含要作為任務主體執行的腳本代碼；子規則流任務則包含任務開始后將依次執行的子規則流。

為了方便開發人員和業務人員管理業務規則，BRMS必須提供具有直觀用戶界面的工具來實現業務規則管理。規則管理工具至少應該具備以下功能：規則的定制和編輯、規則流的定制、決策表形式的規則定制、規則的查詢、規則有效期限的控制、規則的組織結構、規則模板的定制、規則庫訪問權限的控制、規則變更歷史的記錄、規則文檔的管理等。

·小資料2·

業務規則管理系統其實是一組工具集，它包括：規則引擎、規則庫、規則語言框架、規則管理集成開發環境。業務規則管理系統的基本工作原理如圖所示。

規則引擎（Rules Engine）

是執行業務規則的軟件組件，它嵌入在程序中，是業務規則管理系統的核心元素。規則引擎的類型有：簡單型、數據中心型和面向事務型。

規則庫（Rules Repository）及其服務機制

用于存儲規則和規則元數據（Meta Data）以及與規則有關的屬性。它提供一組工具用于存儲、分類、查詢、版本控制、權限控制、測試、提交等，規則的狀態和有效性可以跟蹤。規則庫可以依托文件系統或數據庫管理系統。

規則語言框架（Rules Language Framework）

規則語言一般分為兩類：“面向程序技術”的規則語言，使用者是技術人員；“面向業務”的規則語言，使用者是業務人員。規則語言框架則為定制“面向業務”的規則語言提供支持。

規則管理工具（Rules Management Tool）

用于管理、創建、修改和部署業務規則的圖形化工具，易用性強，除了開發人員外，業務人員也可以使用這套圖形化工具實現對規則的管理。

規則集成開發環境（Rules IDE）

一般規則集成開發環境只有規則編輯器，而高級的規則集成開發環境可以實現對規則和規則庫的管理：如規則的創建、分類、檢索、修改、版本控制、權限管理等；甚至可以實現對多個規則引擎的“在線”調試；對規則集合進行沖突檢查等。

一個完整的BRMS應該提供規則管理（Rules Management）、規則部署（ules Deployment）、規則分析（Rules Analysis）、規則定制和設計（Rules Design and Authoring）等功能。

（計算機世界報 第14期 B6、B7）