更新業務流程的平均週期已經從1980年的84個月縮短到了現在的6個月，而且IT解決方案交付週期也從30個月縮短到了3個月（參見圖1）。在銀行業也是這樣。其中的核心元素包括銀行業的工業化、消費者需求的更改、競爭的日趨激烈以及政府調控的影響。另外，銀行的業務環境和操作流程也在不斷變化。但是，當試圖使受影響的軟件系統適應這些改變時，出現了很大的延遲。從技術的觀點來看，有高度適應性和靈活性是很有必要的。但是因爲銀行擁有高度異構的系統拓撲，其系統和接口（包含單片主機系統）的數量非常可觀，所以要實現這一點很難。
圖1. 1980年以來業務流程週期和IT解決方案交付週期的發展
面向服務的架構(SOA)能提供調整業務流程和技術實現過程中所需的靈活性。此處對帶有封裝的功能的服務進行了定義，這些服務通過標準化的接口和協議（如SOAP、WSDL、UDDI或J2EE連接器架構）訪問各種系統（可能包括現存的系統）的功能。通過將服務封送或“編排”進可執行的業務流程中，SOA可參考業務用戶的觀點對技術觀點進行調整。目前，業務流程建模是基於所謂的“工作流管理系統”完成的。在建模過程中，會將業務流程映射爲描述語言（已標準化或正在標準化）。利用這一點，無需“硬編碼”即可對業務流程進行調整，從而在運行時即時滿足各種新要求。在《BIT》雜誌的“銀行業與信息技術”（2004年第2卷第3期）中，討論了此架構在銀行中與各種工作流符號（如eEPK、UML活動圖、BPEL、XPDL以及JPD）結合的一個實現。
爲了提高業務流程實現的抽象層次和靈活性，業務規則引擎可以部署在SOA框架內。這些規則引擎將業務流程內的決策從用編程語言完成的實際實現隔離開來。
業務規則與企業平臺
在分析例子之前，有必要了解一下“業務規則”這個術語的含義以及此領域已有的標準。
業務規則
對於銀行而言，管理機構、競爭對手、客戶和整個市場情況不斷帶來各種變更，必須將這些變更作爲業務規則。業務規則專家組 (BRG) 規定了業務規則的兩個定義。第一個定義與業務觀點相關，而第二個定義與IT相關：
- “從業務的角度看，業務規則是一種原則，包含在特定活動或範圍內關於指導、操作、實踐或過程的行爲規範。”
- “從信息系統的角度看，業務規則是一個定義或限制業務某些方面的聲明。業務規則旨在用於斷言業務結構，或者控制或影響業務行爲。”
運行時，規則引擎 必須對這些業務規則進行解釋。可以將規則引擎理解爲一種高性能的專用解釋程序，其中包含if-then命令，可根據預先定義的規則對轉換的值和對象進行分析，然後返回修改後的值和對象，或直接執行操作。因此，大多數規則引擎使用“Rete” 算法，並支持演繹和歸納。
爲了彌合業務觀點和IT觀點間的差距，就產生了對業務規則管理系統（BRMS）的需求。在BRMS中，會將公司使用的策略和過程進行結合，以管理業務規則的整個生命週期。因此，受影響的部門和非IT人員必須能夠實時地修改IT基礎架構，以適應一般條件和策略。
企業平臺
企業平臺（EP）可以看作SOA集成開發與運行時環境，這個環境涵蓋了全公司範圍的IT基礎架構。此類平臺的功能分佈在三個層次：門戶層、集成層和應用程序服務器層。
門戶層實現所有相關的信息和應用程序“單點訪問”，保證真正單點實現客戶、業務合作伙伴及員工訪問。門戶和有關資源的訪問權由用戶角色決定，以方便內容管理和實現個性化。
集成層提供所有需要的服務，用於連接應用程序、業務流程和業務合作伙伴，以及在各種應用程序間進行數據集成和數據轉換。
應用程序服務器層是企業平臺的基礎。應用程序服務器必須滿足與（全局）事務的實現、管理和協調有關的所有要求，並提供高性能、高可用性和可伸縮性。
標準
廣泛使用異構計算機系統，則意味着要採用標準，以達到必要的互操作水平。通常將互操作性理解爲通信和協作的能力，可允許一個系統內的應用程序訪問另一個系統內的數據或程序。使用標準的另一個目的是定義通用接口，以支持對互操作進行編程。
Java Specification Request (JSR) 94描述了軟件工程師如何通過API將規則引擎集成到應用程序中，以及規則引擎供應商必須如何實現此類API。
不過，JSR 94沒有提供描述業務規則的定義。JSR 94的目標是在不確定規則引擎供應商的情況下幫助把規則引擎集成到Java 應用程序中。JSR 94沒有爲任何類型的業務規則（如，基於XML的、基於統一數據的或基於對象模型的）指定描述語言。
規則集的實驗性實現
現在把我們的注意力轉向規則集的一個實驗。我們將首先研究實驗本身，然後再分析其在WebLogic Portal 8.1和ILOG Jrules中的實現。
場景
我們的實驗解決兩個問題。首先是採用“push 概念”的方式進行面向事件的客戶處理，即根據其在EP門戶內的需求主動處理客戶。在面向事件的客戶處理的上下文中，會利用基於用戶給定的事件的業務規則，向已登錄的用戶顯示個性化的內容。此類規則與以下所示類似：
如果用戶具有影響信用額度的“change of house”事件，而此事件尚未發生，則將向年滿18歲或18歲以上的用戶顯示一個信用額度啓事。
該規則轉換爲ECAA符號（Event, Condition, Action, Alternative Action）如下所示：
| ON | Change of house |
| IF | Customer credit-worthy AND above 18 AND not yet addressed |
| DO | Show credit advertisement |
| ELSE | --- |
其次，是在集成層內將規則引擎（各個業務規則）集成到業務流程的建模和運行庫中。這是基於在線貸款業務流程實現的，此流程中具有自動信用確定功能和後臺辦公流程（在此處通過規則引擎進行決策）。
我們的目標是在WebLogic Platform 8.1和ILOG JRules中實現所有這些問題。
利用BEA WebLogic 8.1 Service Pack 3進行實現
門戶規則服務屬於Weblogic Portal 8.1，用於在門戶應用程序中實現個性化。它的實現需要藉助不同組件：
user segments、campaigns、content selectors以及Java Server Pages (JSP)內的個性化標籤。
WebLogic Workshop 8.1具有合適的用戶界面，利用此界面，可以在很高的抽象層次上更改這些組件。更重要的是，2004年發佈的Service Pack 3能提供對附加組件的API訪問，可直接訪問基礎規則引擎。這就是規則控件和“RulesManager” Enterprise JavaBean (EJB)。
WebLogic Portal 8.1規則包含稱爲規則集的XML文檔。規則集的基本設置如下所示：
<ruleset>
<rule>
<condition>
Left Hand Side expression: Event (ON) and Condition (IF)
</condition>
<action>
Right Hand Side expression: Action (DO)
</action>
</rule>
</ruleset>
所有的規則都以ruleset元素內的rule元素的形式出現。此處映射左邊(LHS)表達式，即Event (ON) and Condition (IF)。單獨的元素是condition，在此元素內可以將條件與邏輯運算符鏈接。如果LHS爲true，則將執行RHS（位於action元素內）的Action (DO)。也可以在工作內存中對轉換過的對象進行操作，或在其中創建新對象。不過，可能對象的列表（類型映射）僅限於小部分的類型。
可以從WebLogic Platform 8.1的所有主要組件訪問規則引擎，特別是集成層和門戶層。
由於規則引擎的對象類型數據有限，故而不可能實現在線貸款流程。因此必須將ILOG的規則引擎作爲插件安裝。
利用ILOG JRules 4.6進行實現
ILOG JRules 4.6是一套完整的BRMS，可以將其視爲目前業務規則領域的行業標準。圖2演示瞭如何將BRMS集成到Java 2 Enterprise Edition (J2EE)架構中。
圖2. ILOG Jrules應用示例
圖2摘自ILOG JRules 4.6白皮書。在JRules 4.6中可以使用全部應用程序對象模型，包括所有XML架構。Java和XML對象被組合爲一個業務對象模型 (BOM)。利用BOM，可以將對象及其方法轉換爲自然語言的短語。因此，例如將對象Customer分配給短語“the customer”，將方法getAge分配給“the age of”。則抽象爲自然語言的示例規則如下所示：
If the age of the customer is greater than 18 And ... Then ...
其中，粗體部分顯示的是Rule Builder的既定元素，下劃線部分顯示的是BOM中的翻譯，而斜體部分顯示的是Rule Builder內的用戶輸入。
也可以採用規則集的方式組織這些規則。對象（Java 和 XML）加載到內存中後，就可以根據這些規則集進行運行。然後規則可以操縱或創建任何的對象。規則集和BOM保存在規則庫中。因此，規則管理程序和管理員可以根據其角色對規則進行訪問、更新和部署，從而涵蓋業務規則的整個生命週期（創建、部署、更新、刪除）。
比較
WebLogic Portal 8.1提供了業務規則功能，但到目前爲止，此功能只是用於WebLogic Platform 8.1內的活動管理和用戶分段。Service Pack 3 通過提供API增強了規則引擎的功能。不過，其使用仍然僅限於進行個性化。ILOG JRules 4.6具有無限制的規則引擎，是一套完整的BRMS。
實現的結果表明WebLogic Portal 8.1的規則功能適用於較爲簡單的個性化和活動管理任務。創建和更新活動和用戶分段已集成到WebLogic Workshop 8.1 IDE中，能在高抽象層次執行這些任務，且只能由具有適當權限的人員執行此類任務。不過，只能在WebLogic Platform 8.1環境中部署規則引擎，不能在任何其他供應商的平臺上使用。
對於更復雜的個性化規則（通過結合AND和OR語句），可以使用規則服務定義XML格式的規則集。不過，必須在本機XML中創建和編輯規則。XML編輯器還不足以涵蓋相應的抽象層次，而且，相對於Java代碼映射而言，具有多於三個條件的規則和包含兩個以上規則的規則集都更加複雜化，更加容易混淆。
ILOG JRules 4.6本身就是一個靈活的BRMS，涵蓋了業務規則的整個生命週期。ILOG JRules 4.6內的規則引擎是J2EE應用程序，可以部署到任何J2EE項目。另外，ILOG能輕鬆集成到IDE環境中，可以利用Java控件調用規則引擎。對於較大規模的項目來說，集成和使用ILOG JRules 4.6一類的規則管理系統是可能的，也是值得這樣做的。最後，結果表明，對於面向事件的客戶處理和銀行業務流程工業化二者的實現而言，ILOG JRules 4.6這樣的BRMS是絕對必不可少的。
結束語
如其他行業早期一樣，銀行正面臨將推動該行業進一步發展的結構變更。在這種情況下，銀行業關心的主要問題是業務的劃分、全球跨行業務往來，技術集成以及持續的數字化進程。
爲了應對即將來臨的變更，業務流程（從技術觀點出發）必須不斷靈活且迅速地處理好新的挑戰。解決此問題的可能方法之一就是使用EP和EAI。爲了讓相關部門獲得更強的業務處理能力，必須進一步將業務邏輯從IT和實現端分離。利用業務規則和BRMS可以做到這一點。ILOG等BRMS可以輕鬆與BEA WebLogic Platform和WebLogic Workshop IDE實現集成。對於想在銀行業以贏家身份出現的企業而言，將這些工具結合在一起使用可以獲得明顯的競爭優勢。
參考資料
- WebLogic Platform 8.1
- ILOG JRules
- Using Rules in Portal Applications
- The Portal Rules Service
- BEA White Paper – Maximizing the Impact of IT Budgets for the Service Driven Enterprise. (PDF)
- JSR 94: Java Rule Engine API
- ILOG JRules 4.6 White Paper
Daniel Jobst在德國的雷根斯堡大學ibi研究中心工作，該中心專門致力於研究銀行業IT與技術革新。其研究的主要領域是企業平臺、集成方案和業務規則管理系統。除了進行研究工作外，Daniel還爲數家銀行提供集成和規則項目諮詢。
Rainer von Ammon自2002年起在上奧地利州應用科學技術大學擔任軟件工程教授，專門研究電子商務基礎架構和分佈式系統。他還擔任德國雷根斯堡大學銀行情報學院研究中心的主任。
Benjamin Gebauer在德國的雷根斯堡大學ibi研究中心工作，該中心專門致力於研究銀行業IT與技術革新。其研究的主要領域是企業平臺、集成方案和業務規則管理系統。除了進行研究工作外，Benjamin還爲數家銀行提供集成和規則項目諮詢。
原文出處
http://dev2dev.bea.com/pub/a/2005/04/business_rules_engines.html