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