工作流概念
工作流管理聯(lián)盟(WfMC) 對于“工作流” 這個概念的經(jīng)典定義為: 全部或者部分由計算機支持或自動處理的業(yè)務(wù)過程.
工作流管理系統(tǒng)(Workflow Management System, WFMS), 它通過執(zhí)行計算機的流程定義去支持一批專門設(shè)定的業(yè)務(wù). 它被用來支持往踢、管理和執(zhí)行工作流程.
因此, 對于我們, 工作流管理系統(tǒng)的目標是: 管理工作的流程以確保工作正確的時間被期望的人員所執(zhí)行——在自動化進行的業(yè)務(wù)過程中 "插入" 人工的執(zhí)行和干預(yù), 可以說正是工作流管理系統(tǒng)的價值所在, 也是工作流系統(tǒng)開發(fā)者的主要工作內(nèi)容.
如何從一個開發(fā)者的角度看工作流技術(shù)
使用工作流技術(shù)體系開發(fā)軟件系統(tǒng)對開發(fā)者又有什么好處呢?
舉個例子說明.
現(xiàn)在我們來看一個簡單的業(yè)務(wù)——訂貨流程:
- 客戶提交采購訂單
- 業(yè)務(wù)員執(zhí)行訂單處理
- 如果缺貨, 轉(zhuǎn)工廠生產(chǎn)
- 倉庫發(fā)貨
- 物流發(fā)貨
不使用工作流技術(shù), 從頭開始開發(fā)這個訂購流程的業(yè)務(wù)系統(tǒng), 我們需要:
- 每個活動節(jié)點都要開發(fā)交互界面和后臺處理程序.
- 每次活動的流轉(zhuǎn)都需要硬性判斷下一步活動節(jié)點及其處理人.
- 每次操作都需要維護業(yè)務(wù)數(shù)據(jù)和流程的一些相關(guān)數(shù)據(jù).
- 一旦業(yè)務(wù)流程, 就需要大量的更改程序, 甚至重新開發(fā)以適應(yīng)新的需求.
- 監(jiān)視升酣、控制训挡、分析流程處理情況的應(yīng)用還需要單獨開發(fā), 且成本不低.
結(jié)果這個業(yè)務(wù)系統(tǒng)可能是如下圖所示的情況, 請注意這不包括監(jiān)視器肋拔、控制、分析流程的部分.
下面我們看看使用工作流技術(shù)實現(xiàn)上述的訂貨流程將會是什么情況, 如下圖:
很明顯, 位于右側(cè)的工作流管理系統(tǒng)接管了所有訂貨業(yè)務(wù)在流程方面的定義和執(zhí)行, 這包括:
- 使用專門的 "流程數(shù)據(jù)" 系統(tǒng), 維護所有涉及流程傳遞的數(shù)據(jù).
- 提供 "流程設(shè)計" 工具, 幫助用戶定義訂貨流程的模型, 這一般都是基于圖形界面的.
- 工作流引擎作為工作流管理系統(tǒng)的核心, 負責(zé)解釋流程定義嚼贡、管理流程數(shù)據(jù)狼速、計算和驅(qū)動流程實例的運行.
- 工作流引擎提供眾多 API 供客戶端應(yīng)用程序或外部業(yè)務(wù)系統(tǒng)調(diào)用, 將特定的 "業(yè)務(wù)(例如: 訂貨)" 納入"流程" 的管理和控制之中, 從而實現(xiàn)工作流程管理和業(yè)務(wù)操作的完美結(jié)合.
- 工作流引擎還提供眾多 API 供流程的 "增值" 系統(tǒng)使用, 例如流程監(jiān)控系統(tǒng)可以使用工作流程引擎提供的 API 去監(jiān)視流程的執(zhí)行過程抬纸、掛起和恢復(fù)流程實例的運行; 流程數(shù)據(jù)分析系統(tǒng)可以使用工作流引擎的 API 分析出工作完成的效率、業(yè)務(wù)流程的瓶頸等結(jié)果, 以便重組流程弦悉、優(yōu)化業(yè)務(wù).
綜上所述, 引入工作流技術(shù)對于技術(shù)開發(fā)來說, 有如下好處:
- 降低開發(fā)風(fēng)險——通過使用諸如活動窒典、流轉(zhuǎn)、狀態(tài)警绩、行為這樣的術(shù)語, 使得業(yè)務(wù)分析師和開發(fā)人員使用同一種語言交談成為可能. 優(yōu)秀的流程設(shè)計模型工具, 甚至能使開發(fā)人員不必將用戶需求轉(zhuǎn)換為詳細設(shè)計文檔.
- 流程實現(xiàn)的集中統(tǒng)一——應(yīng)對業(yè)務(wù)流程經(jīng)常變化的情況, 使用工作流技術(shù)的最大好處是, 使業(yè)務(wù)流程的實現(xiàn)代碼, 不再散落在各式各樣的業(yè)務(wù)系統(tǒng)中.
- 加速開發(fā)——開發(fā)者不用再關(guān)注流程的參與者崇败、活動節(jié)點的銜接、流轉(zhuǎn)控制. 因為這些工作很多被工作流框架接管了. 因而開發(fā)者開發(fā)起來更快肩祥、代碼出錯更少后室、系統(tǒng)更加容易維護.
- 提升對迭代開發(fā)的支持——如果系統(tǒng)中業(yè)務(wù)流程部分被硬編碼, 就不容易更改, 需求分析師就會花費很大的精力在開發(fā)前的業(yè)務(wù)分析中, 并且希望以此成功. 但可悲的是, 在任何軟件項目開發(fā)中, 這都很少能實現(xiàn).
工作流管理使得業(yè)務(wù)流程很容易部署和重新編排, 業(yè)務(wù)流程相關(guān)的應(yīng)用開發(fā)可以以一種 "迭代/漸進" 的方式推進, 也就是說工作流在某種程度上支持 “需求分析不必一次完全成功”.
工作流管理系統(tǒng)參考模型
首先, 最重要的部分就是中間的工作流引擎, 可以說他是整個工作流管理系統(tǒng)的心臟, 因為所有的工作流管理系統(tǒng)都要使用工作流引擎:
- 為執(zhí)行的流程實例解釋流程定義——這些流程定義一般都是由接口1獲得的.
- 組織調(diào)度流程的實例, 推進工作流程的前進, 這包括條件流轉(zhuǎn)、分支聚合混狠、子父進程.
- 處理工作任務(wù)的分配岸霹、接收、提交等行為——無論是人工干預(yù)或自動執(zhí)行的任務(wù), 都需要經(jīng)過工作流引擎和持久化.
- 管理調(diào)用其他的 4 個接口——這可能包括執(zhí)行工作流程定義的一些外部腳本.
工作流引擎做的工作就像心臟把血液不斷送到身體的各個部分一樣.
工作流管理系統(tǒng)5個部分
接口1——流程定義工具
前面提到過我們使用它來設(shè)計業(yè)務(wù)流程, 提供給工作流引擎來實例化運行. 所謂的 "業(yè)務(wù)流程定義" 一般來說就是一段 XML, 它一般遵循 XPDL標準 BPEL標準 或其它廠商自定義的標準.事實上可以把流程定義工具理解為一個產(chǎn)生 XML 的圖形化設(shè)計建模軟件.
接口2——工作流客戶端應(yīng)用
這很有意思, 當(dāng)業(yè)務(wù)流程設(shè)計好了 運行起來了, 那么我們——"人類" 如何與工作流引擎交互呢?
這時候, 工作流引擎就通過接口 2, 為我們提供各種各樣的工作任務(wù)列表 工作表單 流程列表以及一些查詢功能.
我們通過這些接口應(yīng)用, 就可以填寫表單 處理任務(wù) 從而實現(xiàn)人與工作流引擎的溝通.
接口3——執(zhí)行外部應(yīng)用
工作流引擎通過這個接口去執(zhí)行一些外部的或面向?qū)ｉT職能領(lǐng)域的應(yīng)用程序.
例如財務(wù)系統(tǒng) 報表系統(tǒng)等, 讓第三方系統(tǒng)參與進來, 從而完成定義的工作流程.
同時我們也可以發(fā)現(xiàn)接口2 和接口 3 之間的界定有些模糊, 難道接口 2 提到的 "工作任務(wù)列表" 不能算是外部的應(yīng)用程序嗎?
沒錯! 這個問題確實存在, 這也就是為什么荷蘭工作流大師 Aalst 在其著作<工作流管理——模型 方法和系統(tǒng)> 中寫道 "建議每個應(yīng)用程序都有此 '應(yīng)用程序執(zhí)行服務(wù)' 打開" 的原因, 他是在建議統(tǒng)一這兩個接口嗎? 總之, 接口3在標準化方面眾口不一.
接口4——其他工作流應(yīng)用接口服務(wù)
用來處理若干自治工作流管理系統(tǒng)之間的工作交換, 例如實例轉(zhuǎn)移 工作任務(wù)外包等. 事實上, WfMC 組織的初衷是想通過這個接口來連接各種不同的工作流引擎和系統(tǒng), 使他們在一個統(tǒng)一的標準下工作和交流.
想法是非常不錯的, 但是, 由于種種原因吧, 作者認為是商業(yè)利益的因素以及 WfMC 沒有強大到能 "號令江湖, 莫敢不從" 的地步, 所以到目前為止, 接口 4 基本不被支持, 也就是說, 各大廠商的工作流產(chǎn)品并不能用同一種語言對話.
但是, 隨著jbpm4 推出的 PVM——流程虛擬技術(shù)的發(fā)展, 接口4 的障礙也許能被打破.
接口5——管理和監(jiān)控工具
雖然很多工作流管理系統(tǒng), 特別是開源工作流管理系統(tǒng)實現(xiàn)的最簡單的部分就是這個接口, 但我認為最能體現(xiàn)工作流管理系統(tǒng)在企業(yè)管理方面價值的就是這個部分, 它主要被用來搜集管理信息.
這包括諸如工作流系統(tǒng)功能管理工具, 流程實時監(jiān)控和控制工具, 以及工作效率分析和流程覆蓋面分析等各種商業(yè)智能工具, 這為提升企業(yè)的管理能力, 優(yōu)化重組企業(yè)的流程, 分析企業(yè)內(nèi)部的工作效率瓶頸等提供了重要的量化數(shù)據(jù)支持.
總結(jié)一下, 工作流管理系統(tǒng)參考模型的 5 大接口各自強調(diào)了什么?
接口1 —— 提供流程定義
接口2 —— 提供工作任務(wù)列表等客戶端應(yīng)用程序, 實現(xiàn)使用者與工作流引擎的溝通
接口3 —— 支持外部應(yīng)用程序參與工作流程
接口4 —— 支持不同工作流引擎系統(tǒng)間的連接
接口5 —— 提供監(jiān)控工具, 搜集管理信息
BPM
BPM 即業(yè)務(wù)流程管理, 其重點是通過建模, 自動化, 管理和優(yōu)化流程, 來優(yōu)化公司業(yè)務(wù)的效率和效果.
BPM 打破了跨部門, 跨系統(tǒng)和跨用戶, 強調(diào)端對端的業(yè)務(wù)流程. BPM 系統(tǒng)運行在公司的內(nèi)部和外部, 不僅員工, 客戶, 合作伙伴和提供商都能夠進入該系統(tǒng). 同時, 在公司內(nèi)部 BPM 的應(yīng)用系統(tǒng)還包含了提升業(yè)務(wù)可視水平和可預(yù)見水平的功能.
BPM 通常以 Internet 方式實現(xiàn)信息傳遞, 數(shù)據(jù)同步, 業(yè)務(wù)監(jiān)控和企業(yè)流程的持續(xù)升級和優(yōu)化. 從這方面來說, BPM 不但涵蓋了 "傳統(tǒng)工作流" 的流程傳遞, 流程監(jiān)控的范濤, 而且突破了 "傳統(tǒng)工作流" 技術(shù)應(yīng)用范圍的瓶頸.
BPM 同樣需要流程定義語言描述流程. 流程定義語言可以將企業(yè)中的各種業(yè)務(wù)流程表示成一種格式化的模型.
BPM 的相關(guān)技術(shù)標準可以用來定義業(yè)務(wù)流程和 Web Service 的集成與部署, 以達成企業(yè)業(yè)務(wù)目標. 也就是說, BPM 語言不僅擁有 XML 表示的流程定義, 還延伸到了SOAP WSDL UDDI等多項技術(shù)規(guī)格.
關(guān)于jbpm4 您需要知道的
JBPM 是一個可擴展的, 靈活的能夠?qū)崿F(xiàn)工作流/業(yè)務(wù)流程管理的企業(yè)級開發(fā)框架, 提供了流程定義, 流程部署, 流程執(zhí)行, 流程管理等功能.
1. 嵌入式的工作流引擎
JBPM4 是完全支持嵌入式應(yīng)用的業(yè)務(wù)流程開發(fā)框架, 可以在事務(wù)處理, 持久化等各個方面與業(yè)務(wù)應(yīng)用程序進行靈活集成.
2. 可插拔的體系架構(gòu)
JBPM4 采用了模塊化的架構(gòu)設(shè)計, 采用了 IOC 的設(shè)計理念, 各個模塊之間可以比較方便的解除耦合或替換不同的實現(xiàn).
例如持久化, 事務(wù)處理 身份認證, 日志服務(wù)等, 都由可選模塊實現(xiàn).
JBPM 的可插拔體系架構(gòu), 為軟件開發(fā)者靈活選擇 JBPM 的功能, 自定義已有的功能和拓展新的功能提供了 "無限可能".
3.易擴展的流程語言
JBPM 框架內(nèi)置的流程定義活動, 包括 start, task, fork, join和decision等, 是構(gòu)建完整業(yè)務(wù)流程所必須的組成部分, 他們提供了可以將業(yè)務(wù)邏輯Java代碼和業(yè)務(wù)流程編排無縫銜接的綁定機制.
