決策剖析
決策服務的用途是基於傳入的惡劣天氣事件，智能地向各個部門生成通知和指令。此規則引擎的輸入和輸出遵守 Common Alerting Protocol (CAP)，這是 OASIS/ITU-T 9 發布的一個 XML 規範（參見 參考資料）。輸入數據包含有關天氣警報的信息，比如降雨和起霧。圖 4 顯示了一個示例 CAP XML 的輸入片段。
圖 4. 輸入 XML 片段
基於這些警報，決策服務制定為各個城市部門生成通知或指令的決策，從 圖 5 中的示例輸出片段可以看出。
這些智能通知和指令由業務規則生成。
圖 5. 輸出 XML 片段
決策服務創建流程
基於規則的開發的一個重要優勢是，它從應用程序代碼中外部化了業務規則，並分離出了開發周期。基於規則的開發將應用程序開發和部署周期與規則的開發和部署跟蹤分離開來。因此，創建基於規則的應用程序的流程不同於傳統的開發流程。創建一個決策服務的流程如 圖 6 中的流程圖所示。可在此流程圖中看到，創建一個決策服務需要規則分析師、規則架構師和業務主題專家協同工作。（查看 圖 6 的更大版本。）
圖 6. 創建決策服務的流程
應用程序開發流程中所涉及的任務包括：
1. 初始化
a. 規則發現
b. 規則分析
c. 準備環境
2. 開發
a. 項目創建
b. 規則設計
c. 規則創作
3. 部署和執行
a. 部署
b. 審計
4. 支持業務用戶
a. 創建場景 Excel 模板
b. 發布到 Rule Team Server
5. 規則維護
a. 編輯/編寫規則
b. 測試
c. 部署
從總體上講，該流程從以下步驟開始：
1. 初始化階段，規則分析師發現並獲取業務策略。
2. 然後分析策略以創建無歧義的業務規則。
3. 規則開發人員使用 Rule Studio 創建規則項目和編寫初始規則集。
4. 然後將規則部署到 Rule Execution Server (RES)，它利用 WebSphere ILOG JRules 的託管透明決策服務 (Hosted Transparent Decision Services, HTDS) 功能來將規則集公開為 Web 服務。
5. 要使業務用戶能夠維護業務規則，需要將規則發布到 Rule Team Server (RTS)。業務用戶不僅可在 RTS 中編寫規則，他們還可使用決策驗證服務 (Decision Validation Service, DVS) 從 RTS 測試這些規則。
6. 準備好後，將規則提取並部署到 RES。
這些流程中每一個的詳細信息都已提供。但是首先有幾點需要注意。
圖 6 中所示的流程圖顯示了創建一個決策服務的典型流程，這就是我們的案例分析中使用的流程。但是，這並不是說這是惟一有效的流程，或者甚至是所有情形的推薦流程。例如，使用一個決策倉庫進行審計是一個可選步驟，組織可選擇跳過。
本文不是一篇詳細的教程，更像一個開發流程示例。它可用作產品文檔的補充，而不能替代它。但是，文中提供了在一個任務中使用 WebSphere ILOG JRules 嚮導時，要輸入到嚮導中的詳細信息。另外，WebSphere ILOG JRules 提供了一個龐大的功能和特性集合，但此流程不會嘗試涉及所有這些功能。例如，我們不會為本案例分析中的 Microsoft Office 或 EJB 部署使用規則解決方案。
此外，儘管 圖 6 描繪了一系列有序步驟，但規則開發常常會得到一個敏捷、迭代式的開發周期，這實際上是推薦的方法。但是，在一次迭代中，此流程可在跳過一些已完成的活動後應用，比如準備環境或創建項目。
此案例分析使用 WebSphere Application Server Community Edition 默認的 WebSphere ILOG JRules 安裝，因此未包含與 WebSphere ILOG JRules 的安裝和配置相關的步驟，包括身份驗證和許可權管理。
發現業務規則
業務規則可能被認為是用於制定決策的條件語句。任何組織都擁有大量業務規則，它們常常禁錮在主題專家的頭腦中。這些規則以業務策略的形式傳達，比如以下規則：
如果降雨量較大，向排水部門發送評估降雨量的指令，而不是評估污水管容量。
如果水廣場已被清場且威脅級別較高，則發送接通水廣場的指令，以及向排水部門發送監視廣場的水質量的指令。
一個典型的規則集中有幾十或幾百個這樣的策略。其中每個策略適用於一個業務人員且可單獨理解，但它們結合在一起即可制定業務決策。
在一個 BRMS 的上下文中，業務規則是可執行的單元；因此，每條策略都需要細化以準確採集業務規則，而不留下任何歧義。這種細化通常是一個兩步過程：
1. 執行規則分析，以確定規則組和總體規則流邏輯。
2. 使用業務對象模型 (BOM) 中定義的術語編寫業務策略。
以下文章點擊率最高
Loading…