工作流概述
作者Tom Baeyens 翻譯dinghong ，轉(zhuǎn)載自http://blog.csdn.net/ngnr/services/trackbacks/145986.aspx
前言
如果數(shù)據(jù)庫(kù)系統(tǒng)（ database systems）像受人尊敬的智者講述的條理清晰的故事，那么工作流（workflow）就像一群
乳臭未干的小子在大談各自的“哲理”。之所以這樣講，我是想指出，工作流系統(tǒng) （workflow management systems）
還處于技術(shù)發(fā)展曲線（ technology hype curve）上的初級(jí)階段。在這個(gè)領(lǐng)域我們將面臨一個(gè)激動(dòng)人心的階段。 為了
描述這一點(diǎn)，可以和關(guān)系數(shù)據(jù)庫(kù)系統(tǒng)（RDBMS）做一個(gè)對(duì)比。當(dāng)在軟件開發(fā)團(tuán)隊(duì)中談?wù)揜DBMS時(shí)，大部分人會(huì)有一個(gè)清晰
的概念，在你和他們交流的時(shí)候，人們會(huì)通過輕微的點(diǎn)頭表示認(rèn)可或理解你所說的?？僧?dāng)使用工作流術(shù)語(yǔ)討論工作流時(shí)，
他們會(huì)搖頭表示不同意，因?yàn)槊總€(gè)人對(duì)工作流術(shù)語(yǔ)都有不同的理解。
Figure 1: Workflow vs. RDBMS positioned in the hype-curve
導(dǎo)致形成這種狀況的原因之一，是在工作流中使用了過多的概念。在這個(gè)領(lǐng)域中的大量規(guī)范和工具沒有一個(gè)是相似的。
當(dāng)然，它們相互之間有重疊并且會(huì)相互參考引證。在介紹工作流時(shí)有一個(gè)話題必須包括，那就是工作流和業(yè)務(wù)流程管理
（BPM）的關(guān)系。術(shù)語(yǔ)“工作流”通常描述人與計(jì)算機(jī)系統(tǒng)的一系列相關(guān)交互。在開發(fā)人員中，工作流經(jīng)常被提及。有時(shí)，
工作流的意思是指一些不同的UI界面。業(yè)務(wù)流程管理的范圍比較廣，相比之下工作流多半局限于技術(shù)領(lǐng)域。業(yè)務(wù)流程管
理還從管理人員的角度涉及了非技術(shù)問題，比如分析、組織的效率。在本文中，我首先解釋什么是工作流管理系統(tǒng)，然
后介紹業(yè)務(wù)流程管理的優(yōu)點(diǎn)。接下來描述一下為什么工作流市場(chǎng)乍看起來如此混亂。本文給出的主要結(jié)論是：選擇工作
流系統(tǒng)是想用工作流系統(tǒng)的公司，將要面對(duì)的最困難的事情。為此，本文的核心部分描述了一個(gè)流程定義
（process definition）的四個(gè)層次，為你選擇工作流提供一個(gè)基礎(chǔ)。本文還用中立的語(yǔ)言描述了工作流和BPM的通用概念。
最后，給出了一些規(guī)范和工具的指導(dǎo)性描述。
什么是工作流管理系統(tǒng)（WFMS）
定義
工作流系統(tǒng)是以規(guī)格化的流程描述作為輸入的軟件組件,它維護(hù)流程的運(yùn)行狀態(tài),并在人和應(yīng)用之間分派活動(dòng)。
為了后面的描述，我們先定義一些基本的術(shù)語(yǔ)：流程定義（process definition）和流程實(shí)例（process instance）. 一個(gè)
流程定義是一個(gè)業(yè)務(wù)流程或過程的規(guī)格化描述。一個(gè)流程實(shí)例是流程定義的一個(gè)運(yùn)行實(shí)體。 都目前為止，概念還比較清晰
是不是？但當(dāng)再深入一步時(shí)，我們就要小心使用文字了。如何闡述流程中的步驟，現(xiàn)在還沒有一個(gè)統(tǒng)一的方式。這是各種工
作流規(guī)范和工具之間主要的分歧。
為什么應(yīng)當(dāng)禁止使用術(shù)語(yǔ)“活動(dòng)（activity）”...
流程定義通常用一些活動(dòng)表述。我認(rèn)為這是導(dǎo)致工作流領(lǐng)域所有混亂的主要原因。我告訴你為什么：因?yàn)樾g(shù)語(yǔ)“活動(dòng)”混淆了
狀態(tài)（state）和動(dòng)作（action）之間的差異。在流程中，狀態(tài) (或者說等待狀態(tài))代表了一種對(duì)外部參與者（actor）的依
賴。在流程運(yùn)行時(shí)，這意味著流程引擎必須等待，直到外部參與者通知工作流管理系統(tǒng)指定的狀態(tài)完成了。比如，等待可進(jìn)
一步運(yùn)行的認(rèn)可。動(dòng)作是在流程運(yùn)行過程中，工作流系統(tǒng)為響應(yīng)指定事件（event）運(yùn)行的一段程序邏輯
（programming logic）。當(dāng)流程運(yùn)行過程中指定的事件發(fā)生時(shí)，工作流系統(tǒng)啟動(dòng)并執(zhí)行這些動(dòng)作。比如，當(dāng)狀態(tài)分配給一個(gè)
參與者時(shí)，發(fā)一封Email。你也能看出，狀態(tài)和動(dòng)作是如此不同，因此使用同樣的術(shù)語(yǔ)去描述這些概念是一個(gè)壞習(xí)慣。我的建
議是避免使用術(shù)語(yǔ)“活動(dòng)”，使用“狀態(tài)”或者“動(dòng)作”代替它。
工作流系統(tǒng)另一個(gè)重要的職責(zé)是維護(hù)每一個(gè)流程運(yùn)行的上下文信息。 流程上下文變量（process context variable） ，或
簡(jiǎn)稱變量，是與流程實(shí)例相關(guān)的變量。如，休假申請(qǐng)的開始日期、數(shù)據(jù)庫(kù)中一條記錄的鍵值、文檔管理系統(tǒng)中一篇文檔的索
引等。通常在流程定義中聲明這些變量，然后在流程實(shí)例生成時(shí)，這些流程變量被實(shí)例化。所有成熟的工作流管理系統(tǒng)都支
持定制的變量類型。
目標(biāo)領(lǐng)域（Target usage）
使用工作流管理系統(tǒng)的目的之一是作為企業(yè)應(yīng)用系統(tǒng)集成（EAI）的平臺(tái)。在當(dāng)前大部分企業(yè)級(jí)IT架構(gòu)中，各種各樣的異構(gòu)
（heterogeneous）應(yīng)用和數(shù)據(jù)庫(kù)運(yùn)行在企業(yè)內(nèi)網(wǎng)中。在這些系統(tǒng)被應(yīng)用到組織時(shí)，都有一個(gè)清晰的目標(biāo)。例如，客戶管理、
文檔管理、供應(yīng)鏈、訂單、支付、資源計(jì)劃等等。讓我們稱這些系統(tǒng)為專門應(yīng)用（ dedicated applications）。每一個(gè)專
門應(yīng)用都包含它們所支持業(yè)務(wù)流程的領(lǐng)域知識(shí)。這些專門應(yīng)用中的自動(dòng)化流程，被拼裝到企業(yè)中更大的非自動(dòng)化流程中。每
當(dāng)一個(gè)這樣的專門應(yīng)用安裝并投入使用，都會(huì)帶來涉及其他多個(gè)應(yīng)用的新功能需求。企業(yè)應(yīng)用系統(tǒng)集成（EAI）就是通過使
用多個(gè)專門應(yīng)用滿足軟件新需求的方法。有時(shí)，這只需要在兩個(gè)應(yīng)用之間提供數(shù)據(jù)通訊的通道。專門應(yīng)用將很多業(yè)務(wù)流程硬
編碼在軟件中。可以這么說，在你購(gòu)買專門應(yīng)用時(shí)，你是購(gòu)買了一組固定的自動(dòng)化業(yè)務(wù)流程。而工作流管理系統(tǒng)是不必事先
知道問題域的相關(guān)信息的。工作流系統(tǒng)將業(yè)務(wù)流程描述作為輸入并管理流程實(shí)例的執(zhí)行，這使得它比專門應(yīng)用更靈活（當(dāng)然
你也要花精力編寫業(yè)務(wù)流程的規(guī)格化描述）。這就是為什么說工作流系統(tǒng)和專門系統(tǒng)是相互補(bǔ)充的。工作流系統(tǒng)可以用來管
理全局的業(yè)務(wù)流程。如果專門應(yīng)用支持你所需要的業(yè)務(wù)流程，那么使用專門應(yīng)用。在此討論的工作流系統(tǒng)的第一種使用方式
就是：結(jié)合所有的專門應(yīng)用，使用工作流系統(tǒng)構(gòu)建一個(gè)EAI平臺(tái)。
工作流系統(tǒng)能夠發(fā)揮很大價(jià)值的第二個(gè)使用方式是：協(xié)助涉及多人相關(guān)任務(wù)工作流軟件的開發(fā)。為了達(dá)到這個(gè)目的，大部分
工作流系統(tǒng)都有一個(gè)方便的機(jī)制，來生成執(zhí)行任務(wù)的表單。對(duì)于專注于ISO 或者CMM認(rèn)證的組織，采用這種方式使用工作流
系統(tǒng)能夠顯著提高生產(chǎn)率。 不用將過程用文字的形式寫在紙上，工作流系統(tǒng)使你通過流程定義建模實(shí)現(xiàn)過程的自動(dòng)化（如
使用基于Web的應(yīng)用）。
工作流系統(tǒng)的第三種使用方式是：將工作流引擎嵌入到其他應(yīng)用中。在前面我們談到，專門應(yīng)用將指定問題域相關(guān)的業(yè)務(wù)流
程固化在軟件中。開發(fā)專門應(yīng)用的公司也可以將工作流引擎嵌入到他們的軟件中。在這里，工作流引擎只是作為一個(gè)軟件組
件，對(duì)于應(yīng)用的最終用戶是不可見的。將工作流引擎嵌入到應(yīng)用中的主要原因是為了重用（不重復(fù)發(fā)明輪子）和應(yīng)用軟件的
可維護(hù)性。
The case for workflow
對(duì)于引入工作流的組織，能夠在軟件開發(fā)和業(yè)務(wù)兩個(gè)層次受益。
方便開發(fā)
工作流管理系統(tǒng)能夠簡(jiǎn)化企業(yè)級(jí)軟件開發(fā)甚至維護(hù)。
降低開發(fā)風(fēng)險(xiǎn) - 通過使用狀態(tài)和動(dòng)作這樣的術(shù)語(yǔ)，業(yè)務(wù)分析師和開發(fā)人員使用同一種語(yǔ)言交談。這樣開發(fā)人員就不必將用戶需求
轉(zhuǎn)化成軟件設(shè)計(jì)了。
實(shí)現(xiàn)的集中統(tǒng)一 -業(yè)務(wù)流程經(jīng)常變化，使用工作流系統(tǒng)的最大好處是：業(yè)務(wù)流程的實(shí)現(xiàn)代碼，不再是散落在各種各樣的系統(tǒng)中 。
加快應(yīng)用開發(fā) - 你的軟件不用再關(guān)注流程的參與者，開發(fā)起來更快，代碼更容易維護(hù)。
業(yè)務(wù)流程管理 (BPM)
在自動(dòng)化業(yè)務(wù)流程之前，分析并將它們規(guī)格化是一件艱苦但會(huì)有很好回報(bào)的工作。e-workflow.org對(duì)于分析流程能夠帶了的
益處有不錯(cuò)的闡述：
提高效率 - 許多流程在自動(dòng)化過程中會(huì)去除一些不必要的步驟
較好的流程控制 - 通過標(biāo)準(zhǔn)的工作方法和跟蹤審計(jì)，提高了業(yè)務(wù)流程的管理
改進(jìn)客戶服務(wù) - 因?yàn)榱鞒痰囊恢滦?，提高了?duì)客戶響應(yīng)的可預(yù)見性
靈活 - 跨越流程的軟件控制，使流程可以按照業(yè)務(wù)的需要重新設(shè)計(jì)。
業(yè)務(wù)流程改進(jìn) - 對(duì)流程的關(guān)注，使它們趨向于流暢和簡(jiǎn)單
我認(rèn)為他們還遺漏了一個(gè)使用工作流系統(tǒng)最重要的因數(shù)：提高對(duì)迭代開發(fā)的支持。如果軟件中業(yè)務(wù)流程部分不容易更改，組
織就會(huì)花很大的精力在開發(fā)前的業(yè)務(wù)流程分析中，希望一次成功。但可悲的是，在任何軟件項(xiàng)目開發(fā)中，這都很少能實(shí)現(xiàn)。
工作流系統(tǒng)使得新業(yè)務(wù)流程很容易部署，業(yè)務(wù)流程相關(guān)的軟件可以一種迭代的方式開發(fā)，因此使用工作流系統(tǒng)使開發(fā)更有效、
風(fēng)險(xiǎn)更低。
缺失的一環(huán)（Missing link）
我確實(shí)認(rèn)為工作流系統(tǒng)是企業(yè)應(yīng)用開發(fā)中缺失的一環(huán)。將企業(yè)業(yè)務(wù)流程邏輯在企業(yè)級(jí)軟件中實(shí)現(xiàn)的缺省方式是分散的。這意
味著業(yè)務(wù)流程邏輯散布在各種系統(tǒng)中，如EJB、數(shù)據(jù)庫(kù)觸發(fā)器、消息代理等等。這樣得到的軟件難于維護(hù)，結(jié)果，企業(yè)只能
將改變業(yè)務(wù)流程軟件作為最后的選擇。他們經(jīng)常能夠做的是，改變流程以適應(yīng)軟件。上述問題也適用于采用大型外部ERP軟
件包的企業(yè)。進(jìn)一步，假設(shè)我們認(rèn)識(shí)到這個(gè)問題，并打算將一個(gè)流程相關(guān)的代碼都集中起來。對(duì)于一個(gè)流程來說這很不錯(cuò)，
但當(dāng)你要實(shí)現(xiàn)多個(gè)流程時(shí)，你會(huì)看到管理狀態(tài)和流程變量的代碼被到處復(fù)制。最后，我們會(huì)整理這些代碼放到一個(gè)集中的庫(kù)
中。好，...這就是一個(gè)工作流管理系統(tǒng)了，不用費(fèi)心自己來實(shí)現(xiàn)，你可以從本文后面的列表中選擇一個(gè)。
A closer look
WFMS interfaces
一個(gè)工作流管理系統(tǒng)以流程定義作為輸入。在這里，可以將流程定義看作UML活動(dòng)圖、UML狀態(tài)圖或者有限狀態(tài)機(jī)。在提交一
張費(fèi)用單據(jù)、申請(qǐng)休假、要求一個(gè)報(bào)價(jià)、...之后，工作流系統(tǒng)負(fù)責(zé)維護(hù)這些流程定義的執(zhí)行狀態(tài)和上下文。為此，需要通
知工作流系統(tǒng)狀態(tài)的變化。運(yùn)行流程的狀態(tài)變化可以記錄下來，以備監(jiān)控管理。
Figure 2: Interfaces of a WFMS
定義 工作流系統(tǒng)的定義接口使流程開發(fā)人員能夠部署流程定義。注意，這里的“流程開發(fā)人員”可以是業(yè)務(wù)分析師和軟件開發(fā)人
員的組合。
圈套（Pitfall）
許多工作流管理系統(tǒng)的開發(fā)商想使你相信，通過使用他們的圖形化流程開發(fā)工具，只要業(yè)務(wù)分析師就可以生成流程定義。
這種幻想源于“編程很難”這樣的事實(shí)。開發(fā)商的銷售人員喜歡說“看，你不用寫一行代碼”。不用寫代碼是好事，可大部
分開發(fā)商在這點(diǎn)上走的太遠(yuǎn)，忽略了在某些場(chǎng)合提供一種將代碼集成到流程定義中的機(jī)制是很適合的。在將工作流系統(tǒng)
作為EAI平臺(tái)時(shí)，必須在流程中集成代碼。開發(fā)流程定義需要業(yè)務(wù)分析師和軟件開發(fā)人員的合作。一個(gè)好的圖形流程設(shè)計(jì)
工具應(yīng)該能夠支持這種合作。
執(zhí)行 執(zhí)行接口使用戶和系統(tǒng)可以操作流程實(shí)例。流程實(shí)例是流程定義的執(zhí)行。流程定義的控制流通過狀態(tài)機(jī)描述。執(zhí)行接口
的兩個(gè)主要方法是啟動(dòng)一個(gè)流程實(shí)例和通知工作流系統(tǒng)一個(gè)狀態(tài)結(jié)束了。
應(yīng)用 應(yīng)用接口代表了由工作流系統(tǒng)發(fā)起的工作流系統(tǒng)和外部系統(tǒng)之間的交互。當(dāng)一個(gè)用戶或系統(tǒng)操作一個(gè)流程實(shí)例的運(yùn)行時(shí)，
會(huì)生成一些事件（如一個(gè)遷移的執(zhí)行）。流程定義中可以指定一段響應(yīng)一個(gè)事件的可執(zhí)行代碼邏輯，這段代碼和組織內(nèi)
外部的其他系統(tǒng)打交道。
監(jiān)控 管理人員通過監(jiān)控接口獲得流程運(yùn)行的確切數(shù)據(jù)。有時(shí)，運(yùn)行日志也可用于審計(jì)。
這些是WfMC參考模型（reference model of the WfMC）中定義的五個(gè)接口中的四個(gè)。
流程定義的四個(gè)層次
在下面這部分，我嘗試回答這樣的問題“什么是流程定義包括的內(nèi)容？”。這是從各種規(guī)范和工具所使用模型的原則和概念中
總結(jié)得來的，反映了大部分模型中通用的基本思想。流程定義的內(nèi)容可以分為四個(gè)不同的層次：狀態(tài)（state）、上下文
（context）、程序邏輯（programming logic）和用戶界面（UI）。
狀態(tài)層
所有狀態(tài)和控制流的表述，都屬于業(yè)務(wù)流程的狀態(tài)層。標(biāo)準(zhǔn)編程語(yǔ)言中的控制流來源于Von Neuman體系?？刂屏鞫x了必須
被執(zhí)行的指令的順序，控制流由我們書寫的命令、if語(yǔ)句、循環(huán)語(yǔ)句等確定。在業(yè)務(wù)流程中的控制流基本與此一致。但在業(yè)
務(wù)流程中不是使用命令而是使用狀態(tài)作為基本元素。
在流程中，狀態(tài) (或者說等待狀態(tài))代表了一種對(duì)外部參與者（actor）的依賴。狀態(tài)的意思就像“現(xiàn)在X系統(tǒng)或某某人必須作
某些事，在此等待直到參與者通知這些任務(wù)已完成”。狀態(tài)定義了一種對(duì)外部提供結(jié)果的依賴。狀態(tài)典型的例子是批準(zhǔn)步驟
（step）。
流程定義中的狀態(tài)也指定了執(zhí)行依賴于哪個(gè)參與者。在活動(dòng)圖中，泳道（swimlanes）的標(biāo)注代表這些參與者的名字。工作
流系統(tǒng)使用這些信息構(gòu)建任務(wù)列表，這是一般工作流系統(tǒng)都有的功能。如前所述，參與者可以是人也可以是系統(tǒng)。對(duì)于需要
人參與的狀態(tài)，工作流系統(tǒng)必須在運(yùn)行時(shí)計(jì)算出具體的個(gè)人。這樣的計(jì)算使工作流系統(tǒng)必須依賴于組織結(jié)構(gòu)信息。關(guān)于這方
面的一篇非常有趣的文章是在further reading section提到的“工作流應(yīng)用中的組織管理
”（ ‘Organizational Management in Workflow Applications‘）。
流程定義的控制流包含一組狀態(tài)和它們之間的關(guān)系。狀態(tài)之間的邏輯關(guān)系描述了哪些執(zhí)行路徑可以同時(shí)執(zhí)行，那些不可以。
同步執(zhí)行路徑用分叉（forks）和聯(lián)合（joins）建模，異步執(zhí)行路徑用判斷（decisions）和合并（ merges）建模。注意在
大多數(shù)模型中，在每個(gè)狀態(tài)之前都有一個(gè)隱式合并。
UML活動(dòng)圖經(jīng)常被用來做業(yè)務(wù)流程建模。作為一種直觀和通用的表達(dá)，活動(dòng)圖在圖形表述上有一個(gè)主要問題，就是沒有區(qū)分
狀態(tài)和動(dòng)作，它們都用活動(dòng)來表示。缺少這種區(qū)分（導(dǎo)致狀態(tài)概念的缺失）是學(xué)術(shù)派對(duì)UML活動(dòng)圖的主要批評(píng)。UML活動(dòng)圖的
第二個(gè)問題是在UML2.0版中引入的。當(dāng)多個(gè)遷移（transitions）到達(dá)一個(gè)活動(dòng)時(shí)，以前的版本規(guī)定這是一個(gè)缺省合并
（merge），在2.0版中規(guī)定這是一個(gè)需要同步的缺省聯(lián)合（join）。在我看來，UML活動(dòng)圖的圖形部分仍舊可以用來對(duì)業(yè)務(wù)
流程狀態(tài)層次建模，只要使用時(shí)對(duì)兩條構(gòu)建語(yǔ)義作如下的變化：
在用圖形表述業(yè)務(wù)流程時(shí)，只建模狀態(tài)層（狀態(tài)和控制流），不要包括動(dòng)作。這意味著圖形中的矩形都是狀態(tài)而不是活動(dòng)
如果多個(gè)遷移到達(dá)一個(gè)狀態(tài)，缺省定義為不需要同步的合并（merges）
在流程運(yùn)行過程中，工作流系統(tǒng)用一個(gè)令牌（token）作為指針跟蹤流程的狀態(tài)。這相當(dāng)于Von Neuman體系中的程序計(jì)數(shù)器。
當(dāng)令牌到達(dá)一個(gè)狀態(tài)時(shí)，它被分配給工作流系統(tǒng)等待的外部參與者。外部參與者可以是個(gè)人、組織或者計(jì)算機(jī)系統(tǒng)。我們定
義流程運(yùn)行的執(zhí)行人或系統(tǒng)為“參與者”（actor）。只有在工作流系統(tǒng)將令牌分配給一個(gè)參與者時(shí)，才需要訪問組織結(jié)構(gòu)信
息。工作流系統(tǒng)通過分配令牌構(gòu)建任務(wù)列表。
上下文層
流程上下文變量（process context variable） ，或簡(jiǎn)稱變量，是與流程實(shí)例相關(guān)的變量。流程開發(fā)人員可以使用流程變
量存儲(chǔ)跨越流程實(shí)例整個(gè)生命周期的數(shù)據(jù)。一些工作流管理系統(tǒng)有固定數(shù)目的數(shù)據(jù)類型，另一些你可以定義自己的數(shù)據(jù)類
型。
注意變量也可以用來存放引用（ references）。一個(gè)變量可以引用如數(shù)據(jù)庫(kù)中的記錄、網(wǎng)絡(luò)上的文件。什么時(shí)候使用引用，
取決于使用引用數(shù)據(jù)的其他應(yīng)用。
和流程變量相關(guān)的另一個(gè)令人感興趣的方面是：工作流系統(tǒng)如何將數(shù)據(jù)轉(zhuǎn)化為信息。工作流是用于組織內(nèi)部跨越各種異構(gòu)
系統(tǒng)實(shí)現(xiàn)任務(wù)和數(shù)據(jù)協(xié)同的。對(duì)于業(yè)務(wù)流程中人工執(zhí)行的任務(wù)，工作流系統(tǒng)負(fù)責(zé)從其他相關(guān)系統(tǒng)，如SAP、數(shù)據(jù)庫(kù)、CRM系統(tǒng)、
文檔管理系統(tǒng)收集數(shù)據(jù)。在業(yè)務(wù)流程的每一個(gè)人工步驟，只有相關(guān)聯(lián)的數(shù)據(jù)項(xiàng)被從異構(gòu)系統(tǒng)中收集和計(jì)算。通過這種方式，
從不同系統(tǒng)來的數(shù)據(jù)被轉(zhuǎn)換并展現(xiàn)為信息。
程序邏輯層
如前所述，動(dòng)作是在流程運(yùn)行過程中，工作流系統(tǒng)響應(yīng)指定的事件（event）執(zhí)行的一段程序邏輯（programming logic）。
程序邏輯可以是二進(jìn)制或源代碼形式的、用任何語(yǔ)言或腳本編寫的軟件。程序邏輯層是所有這些軟件片斷和關(guān)于在什么事件
發(fā)生時(shí)調(diào)用它們的信息的組合。程序邏輯的例子包括發(fā)Email、通過消息代理發(fā)消息、從ERP系統(tǒng)中拿數(shù)據(jù)和更新數(shù)據(jù)庫(kù)。
用戶界面層
一個(gè)參與者通過向流程變量中填充數(shù)據(jù)的事件，來觸發(fā)結(jié)束一個(gè)狀態(tài)。比如，在請(qǐng)假的例子中，老板提供“同意”或“不同意”
數(shù)據(jù)到流程中。某些工作流系統(tǒng)允許指定哪些數(shù)據(jù)可以填充到流程中，以及它們?nèi)绾卧诹鞒套兞恐写鎯?chǔ)。通過這些信息，可
以生成從用戶收集信息的UI表單。基于流程定義生成用戶提交表單的Web應(yīng)用例子，可以訪問the jBpm online demo。
工作流全景
可執(zhí)行流程與工作流管理系統(tǒng)的比較（Executional processes versus a WFMS）
當(dāng)前在BPM領(lǐng)域中，關(guān)于可執(zhí)行業(yè)務(wù)流程的規(guī)范有趨向于統(tǒng)一集中的趨勢(shì)。 XLANG, WSFL 和BPML合并為基于交互（消息交換）
的BPEL。BPEL在面向服務(wù)體系結(jié)構(gòu)(SOA)的大背景下定義。它的前提條件之一是涉及的服務(wù)必須用WSDL聲明。BPEL規(guī)定了一
套XML語(yǔ)法，這套語(yǔ)法可以看作一種編程語(yǔ)言，用來描述包括對(duì)WSDL定義的服務(wù)調(diào)用的控制流。
在可執(zhí)行業(yè)務(wù)流程和基于狀態(tài)的工作流管理系統(tǒng)所使用的方法中，我注意到了三點(diǎn)主要的區(qū)別：
基于狀態(tài)與面向消息：基于狀態(tài)的工作流系統(tǒng)以狀態(tài)（或者活動(dòng)）概念為中心。工作流引擎維護(hù)狀態(tài)并計(jì)算從一個(gè)狀態(tài)到另一個(gè)
狀態(tài)的遷移。另一方面，像BPEL這樣的可執(zhí)行流程以對(duì)輸入消息響應(yīng)的定義為中心。一組這些響應(yīng)外加其
他信息（other bells and whistles）可以看作一個(gè)業(yè)務(wù)流程。這也解釋了為什么BPEL可以看作是對(duì)基于
狀態(tài)的工作流系統(tǒng)的某些方面的補(bǔ)充。一個(gè)響應(yīng)輸入消息的BPEL onMessage事件處理器，可以在工作流狀
態(tài)之間的遷移中執(zhí)行。
流程實(shí)例ID與消息相關(guān)處理：可執(zhí)行業(yè)務(wù)流程的復(fù)雜性之一來自消息相關(guān)性的處理。流程描述的一部分必須說明BPEL引擎如何從
輸入消息中確定具體流程的標(biāo)識(shí)。這必須基于輸入消息的一個(gè)數(shù)據(jù)項(xiàng)。而工作流系統(tǒng)在每個(gè)流程實(shí)
例生成同時(shí)生成了實(shí)例ID，客戶端在后續(xù)調(diào)用引擎API時(shí)使用這個(gè)ID。
工作流引擎API與抽象服務(wù)端點(diǎn)（endpoint）：工作流系統(tǒng)提供一組集中的API，客戶端通過調(diào)用API完成與所有流程實(shí)例的交互。
在可執(zhí)行業(yè)務(wù)流程中，每個(gè)流程表現(xiàn)為一個(gè)服務(wù)。這意味著對(duì)于每個(gè)流程定義都有
一個(gè)不同的訪問點(diǎn)。
學(xué)術(shù)界
學(xué)術(shù)界對(duì)工作流的研究可以回溯到上個(gè)世紀(jì)七十年代。在當(dāng)前，研究領(lǐng)域趨向于認(rèn)為petr 網(wǎng)是所有流程定義語(yǔ)言之母。關(guān)
于petri網(wǎng)已有大量先進(jìn)的分析技術(shù)，去年在 2003 conference on Business Process Management上我有幸會(huì)晤了Petri教授。
對(duì)于大部分人能夠訪問和理解的有關(guān)Petyri網(wǎng)最好的研究之一是工作流模式(workflow patterns)。工作流模式比較了大量
的工作流管理系統(tǒng)并以petri網(wǎng)的術(shù)語(yǔ)表述了通用流程建模概念。
開放源代碼項(xiàng)目
最后我們看看真實(shí)世界中的工作流管理系統(tǒng)。選擇一個(gè)工作流管理系統(tǒng)是一件困難的事情，但有選擇總比沒有選擇好。:-)
本文闡述工作流基本概念的目的之一，就是使你能夠作更好的選擇。但我也意識(shí)到，對(duì)于現(xiàn)在的軟件架構(gòu)師來說，選擇工作
流系統(tǒng)是一件最具挑戰(zhàn)性的工作。
下面的列表來源于三個(gè)地方：my previous article, the list of Carlos E Perez, 和 list by Topicus.
jBpm - jBpm是本文作者編寫的一個(gè)靈活可擴(kuò)展的工作流管理系統(tǒng)。作為jBpm運(yùn)行時(shí)server輸入的業(yè)務(wù)流程使用簡(jiǎn)單強(qiáng)大的語(yǔ)言
表達(dá)并打包在流程檔案中。jBmp將工作流應(yīng)用開發(fā)的便利性和杰出的企業(yè)應(yīng)用集成（EAI）能力結(jié)合了起來。jBmp包括一
個(gè)Web應(yīng)用程序和一個(gè)日程安排程序。jBmp是一組J2SE組件，可以作為J2EE應(yīng)用集群部署。
OpenEbXML - OpenebXML項(xiàng)目致力于提供一個(gè)ebXML框架，主要支持不久將由 UN/CEFACT和OASIS發(fā)布的ebXML規(guī)范2.0版。
Werkflow - Werkflow是一個(gè)靈活可擴(kuò)展的基于流程和狀態(tài)的工作流引擎。它的目標(biāo)是滿足可以想象的所有工作流程，從企業(yè)級(jí)
的業(yè)務(wù)流程到小范圍的用戶交互流程。通過使用可插拔和分層結(jié)構(gòu)，可以方便地容納各種工作流語(yǔ)義。
OSWorkflow - OSWorkflow最獨(dú)到之處是絕對(duì)的靈活。
wfmOpen - WfMOpen是WfMC和OMG中所謂工作流設(shè)施（workflow facility） (工作流引擎)的J2EE實(shí)現(xiàn)。工作流通過擴(kuò)展的XPDL描
述。
OFBiz - OFBiz工作流引擎基于WfMC和OMG的規(guī)范，使用XPDL作為流程定義語(yǔ)言。
ObjectWeb Bonita - Bonita是一個(gè)符合WfMC規(guī)范、靈活的協(xié)同工作流系統(tǒng)。 對(duì)于各種動(dòng)作如流程概念建模、定義、實(shí)例化、流
程控制和用戶交互等提供了全面的集成圖形工具。 100% 基于瀏覽器、使用SOAP和XML數(shù)據(jù)綁定技術(shù)的
Web Services封裝了已有的工作流業(yè)務(wù)方法并將它們以基于J2EE的Web Service形式發(fā)布?；诨顒?dòng)預(yù)測(cè)模
型的第三代工作流引擎。
Bigbross Bossa -速度非?？?、輕量級(jí)的引擎，使用富有表達(dá)能力的Petri網(wǎng)定義工作流，不要求關(guān)系數(shù)據(jù)庫(kù)，使用簡(jiǎn)單，能和
Java應(yīng)用集成。事實(shí)上，它是按嵌入式設(shè)計(jì)的。
XFlow - XFlow運(yùn)行于EJB和servlet容器中。
Taverna - Taverna項(xiàng)目的目標(biāo)是提供一種語(yǔ)言和軟件工具，方便在eScience中使用工作流和分布計(jì)算技術(shù)。
Enhydra Shark - Shark完全基于WfMC和OMG標(biāo)準(zhǔn)，使用 XPDL作為工作流定義語(yǔ)言。流程和活動(dòng)的存儲(chǔ)使用Enhydra DODS。
PowerFolder - PowerFolder包括開發(fā)人員使用的studio，管理環(huán)境和一個(gè)運(yùn)行時(shí)引擎。
Breeze - Breeze一個(gè)輕量級(jí)、跨平臺(tái)、基于組件的工作流引擎原型。
Open Business Engine - Open Business Engine是一個(gè)開放源碼的Java工作流引擎，支持WfMC規(guī)范，包括接口1（XPDL）、
接口2/3（WAPI）和接口5。OBE為活動(dòng)的運(yùn)行提供了一個(gè)可控的集中環(huán)境。OBE主要基于J2EE實(shí)現(xiàn)。
OpenWFE - OpenWFE是一個(gè)開放源碼的Java工作流引擎。 它包括可升級(jí)的三個(gè)組件：引擎、工作列表和Web界面。它的流程定義
語(yǔ)言雖然使用XML格式，其靈感來源于 Scheme，一種Lisp方言。
Freefluo - Freefluo是一個(gè)使用Web Service的工作流協(xié)同工具，可以處理WSDL的Web Service調(diào)用。支持兩種XML格式的工作流
語(yǔ)言：IBM的WSFL和XScufl。Freefluo非常靈活，它的核心是不與任何工作流語(yǔ)言或執(zhí)行架構(gòu)關(guān)聯(lián)的可重用協(xié)同框架。
Freefluo包括可執(zhí)行使用WSFL一個(gè)子集描述的工作流的運(yùn)行庫(kù)。
ZBuilder - ZBuilder3是第二代工作流開發(fā)管理系統(tǒng)，也是一個(gè)開放源碼產(chǎn)品。它為不同的工作流引擎和工作流定義了一組標(biāo)準(zhǔn)
的JMX管理接口。
Twister - Twister的目標(biāo)是提供新一代、易集成、應(yīng)用Java領(lǐng)域中最新成果、面向B2B的工作流解決方案。流程引擎基于BPEL業(yè)
務(wù)流程規(guī)范和Web Service標(biāo)準(zhǔn)。
Con:cern - con:cern工作流引擎基于擴(kuò)展的案例（case）處理方法，流程由一組具有前后條件的活動(dòng)組成。
商業(yè)軟件提供商
Bea‘s WLI
Carnot
Dralasoft
Filenet
Fujitsu‘s i-Flow
IBM‘s holosofx tool
Intalio
Joinwork （譯者加:-) ）
Lombardi
Oakgrove‘s reactor
Oracle‘s integration platform
Q-Link
SAP‘s NetWeaver
Savvion
Seebeyond
Sonic‘s orchestration server
Staffware
Ultimus
Versata
WebMethod‘s process modeling
工具目錄
http:///Computers/Software/Workflow/Products/
A collection of links to tools for modelling business processes and workflows maintained by Bart-Jan Hommes at
TU Delft, the Netherlands.
規(guī)范
Michael zur Muehlen作了一個(gè)所有工作流相關(guān)規(guī)范的介紹性的幻燈片，很不錯(cuò)。
我同意John Pyke 和 Wil van der Aalst 的觀點(diǎn)：工作流標(biāo)準(zhǔn)還處于制定階段?，F(xiàn)在存在大量相互叢疊的規(guī)范。
在我看來，導(dǎo)致規(guī)范如此之多而同時(shí)每個(gè)規(guī)范的應(yīng)用又很有限的原因是，在工作流最基礎(chǔ)概念上大家達(dá)成的共識(shí)很少。工作
流是最容易讓你感到心煩的話題，因?yàn)楣ぷ髁鞅旧淼母拍顣?huì)和其他相關(guān)概念和技術(shù)混淆在一起?？梢耘e一個(gè)具體的例子，
比如說工作流完全是對(duì)Web Service的補(bǔ)充。你可以通過暴露接口以Web Service的方式訪問一個(gè)工作流管理系統(tǒng)，但是不能
假定總是必須通過Web Service接口訪問工作流系統(tǒng)接口。一些規(guī)范造成了這樣的假設(shè)。除了Web Service，其他容易混淆的
概念和技術(shù)包括：Email、流程之間的通訊、Web應(yīng)用和組織結(jié)構(gòu)。
在工作流領(lǐng)域第一個(gè)致力于標(biāo)準(zhǔn)化工作的是Workflow Management Coalition (WfMC)，開始于 1993。 WfMC發(fā)布的參考模型
很不錯(cuò)，它定義了工作流管理系統(tǒng)和其他相關(guān)部分之間的接口。WfMC的另一項(xiàng)成果是XPDL規(guī)范。 XPDL定義了描述工作流聲明
部分（declarative part）的XML結(jié)構(gòu)。我個(gè)人認(rèn)為，參考模型和XPDL是目前最好的規(guī)范。
JSR 207: Java的流程定義 -是由Java Community Process (JCP) 發(fā)起，如何在J2EE應(yīng)用服務(wù)器中實(shí)現(xiàn)業(yè)務(wù)流程自動(dòng)化的標(biāo)準(zhǔn)。
其基本模型是定義一個(gè)特殊類型的ejb session bean，作為一個(gè)業(yè)務(wù)流程的接口。JSR207標(biāo)準(zhǔn)化一組
XML元標(biāo)記（meta tags）作為JSR175元數(shù)據(jù)的一部分。JSR207 將session bean和元數(shù)據(jù)作為ejb容器
的輸入，然后生成綁定方法的代碼，這些方法在元數(shù)據(jù)中描述。此規(guī)范還處于初級(jí)階段，沒有發(fā)布任
何內(nèi)容。專家小組成立于 March 2003.
WfMC‘s XPDL - WfMC是由約300家成員參加的組織，基于參考模型定義了一系列的標(biāo)準(zhǔn)。參考模型用用例（use case）的形式描述
了工作流系統(tǒng)和其他相關(guān)部分之間的關(guān)系。XPDL是WfMC制定的描述業(yè)務(wù)流程控制流（control flow ）的XML格式
規(guī)范。
ebXML‘s BPSS - ebXML是協(xié)同流程的相關(guān)標(biāo)準(zhǔn)集，主要關(guān)注不同公司流程之間的通訊。可以看作EDI的繼承者。 ebXML是由OASIS
和UN/CEFACT聯(lián)合發(fā)起。 BPSS 是ebXML的規(guī)范，其中的概念和本文闡述的很接近。
BPMI‘s BPML & WSCI - (Intalio, Sun, SAP, ...)BPMI 也定義了一個(gè)規(guī)范 (BPMN) ，描述如何將“可執(zhí)行”業(yè)務(wù)流程可視化的表
現(xiàn)。
BPEL - (Microsoft, BEA, IBM, SAP & Siebel) BPEL由一系列基于消息交換的規(guī)范（ XLANG, WSFL, BPML）產(chǎn)生。還有一個(gè)將
此規(guī)范引入到Java的提案: BPELJ。 此規(guī)范描述如何處理輸入的消息，而不是對(duì)流程狀態(tài)進(jìn)行建模。就像本文提到的，
它不是一個(gè)關(guān)于業(yè)務(wù)流程規(guī)格化定義的規(guī)范。簡(jiǎn)單的說，可以將它看作XML形式的編程語(yǔ)言，提供將WSDL-Services組合
成控制流的能力。顧名思義，此規(guī)范重點(diǎn)在（也不只限于）Web Service。
OMG‘s Workflow management facility - 基于WfMC規(guī)范，定義如何向CORBA轉(zhuǎn)換。
UML - UML定義了建模和設(shè)計(jì)軟件系統(tǒng)的9類圖。每類圖包括可視化的表示和語(yǔ)義。其中活動(dòng)圖的目的就是要可視化的表現(xiàn)業(yè)務(wù)流
程。 注意到在一個(gè)流程定義包含四個(gè)層次的內(nèi)容，我想指出的是：一個(gè)流程定義包含的內(nèi)容遠(yuǎn)遠(yuǎn)多于它的可視化部分。
UML只涉及了可視化部分。
RosettaNet - RosettaNet主要定義了一組 Partner Interface Processes (PIP). 一個(gè) PIP 描述了一個(gè)有兩個(gè)交易參與者、
包括消息格式的流程。
UBL - The Universal Business Language (UBL)定義了用于不同組織間通訊的XML文檔標(biāo)準(zhǔn)庫(kù)?？梢钥醋魇菍?duì)ebXML的補(bǔ)充，因
為ebXML只定義了建立組織間流程的基礎(chǔ)。此規(guī)范的競(jìng)爭(zhēng)對(duì)手是 RosettaNet標(biāo)準(zhǔn)中的一個(gè)子集。
結(jié)論
我在本文中指出工作流市場(chǎng)還屬于年輕而又混亂（young and wild）的階段，但已經(jīng)有可靠的工具存在了:
到目前，像J2EE和.NET這樣成熟的集成平臺(tái)才可用。在這樣一個(gè)平臺(tái)上運(yùn)行工作流管理系統(tǒng)才能真正發(fā)揮工作流系統(tǒng)的附加價(jià)值。
這也是為什么只有在今天，工作流系統(tǒng)才被重新發(fā)現(xiàn)。
在 ‘The case for workflow‘一節(jié)，我們介紹了引入工作流管理系統(tǒng)，是如何同時(shí)在技術(shù)和業(yè)務(wù)上帶來投資回報(bào)的。
工作流在技術(shù)發(fā)展曲線的位置表明，BPM和工作流中使用的概念還需要明確。
“開放源代碼項(xiàng)目”和“商業(yè)軟件提供商”列表中的工具，可以讓你獲得工作流和業(yè)務(wù)流程管理的益處。
從以上所有這些中能得到的結(jié)論是：
規(guī)范還沒有成熟，沒有標(biāo)準(zhǔn)被大范圍采用
對(duì)于現(xiàn)在想應(yīng)用BPM的公司來講，比較工作流系統(tǒng)是一個(gè)極其困難的挑戰(zhàn)
盡管標(biāo)準(zhǔn)化工作慢了一拍，可好的工作流管理系統(tǒng)還是有的。這對(duì)于已經(jīng)在挑選工作流系統(tǒng)的組織來說是一個(gè)好消息。
|
|
