用于實現 Web 服務的 SOA 編程模型，第 9 部分: 將規則與 SOA 集成

本文將討論業務規則如何作為一種組件類型與 IBM 面向服務的體系結構（Service-Oriented Architecture，SOA）集成，從而帶來業務靈活性的好處以及可補充其他組件類型的功能的備選執行模型。您將了解三種普通規則類別——序列規則、事件相關規則和推理規則。

引言

SOA 包含各種組件實現類型，如傳統 Java™ 對象（plain old Java™ object，POJO），業務流程執行語言（Business Process Execution Language，BPEL）流程、業務狀態機和很多其他類型。本系列的第 1 部分，介紹了 SOA 概念，第 6 部分將組件作為 SOA 的主要部分進行了描述。

開發人員可使用任意的不同軟件或組件類型實現服務組件。有些服務可從使用業務規則組件類型進行實現而受益，因為規則提供了有用的解決方案特征。本文的一個目的就是對各種類別的業務規則進行簡要總結，并說明單個與 IBM SOA 集成的方法如何適應不同類型的規則。

所有組件類型（包括規則）都可放入到單個解決方案組合模型 SOA 中。SOA 的一個主要好處在于，業務集成者可以使用一個組件替換另一個組件，而不會對業務解決方案的其余部分造成影響。本文的第二個目的是，討論當業務規則根據 SOA 進行實現時如何使這個好處變為現實。

在 SOA 中，服務可以通過僅使用請求消息或同時使用請求消息和響應消息來相互進行同步或異步交互。本文還將描述不同類別的規則與各種服務交互樣式進行交互的方式。

業務規則

業務規則分為三個大類：

1. 順序規則提供順序執行的聲明性規則。此規則類別通過允許非編程人員對規則進行維護從而支持業務靈活性。

   這個類別包括 if-then 語句和決策表。

   
   
   圖 1. If-then 規則
   soa-progmodel9/fig1.gif" width="546" twffan="done"/>
   
   

   和其名稱一樣，每個 if-then 規則包含一個 Boolean 表達式，用于確定是否執行在 then 子句中指定的一個或多個操作。這些操作可以計算規則結果、賦值或調用其他服務。在圖 1 中，if-then 規則將重量在 1 到 5 磅之間且體積小于 9 立方英寸的包裹的運輸和處理費用指定為 5。

   
   
   圖 2. 決策表
   
   
   

   決策表可提供正交條件 的精簡可視化表示。它們等效于多個 if-then 規則，用于測試相同條件具有多個值的情況。圖 2 顯示了為包裹的各種重量與體積組合分配運輸和處理費用的決策表。所有體積超過 9 的包裹和所有重量大于 5 的包裹的運輸和處理費用都為 7 美元。對于體積小于 9 的包裹，當體積小于 1 時費用為 2 美元，而重量小于 5 時費用為 5 美元。

   序列規則的主要好處在于其在業務分析人員或其他非編程人員管理規則方面的潛力。這得益于序列規則易于理解的形式和各種簡化規則管理工作的工具。

   第二個好處在于可以將規則作為 SOA 中的獨立服務組件實現。將規則從其他服務分離出來，可以在不影響其他服務的前提下更新規則。大部分規則實現都允許動態更新規則，支持在無需進行其他組件類型通常所需的開發和部署周期的情況下進行更改。這些好處為業務規則實現帶來了極大的靈活性，允許在 IT 相關約束更少的前提下對規則進行改進。

   IBM WebSphere® Process Server 和 IBM WebSphere Integration Developer 支持 if-then 規則和決策表，因此可為采用 SOA 環境的客戶提供這些好處。

2. 事件相關規則可識別先后發生的多個事件間的關系。這些規則通常將對某個時間段內的消息按照類型和條件進行篩選，然后根據各種預定義模式檢測各種狀況。事件相關規則用于識別一系列消息或事件中的 IT 或業務事件狀況。例如，produce an alert if "check customer rating" service generates more than 10 SOAP faults within 1 minute。

   IBM Tivoli® Enterprise Console 可使用事件相關規則來識別給定時間段內從多個源生成的事件中的事件模式。通過這些規則，該軟件可以方便地識別在 IT 或業務監視中值得注意的狀況，從而將在其他情況下需要通過很多手動工作或進行編程來完成的任務簡化為創建相當簡單的規則語句。

