| 2004 年 10 月 22 日 按需業(yè)務廠商需要快速調整自己的生產流程來適應急速變化的市場需求。本文章系列提供了開發(fā)靈活、按需業(yè)務流程的方法。這一方法提高了快速定義、創(chuàng)建和部署靈活的解決方案的能力，通過集成業(yè)務流程內部的服務、數(shù)據(jù)、規(guī)則、角色和規(guī)格來滿足不斷變化的客戶需求?；?IBM ?目前正在使用的硬件訂單處理系統(tǒng)，文章引入了一個真實化的訂單處理場景。這一場景為系列中的其它文章提供了一個通用的上下文環(huán)境和一組使用案例，系列中的其它文章將涉及模式、模型、工作流、規(guī)則和監(jiān)控等 本系列文章源于我們在一個試驗性項目 Oneida-2 中的經驗（請參閱 Oneida-2 project 以獲取更多信息）。在這個實驗性項目中，我們在一個理想供應鏈的假設前提下實現(xiàn)了按需業(yè)務改造。我們將向您介紹那些技術和方法，使得您可以利用它們來構造可重用組件，以應用到按需業(yè)務流程的快速構建中。 在供應鏈中，制造處理系統(tǒng)（OTMPS）的訂單通常位于訂單入口和制造支持系統(tǒng)之間（如 圖 1 所示）。您可以使用通用的OTMPS 場景和使用案例來理解上面提到的應用。 圖 1. 供應鏈中的訂單處理 
在 Oneida-2 工程中，我們對一個遺留的 OTMPS 進行按需業(yè)務改造。我們的目標是通過實現(xiàn)一個原型系統(tǒng)來說明如何滿足以下業(yè)務需求：
文章系列同樣也描述了為滿足以上需求的和所應用的方法、工具和模式以及 SOA 設計概念。我們采用交互式設計和增量式開發(fā)方法，利用模式進行建模、開發(fā)和發(fā)布。方法強調業(yè)務流程中的重用、 IT 技術的成熟度，并且一些關鍵功能盡可能通過 Web 服務來實現(xiàn)。我們交互式設計主要步驟如下：
我們首先介紹場景、需求和幾個使用案例。同時我們將重點闡述建模、系統(tǒng)實現(xiàn)、性能監(jiān)測解決模式和系統(tǒng)架構。系列中的其它文章將對上面的內容提供更詳細的描述，并重點強調按需業(yè)務流程解決方案中使用的方法、工具和模式。
OTMPS 使得客戶能夠提交訂單（參考 Stakeholders 來了解場景中各種角色的詳細信息）。您可以利用這些有效填寫的訂單作為輸入來產生制造術語中相應的 BOM。 然后您可以提交這些訂單給制造廠進行生產。在正常情況下，這些提交的訂單在對應的 BOM 和制造指令下達給制造廠之前要經歷多個步驟。在這一過程中可能會有意外情況需要人工干預（如，OTMPS 操作員可能手工處理和糾正一些錯誤的訂單）。
OTMPS 包含的功能組件如下所示（它們組成了系統(tǒng)的主要部分）：
在設計實現(xiàn)OTMPS的過程中，您可以對這些功能組件進行適當變化。
根據(jù)與業(yè)主的交流，分析人員對 OTMPS 的實現(xiàn)定義了如下的示例需求：
根據(jù)需求以及前面提到的場景， OTMPS 需要實現(xiàn)以下使用案例（注意，沒用全部列出）：
為加深理解，我們將對 3 個使用案例（UC1、 UC4 和 UC7 ）進行詳細描述： UC1：調度一組在線訂單 Actor：操作員 前提：門戶和業(yè)務集成服務器準備好并處于運行狀態(tài) 主要成功場景：
擴展：5a. 系統(tǒng)顯示“失敗”提示信息 UC4:通知操作員校驗失敗 Actor:操作員 前提:成功執(zhí)行 UC3 過程中遇到無效訂單 主要成功場景：
擴展：6a. 操作員與顧客進行協(xié)商后更新或取消訂單。 UC7：監(jiān)視業(yè)務流程規(guī)格 Actor：業(yè)務業(yè)主 前提：UC1 至少被成功執(zhí)行一次 主要成功場景：
圖 2 列出了上面提到的所有使用案例。例如，在 UC7 中，業(yè)主通過與 監(jiān)視系統(tǒng)交互來觀察業(yè)務性能信息。 在另外一個例子中，操作員連接 Order Application 來執(zhí)行 UC1 ，UC1 反過來又通過 Order Processing 系統(tǒng)執(zhí)行 UC3。 供應商顯示外部供應商系統(tǒng)，它提供了一個請求部件的接口。 Legacy System 和 Validation System 顯示現(xiàn)存的應用，它們被用在 UC3 中。 圖 2. OTMPS 使用案例 
圖 3 詳細說明了循環(huán)開發(fā)流程以及每一階段使用的工具和方法。開發(fā)流程從利用 WBI Modeler 對業(yè)務流程建模開始。第一步是分析師組織業(yè)務領域相關的專家來準確描述業(yè)務需求。利用準確的業(yè)務需求作為輸入，分析師利用 WBI Modeler 對現(xiàn)有的“as-is”業(yè)務流程建模。利用一個協(xié)作流程，“as-is”業(yè)務流程被移植為更有用的“to-be”業(yè)務流程。預先存在的模型構件，稱為流程元素（參考服務和流程元素一節(jié)），在適當?shù)臅r候被從中心庫中取出來加入模型，這樣，將來使用的一個新的模型組件就產生了。分析師同時來定義了在業(yè)務執(zhí)行流程中需要監(jiān)測的業(yè)務規(guī)格。 一旦成功完成建模，業(yè)務分析師將流程模型傳遞到 IT 開發(fā)小組來實現(xiàn)。在實際操作中，IT 架構師應該參與到流程建模中，以保證業(yè)務建模與系統(tǒng)實現(xiàn)間的順利過渡。 WBI Modeler 以業(yè)務流程執(zhí)行語言（BPEL）、XSD 和 WSDL 構件相結合的形式輸出流程模型以及相關的業(yè)務級別的對象定義。流程模型的實現(xiàn)需要集成其它一些組件如訪問遺留功能系統(tǒng)的適配器、業(yè)務邏輯組件、Web 服務綁定等待。有許多相關的模式都可以應用在模型的設計和實現(xiàn)上（參考 模式解決方案）。
圖 3. Oneida 按需業(yè)務流程生命周期 利用 IBM Rational XDE，架構師定義其它 IT 組件的對象模型并產生模型的 Java 代碼。隨后開發(fā)人員利用 Application Developer 將 WBI Modeler 和 Rational XDE 的輸出、業(yè)務合作伙伴的服務、遺留系統(tǒng)以及規(guī)則框架集成起來。利用 Application Developer ，開發(fā)人員將其它組件（XML schemas、Java 代碼、服務、規(guī)則）與 BPEL 工作流關聯(lián)起來。您可以利用通用事件基礎設施（CEI）來產生相關流程事件。最終的應用程序實現(xiàn)發(fā)布到 WBI 基礎運行服務器上。 在執(zhí)行流程中，CEL 基礎設施能夠監(jiān)視流程規(guī)格。如果條件滿足，您可以使用 WBI 監(jiān)視器 5.1 版。它支持 CEI 并提供相應的監(jiān)視工具。另外一種解決方案是，您可以使用 WebSphere Portal Server 來顯示性能信息。分析員將利用這些信息來改進業(yè)務流程，從而實現(xiàn)一個封閉的生命周期循環(huán)。 如上所述，流程模型和實現(xiàn)由幾個單獨的角色來完成，他們分別需要不同的技能。流程語義，包括過程流、策略和性能參數(shù)被用來在 業(yè)務- IT 之間的行業(yè)差距間傳遞信息。在此行業(yè)差距之上進行增量式和交互式的開發(fā)并不是無關緊要的，因為每一方的變動都有可能對另外一方造成重大影響。因此，角色之間進行密切合作對于確定和解決 業(yè)務架構有很大幫助。
建模就是將業(yè)務流程分解成代表不同功能、組件、服務以及相關的數(shù)據(jù)輸入輸出、策略和規(guī)格的子流程。 As-is 模型可用來進行仿真并找出當前的瓶頸。 As-is 業(yè)務流程又可轉化為 to-be 業(yè)務流程來實現(xiàn)期望的改變?？赏ㄟ^仿真 to-be 模型來找出潛在的流程改進。分析師同樣也可找出流程執(zhí)行過程中需要關注的業(yè)務 規(guī)格。 圖 4 說明了 WBI Modeler V5.1 中一個常見的流程片段。 這一簡單的 OTMPS 模型描繪了經過校驗和制造廠的訂單流。 利用 校驗和產生拓撲服務調用步驟，模型集成了一個校驗合作服務。圖中還包含一個決策點 校驗是否成功？， 2 個數(shù)據(jù)格式轉換任務，一個本地數(shù)據(jù)倉庫用來存儲后面處理流程中用到的客戶訂單，一個循環(huán)處理來選擇并將訂單發(fā)送到正確的制造工廠。 圖 4. WBI Modeler V5.1 中流程模型片段 分析師還可能應用一些已經存在的模型組件（如，服務或流程元素）來幫助和加速模型的構建（請參考 服務和流程元素）。這些模型元素作為業(yè)務構件被存儲在一個中央倉庫中。
系列中的第 3 篇文章引入技術指南來指導利用 WBI Modeler V5 的交互式建模流程。文章描述了如何定義核心流程元素：
定義完核心業(yè)務組件之后，我們以下面的順序說明建模方法：
我們簡要描述了利用 WBI Modeler 通過靜態(tài)或動態(tài)仿真來進行模型校驗和分析。我們通過對 WBI Modeler 的各種輸出功能進行描述作出一個總結并描述了產生的構件。
WBI modeler 產生的 BPEL、 XSD 和 WSDL 組件成為系統(tǒng)實現(xiàn)的起點。 利用 Rational XDE ，架構師定義其它IT組件的對象模型并產生相應的 Java 代碼。我們利用 Application Developer 5.1 “業(yè)務集成”透視圖來創(chuàng)造一個服務工程，它包含各種組件如 XML schemas、Web 服務以及對象和流程等。利用 XDE 和 Application Developer 產生的 Java 類和 XML schemas 構件分別被用來訪問外部合作者服務。 BPEL 工作流被擴展（通過 Java 代碼）來集成規(guī)則、支持遺留服務交互和產生業(yè)務事件。 圖 5 是一個 Application Developer BPEL 編輯器視圖。 流程通過靜態(tài)綁定機制來連接它的合作者服務，它在流程發(fā)布的時候產生。必要的綁定、發(fā)布代碼和組件集成到一起。它包括產生的遺留代理組件代碼、 WSDL/XSD 文件和一些發(fā)布組件（EJB 和 SOAP 綁定）。 意外被外部的宏工作流處理，它是一個長期運行的流程，它為引入工作人員來評估意外情況并決定如何來處理提供了可能。 圖 5. Application Developer BPEL 編輯器 在系列的第 4 篇文章中，我們描述了如何將 WBI Modeler 的輸出和 Rational XDE 的輸出導入 Application Developer 以及如何將它們集成在一起。文章還描述了流程和服務組件實現(xiàn)以及 Java 類和 XMLschema 組件如何以輸入/輸出消息和狀態(tài)對象的形式加入到實現(xiàn)。為完成實現(xiàn)，需要包裝并連接到外部的合作者服務和規(guī)則。 我們描述了一些最佳實現(xiàn)來提高工作流的性能。我們 解釋了微工作流之間在事務行為、并行性和性能上的區(qū)別。我們提出了在不同條件下的最佳類型和組合方式。我們羅列了不同的數(shù)據(jù)映射方法、調用方式、綁定發(fā)布技巧以及這些不同方法技巧對于性能的影響。
隨著時間進展，業(yè)主引入新的需求到 OTMPS 實現(xiàn)中（如，改變如何來決定配置訂單的策略）。我們的目標就是使 OTMPS 能夠適應需求的快速改變。
分析師可以來定義策略，但策略需要明確的、可執(zhí)行的規(guī)則來強制執(zhí)行?？梢詤⒖肌安呗浴⒁?guī)則和強制點”一節(jié)中關于策略、規(guī)則和強制點的定義。 在傳統(tǒng)的應用程序中，規(guī)則被嵌入到應用程序中的代碼中。當策略發(fā)生改變，應用程序代碼需要被更新且重新發(fā)布。 規(guī)則外部化使得業(yè)務分析人員和其它非技術用戶可以更改策略而不需要改變流程邏輯和重新發(fā)布應用程序。 為重用現(xiàn)存的工作流組件，對架構來說實現(xiàn)后期定制來滿足策略改變很有必要。這種定制可以通過在工作流執(zhí)行過程中動態(tài)改變外部規(guī)則來實現(xiàn)，這些外部規(guī)則正是用來實現(xiàn)和強制業(yè)務策略。 作為試驗性項目 OTMPS 的一部分，我們實現(xiàn)了一個簡單的服務器框架，它包含一個規(guī)則服務代理和一個規(guī)則選擇引擎（詳細信息請參閱系列文章中的第 5 篇）。我們通過業(yè)務規(guī)則 Beans（BRBeans）（請參閱 圖 6）來實現(xiàn)框架。 BRBeans 是 WBI-SF 中的一個框架，用來創(chuàng)建、修改和調用規(guī)則，它通過 Rule、RuleFolder 和 RuleHelper 等 EJB 來實現(xiàn)。在 BRBeans 框架中，每條規(guī)則都由一個實體 EJB 來實現(xiàn)，實體 EJB 持久性地存儲規(guī)則相關的信息。每一條規(guī)則被指派一個特定的名字和相關的屬性（如開始日期、結束日期、可用性、javaRuleImplementorName 等），被存儲在相關的規(guī)則路徑中。規(guī)則實現(xiàn)就是用 Java 語言編寫的算法并通過 ‘javaRuleImplementorName’ 屬性來與規(guī)則關聯(lián)。 圖 6. BRBeans 架構 除了從工作流中直接調用 BRBeans API ，我們建議采用服務調用的方式，它反過來通過規(guī)則框架調用 BRBeans API ，如 圖 7 所示。所有應用特定的規(guī)則都封裝到一個服務代理中，每個規(guī)則作為一個代理提供的方法。應用程序（如安全、業(yè)務性能等等）間共享的規(guī)則可以定義為另外一個通用服務代理。規(guī)則框架隱藏了規(guī)則引擎，使得可以選擇不同的規(guī)則引擎。分析員通過特定的規(guī)則引擎管理系統(tǒng)（通過規(guī)則管理 GUI ）來定義規(guī)則并發(fā)布到對應的規(guī)則引擎。 圖 7. 規(guī)則服務代理 在策略強制點，規(guī)則以普通 Web 服務的形式被調用，為執(zhí)行傳遞必要的參數(shù)。我們應用策略模式來進行合適規(guī)則引擎的選擇。創(chuàng)造了一個命令模式進行正確規(guī)則的選擇及其在相應規(guī)則引擎上的執(zhí)行。一旦一個規(guī)則命令類被創(chuàng)建，它將在特定的規(guī)則引擎上被觸發(fā)且執(zhí)行正確的規(guī)則。
業(yè)務流程監(jiān)控允許業(yè)主和管理員實時監(jiān)控關鍵性能指示器（KPI，參考關鍵性能指示器）。它同樣也幫助分析師定位當前系統(tǒng)中的問題和瓶頸，形成如 圖 3 所示的閉合的開發(fā)周期?；诖朔答佇畔?，分析師可以決定如何來調整和改變業(yè)務流程來實現(xiàn)循環(huán)的開發(fā)流程。如，在試驗性項目中，OTMPS 業(yè)主定義了如下關鍵性能測量參數(shù)：
CEI 基礎架構使您能夠以一種統(tǒng)一的方式創(chuàng)造和發(fā)布事件。您可以編寫應用程序/工具來根據(jù)這些事件計算并顯示有用信息。事件通常被用來激發(fā)信息相關的業(yè)務流程，這些流程被用來計算性能指標。利用 WBI-SF V5.1.1 中包含的 CEI API ，事件以通用基本事件（CBE）的格式產生。我們利用 WebSphere Portal Server Express 來顯示并聚合信息到一個復合頁面中，以復合表格的形式給用戶提供信息。我們定制 WebSphere Portal Server Express 提供的 Web 頁面來監(jiān)視業(yè)務事件和性能信息。 在本系列將來的文章中，我們將演示如何利用 CEI 實現(xiàn)業(yè)務流程監(jiān)視。我們討論如何在 WBI Modeler V5.1 中定義 KPI ，如何利用 BPEL 編輯器和 Application Developer V5.1.1 中的 CEI API 來創(chuàng)建相應的事件，我們簡單描述了 CBE 的架構，說明了如何利用 XPath 查詢語言進行查詢，如何利用 WBI-SF V5.1.1 創(chuàng)建事件組，如何利用 CEI API 來查詢事件。
有許多相關的模式（請參考 模式）可應用在 OTMPS 的分析、測試、電子業(yè)務以及發(fā)布等等。這些模式是如何結合在一起的？在一個特定的上下文中如何應用這些模式來創(chuàng)建一個靈活的，及時響應的解決方案？這些問題都不是很清楚。在系列中的第 2 篇文章中我們描述了一個 OPMPS 的模式解決方案的實現(xiàn)，利用模式來實現(xiàn)電子商務。為了解電子商務模式，請參考 Jonathan Adams、 Srinivas Koushik、 Guru Vasudeva 和 George Galambos 撰寫的 電子商務模式：可重用方法，IBM Press， 2001， ISBN 1-931182-02-7。要了解 IBM developerWorks 中電子商務資源中其它的模式信息，請參考 IBM 電子商務模式。
在第 2 篇文章中，我們引入了 4 種設計模式，它們或者是現(xiàn)有模式的變形，或者是有可能成為新的設計模式：
就像文章開頭提到的，我們實現(xiàn)了一個真正的 OTMPS 的按需改造，在下面的文章中，我們將詳細描述所采用的技術和方法，這些技術方法在您設計構建類似的系統(tǒng)時同樣也可用上。 圖 8 說明了在我們的 OTMPS 原型系統(tǒng)中主要組件之間運行時的關系。
圖 8. 組件 -- 邏輯視圖
本系列文章概述了實現(xiàn)靈活的業(yè)務流程所需的技術以及開發(fā)生命周期，這些技術和開發(fā)流程使得業(yè)務流程可以滿足不斷變化的需求。 我們描述了一個訂單處理視圖，它為系列中的其它文章提供了一個通用的上下文環(huán)境和一組使用案例。第一步是利用 WBI Modeler 對現(xiàn)存的或期望的業(yè)務流程建模。模型輸出構件和其它構件進行組合，最終的應用程序發(fā)布到 WBI-SF 上。CEI 產生相關事件用來測量業(yè)務規(guī)格，這些信息通過計算并顯示在業(yè)務控制界面上。這些規(guī)格隨后作為輸入供分析師來改進業(yè)務流程，從而完成一個循環(huán)。通過將多個電子商務模式集成可以產生一個模式解決方案，架構設計正是基于這種方式來設計的。
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