3. 推理規則實現演繹法、歸納法、Prolog 樣式的統一或其他人工智能（artificial intelligence，AI）樣式的規則?？蓮耐评慝@益的用例是那些設計到很多相互依賴的規則的用例，這些規則的執行順序必須依賴于數據而不是預先確定的。資源選擇、優化、問題診斷和規劃問題通常都需要進行一定的推理。這些問題涉及到在很多潛在解決方案中進行搜索，以找到那些滿足規則的解決方案。

規則集

大部分規則系統都將規則分組為規則集，規則集在工具中預定義或在運行時進行動態組合。規則集包含規則列表，其中的規則聯合對一組輸入進行計算，并產生一個或多個結果。決策樹提供了序列 if-then 規則集的另一種表示形式。

圖 3 顯示了包含兩個 if-then 的規則集。接口部分記錄規則集的輸入和輸出。第一個規則指定重量小于 1 磅且體積小于 9 立方英寸的包裹的費用為 2 美元。第二個規則指定重量在 1 到 5 磅之間且體積小于 9 的包裹的費用為 5 美元。

每個規則集實現接口的單個操作，可實現該操作的用途（按操作或方法名稱確定）和簽名（參數和結果）。因此，每個規則集可承擔 SOA 中單個操作的角色。

這個方法有諸多優勢：

• 客戶機服務不知道其所使用的服務是如何實現的——是否采用規則或其他實現技術——也不知道規則所屬的規則類別、何時存在選擇。這意味著客戶機可以在不同安裝或不同時間鏈接到其他服務組件，從而提供了一定程度的配置靈活性。
• 常見的類型安全好處都是通過服務協約實現的。
• 編程模型簡單——不需要使用特殊 API 調用規則。
• 流程編排引擎可以像調用其他服務一樣調用規則。引擎并不需要知道特定的操作是使用規則實現的。
• 重用現有容器功能，如訪問控制和事務管理。例如，在解決方案設計中，可能務必使 getDiscount 計算和客戶機應用程序的其他部分一起參與相同的事務。由于可以像其他服務類型一樣調用規則，因此容器功能可以應用到規則。

業務規則組

如圖 4 中所示，服務可以提供多個操作，而規則集實現單個操作。業務規則組對聯合實現服務的所有操作的多個規則集進行包裝。從服務連接的角度來看，業務規則組是“連接”到應用程序中的組件。因此，業務規則組將多個規則集打包為服務，以將提供的可能由其他服務引用的接口導出。

例如，業務規則組可能通過包含與每個操作對應的規則集來實現一個客戶關系管理（Customer Relationship Management，CRM）接口（包含 calculate discount 和 calculate shipping 操作）。如果服務客戶機連接到使用圖 5 中的規則集的業務規則組，則當客戶機調用 calculate shipping 操作時將執行相應的規則。

每個業務規則組均支持在提供的接口中定義的操作，從而實現了類型安全。通常，工具會將業務規則組生成為外殼代碼，該代碼用于實現操作簽名、捕獲輸入參數并以特定于引擎的方式將其傳遞規則引擎。外殼代碼用于解決應用程序特定的操作簽名和很多規則引擎的獨立于應用程序的接口之間的錯誤匹配。圖 5 顯示了提供客戶機和規則引擎之間的橋梁的外殼代碼，該代碼允許客戶機將規則作為服務調用，并允許規則引擎參與 SOA。

從規則調用其他服務

業務規則通常需要調用其他服務，可以將其作為測試條件的一部分（如 "'if moon.getStatus() == "Full" …'）或調用操作（如發送電子郵件）。我們將此建模為兩個部分：

1. 每個業務規則組根據 SOA 定義零個或更多服務引用。服務引用指定所需的服務規范。
2. 在圖 4 中，規則屬于規則集，而規則集屬于規則組。規則可以調用從間接“擁有”規則的業務規則組引用的任意服務。

此方法支持一種特定的開發生命周期，在此生命周期中，規則組和其他服務間的關系的定義早于使用這些服務的實際規則集和規則。應用程序可以在實現時或部署時定義和連接，而規則可以在正在運行的系統中進行管理。

例如，一些業務規則組可以引用服務 A、B 和 C。有時候，該規則組內的規則可能會實際調用服務 A，而在其他時候，這些規則也會調用服務 B。但這些規則無法調用服務 Z，因為相應的業務規則組沒有引用該服務。

調用樣式

服務主要采用兩種方式進行交互；這兩種方法都適用于規則：

1. 請求-響應樣式——由客戶機服務進行同步調用?？蛻魴C調用可能產生同步結果的服務。
2. 事件處理樣式——異步消息處理，如 IBM WebSphere Enterprise Service Bus 中的情況?？蛻魴C以“Fire-and-Forget”的方式向服務發送一條消息。服務將通過兩個異步消息向客戶機傳遞回響應（如果有響應）。

我們將首先討論請求-響應樣式，因為事件處理樣式以請求-響應樣式為基礎。

請求-響應樣式

在請求-響應調用樣式中，客戶機服務調用恰巧通過規則實現的操作。規則的上下文是從客戶機傳遞的參數，還包括規則可訪問的任何靜態數據或服務以及規則內維護的任何狀態。對于任何操作，相應規則將執行一些計算工作，并可能向客戶機返回結果。規則還可能通過調用其他服務進行一些操作或其他工作。

對于 SOA，所有操作簽名都是特定于用法的。因此，計算折扣的操作的輸入、結果和名稱將與驗證駕駛員是否適合保險的操作完全不同。每個應用程序的設計者指定傳遞給規則的輸入值，以及任何希望規則提供的結果，不需要使用特殊 API 來調用規則。

事件處理樣式

在事件處理樣式中，規則集同步處理消息流，如圖 6 中所示。規則集將逐個檢查每條消息，并可能采取某些操作（通過調用其他服務）或生成出站消息。典型的應用包括響應各種業務狀況、審計業務事件以發現不規則情況和監視 IT 事件以發現問題等。規則技術簡化了此類應用，更便于用戶定義消息處理，而無需具備此類編程專業知識。

事件處理樣式以前面描述的請求-響應樣式為基礎。業務規則組接受此類傳入消息并調用規則集。通常，規則集會將傳入消息作為參數接收，且不返回結果（由于使用的異步處理環境）。規則集通過調用另一個服務產生輸出（如果有），此服務可能與任何其他消息源關聯，也可能不與任何其他消息源關聯。因此，從規則技術角度來說，事件處理樣式和請求-響應樣式的區別是環境方面的，而不是本質區別。兩種樣式的規則執行模型并沒有變化；僅在用于調用規則集的接口的簽名以及規則與客戶機應用程序的交互中存在差異。

無狀態規則和有狀態規則的對比

和其他服務實現類型一樣，業務規則可能為無狀態的或有狀態的，即可以選擇跨多個調用維護內部數據記錄。規則可通過保存狀態來將其上下文擴展到整個調用歷史，支持依據傳遞到當前調用的參數之外的其他因素進行決策和計算。有狀態規則的例子包括大部分事件相關規則和一些推理規則的使用。

業務規則內維護的狀態數據和客戶機服務間的關系是特定于應用程序的，不能在體系結構中進行處理。通常，規則將使用一個或多個調用參數來處理相應的內部狀態。

任何規則內維護的狀態都應加以保持，以支持集群配置和大部分業務配置通常要求的高可用性。對于很多規則系統而言，支持規則提供的靈活性以及可伸縮性和可恢復性可能是一項很大的挑戰。

典型使用模式

前面的討論中給出了兩個基本規則調用樣式（同步請求-響應樣式和異步事件處理樣式）并對無狀態處理和有狀態處理進行了區分。調用樣式和有狀態及無狀態執行有四種可能的組合，任何規則類型（如前面所述）都可以采用其中的任意組合進行使用。下表說明了最典型的使用模式：

上表說明了就每種規則類型的功能而言最合理的組合。其他用法當然也是可能的。例如，將序列規則或推理規則替換為無狀態事件處理，可提供與最簡單的事件相關規則等效的功能，但會失去將規則平穩地過渡到真正的多事件相關的功能。又如，您可以將推理規則應用到有狀態事件處理，以對消息序列進行有關推斷。應用程序要求和工具功能將決定每種情況下的最佳選擇。

結束語

本文簡要總結了三種普通規則類別，并說明它們如何與 SOA 集成——不用受以下兩方面的限制：

• 規則是無狀態的，還是有狀態的。
• 調用樣式是同步請求響應還是基于異步消息。

此處描述的集成方法將規則作為第一類服務組件類型對待，是與傳統傳統 Java 代碼、業務流程和狀態機屬于同一種類型的技術。對于服務客戶機的開發人員，這意味著可以像其他服務一樣調用規則，而沒有特殊的API 注意事項。對于總體解決方案開發人員，這就意味著可以將規則和其他實現類型混合使用，為總體解決方案中的每個組件應用最為恰當的技術。