工作流 現(xiàn)狀 （原文）

作者Tom Baeyens 翻譯dinghong

前言

    如果數(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)在軟件開(kāi)發(fā)團(tuán)隊(duì)中談?wù)揜DBMS時(shí)，大部分人會(huì)有一個(gè)清晰的概念，在你和他們交流的時(shí)候，人們會(huì)通過(guò)輕微的點(diǎn)頭表示認(rèn)可或理解你所說(shuō)的。可當(dāng)使用工作流術(shù)語(yǔ)討論工作流時(shí)，他們會(huì)搖頭表示不同意，因?yàn)槊總€(gè)人對(duì)工作流術(shù)語(yǔ)都有不同的理解。

     導(dǎo)致形成這種狀況的原因之一，是在工作流中使用了過(guò)多的概念。在這個(gè)領(lǐng)域中的大量規(guī)范和工具沒(méi)有一個(gè)是相似的。當(dāng)然，它們相互之間有重疊并且會(huì)相互參考引證。
    在介紹工作流時(shí)有一個(gè)話題必須包括，那就是工作流和業(yè)務(wù)流程管理（BPM）的關(guān)系。術(shù)語(yǔ)“工作流”通常描述人與計(jì)算機(jī)系統(tǒng)的一系列相關(guān)交互。在開(kāi)發(fā)人員中，工作流經(jīng)常被提及。有時(shí)，工作流的意思是指一些不同的UI界面。業(yè)務(wù)流程管理的范圍比較廣，相比之下工作流多半局限于技術(shù)領(lǐng)域。業(yè)務(wù)流程管理還從管理人員的角度涉及了非技術(shù)問(wèn)題，比如分析、組織的效率。

    在本文中，我首先解釋什么是工作流管理系統(tǒng)，然后介紹業(yè)務(wù)流程管理的優(yōu)點(diǎn)。接下來(lái)描述一下為什么工作流市場(chǎng)乍看起來(lái)如此混亂。本文給出的主要結(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ò)程的規(guī)格化描述。一個(gè)流程實(shí)例是流程定義的一個(gè)運(yùn)行實(shí)體。 都目前為止，概念還比較清晰是不是？但當(dāng)再深入一步時(shí)，我們就要小心使用文字了。如何闡述流程中的步驟，現(xiàn)在還沒(méi)有一個(gè)統(tǒng)一的方式。這是各種工作流規(guī)范和工具之間主要的分歧。

    工作流系統(tǒng)另一個(gè)重要的職責(zé)是維護(hù)每一個(gè)流程運(yùn)行的上下文信息。 流程上下文變量（process context variable） ，或簡(jiǎn)稱變量，是與流程實(shí)例相關(guān)的變量。如，休假申請(qǐng)的開(kāi)始日期、數(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ì)帶來(lái)涉及其他多個(gè)應(yīng)用的新功能需求。企業(yè)應(yīng)用系統(tǒng)集成（EAI）就是通過(guò)使用多個(gè)專門應(yīng)用滿足軟件新需求的方法。有時(shí)，這只需要在兩個(gè)應(yīng)用之間提供數(shù)據(jù)通訊的通道。專門應(yīng)用將很多業(yè)務(wù)流程硬編碼在軟件中?？梢赃@么說(shuō)，在你購(gòu)買專門應(yīng)用時(shí)，你是購(gòu)買了一組固定的自動(dòng)化業(yè)務(wù)流程。而工作流管理系統(tǒng)是不必事先知道問(wèn)題域的相關(guān)信息的。工作流系統(tǒng)將業(yè)務(wù)流程描述作為輸入并管理流程實(shí)例的執(zhí)行，這使得它比專門應(yīng)用更靈活（當(dāng)然你也要花精力編寫(xiě)業(yè)務(wù)流程的規(guī)格化描述）。這就是為什么說(shuō)工作流系統(tǒng)和專門系統(tǒng)是相互補(bǔ)充的。工作流系統(tǒng)可以用來(lái)管理全局的業(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ù)工作流軟件的開(kāi)發(fā)。為了達(dá)到這個(gè)目的，大部分工作流系統(tǒng)都有一個(gè)方便的機(jī)制，來(lái)生成執(zhí)行任務(wù)的表單。對(duì)于專注于ISO 或者CMM認(rèn)證的組織，采用這種方式使用工作流系統(tǒng)能夠顯著提高生產(chǎn)率。 不用將過(guò)程用文字的形式寫(xiě)在紙上，工作流系統(tǒng)使你通過(guò)流程定義建模實(shí)現(xiàn)過(guò)程的自動(dòng)化（如使用基于Web的應(yīng)用）。

    工作流系統(tǒng)的第三種使用方式是：將工作流引擎嵌入到其他應(yīng)用中。在前面我們談到，專門應(yīng)用將指定問(wèn)題域相關(guān)的業(yè)務(wù)流程固化在軟件中。開(kāi)發(fā)專門應(yīng)用的公司也可以將工作流引擎嵌入到他們的軟件中。在這里，工作流引擎只是作為一個(gè)軟件組件，對(duì)于應(yīng)用的最終用戶是不可見(jiàn)的。將工作流引擎嵌入到應(yīng)用中的主要原因是為了重用（不重復(fù)發(fā)明輪子）和應(yīng)用軟件的可維護(hù)性。

The case for workflow

    對(duì)于引入工作流的組織，能夠在軟件開(kāi)發(fā)和業(yè)務(wù)兩個(gè)層次受益。

方便開(kāi)發(fā)

    工作流管理系統(tǒng)能夠簡(jiǎn)化企業(yè)級(jí)軟件開(kāi)發(fā)甚至維護(hù)。

• 降低開(kāi)發(fā)風(fēng)險(xiǎn) - 通過(guò)使用狀態(tài)和動(dòng)作這樣的術(shù)語(yǔ)，業(yè)務(wù)分析師和開(kāi)發(fā)人員使用同一種語(yǔ)言交談。這樣開(kāi)發(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)用開(kāi)發(fā) - 你的軟件不用再關(guān)注流程的參與者，開(kāi)發(fā)起來(lái)更快，代碼更容易維護(hù)。

業(yè)務(wù)流程管理 (BPM)

    在自動(dòng)化業(yè)務(wù)流程之前，分析并將它們規(guī)格化是一件艱苦但會(huì)有很好回報(bào)的工作。e-workflow.org對(duì)于分析流程能夠帶了的益處有不錯(cuò)的闡述：

• 提高效率 - 許多流程在自動(dòng)化過(guò)程中會(huì)去除一些不必要的步驟
• 較好的流程控制 - 通過(guò)標(biāo)準(zhǔn)的工作方法和跟蹤審計(jì)，提高了業(yè)務(wù)流程的管理
• 改進(jìn)客戶服務(wù) - 因?yàn)榱鞒痰囊恢滦?，提高了?duì)客戶響應(yīng)的可預(yù)見(jiàn)性
• 靈活 - 跨越流程的軟件控制，使流程可以按照業(yè)務(wù)的需要重新設(shè)計(jì)。
• 業(yè)務(wù)流程改進(jìn) - 對(duì)流程的關(guān)注，使它們趨向于流暢和簡(jiǎn)單

    我認(rèn)為他們還遺漏了一個(gè)使用工作流系統(tǒng)最重要的因數(shù)：提高對(duì)迭代開(kāi)發(fā)的支持。如果軟件中業(yè)務(wù)流程部分不容易更改，組織就會(huì)花很大的精力在開(kāi)發(fā)前的業(yè)務(wù)流程分析中，希望一次成功。但可悲的是，在任何軟件項(xiàng)目開(kāi)發(fā)中，這都很少能實(shí)現(xiàn)。工作流系統(tǒng)使得新業(yè)務(wù)流程很容易部署，業(yè)務(wù)流程相關(guān)的軟件可以一種迭代的方式開(kāi)發(fā)，因此使用工作流系統(tǒng)使開(kāi)發(fā)更有效、風(fēng)險(xiǎn)更低。

缺失的一環(huán)（Missing link）

    我確實(shí)認(rèn)為工作流系統(tǒng)是企業(yè)應(yīng)用開(kāi)發(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)軟件。上述問(wèn)題也適用于采用大型外部ERP軟件包的企業(yè)。進(jìn)一步，假設(shè)我們認(rèn)識(shí)到這個(gè)問(wèn)題，并打算將一個(gè)流程相關(guān)的代碼都集中起來(lái)。對(duì)于一個(gè)流程來(lái)說(shuō)這很不錯(cuò)，但當(dāng)你要實(shí)現(xiàn)多個(gè)流程時(shí)，你會(huì)看到管理狀態(tài)和流程變量的代碼被到處復(fù)制。最后，我們會(huì)整理這些代碼放到一個(gè)集中的庫(kù)中。好，...這就是一個(gè)工作流管理系統(tǒng)了，不用費(fèi)心自己來(lá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)變化可以記錄下來(lái)，以備監(jiān)控管理。

 

Figure 2: Interfaces of a WFMS

 

 

• 定義   工作流系統(tǒng)的定義接口使流程開(kāi)發(fā)人員能夠部署流程定義。注意，這里的“流程開(kāi)發(fā)人員”可以是業(yè)務(wù)分析師和軟件開(kāi)發(fā)人員的組合。

  圈套（Pitfall） 許多工作流管理系統(tǒng)的開(kāi)發(fā)商想使你相信，通過(guò)使用他們的圖形化流程開(kāi)發(fā)工具，只要業(yè)務(wù)分析師就可以生成流程定義。這種幻想源于“編程很難”這樣的事實(shí)。開(kāi)發(fā)商的銷售人員喜歡說(shuō)“看，你不用寫(xiě)一行代碼”。不用寫(xiě)代碼是好事，可大部分開(kāi)發(fā)商在這點(diǎn)上走的太遠(yuǎn)，忽略了在某些場(chǎng)合提供一種將代碼集成到流程定義中的機(jī)制是很適合的。在將工作流系統(tǒng)作為EAI平臺(tái)時(shí)，必須在流程中集成代碼。開(kāi)發(fā)流程定義需要業(yè)務(wù)分析師和軟件開(kāi)發(fā)人員的合作。一個(gè)好的圖形流程設(shè)計(jì)工具應(yīng)該能夠支持這種合作。

• 執(zhí)行   執(zhí)行接口使用戶和系統(tǒng)可以操作流程實(shí)例。流程實(shí)例是流程定義的執(zhí)行。流程定義的控制流通過(guò)狀態(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)控   管理人員通過(guò)監(jiān)控接口獲得流程運(yùn)行的確切數(shù)據(jù)。有時(shí)，運(yùn)行日志也可用于審計(jì)。

流程定義的四個(gè)層次

    在下面這部分，我嘗試回答這樣的問(wèn)題“什么是流程定義包括的內(nèi)容？”。這是從各種規(guī)范和工具所使用模型的原則和概念中總結(jié)得來(lái)的，反映了大部分模型中通用的基本思想。流程定義的內(nèi)容可以分為四個(gè)不同的層次：狀態(tài)（state）、上下文（context）、程序邏輯（programming logic）和用戶界面（UI）。

狀態(tài)層

    所有狀態(tài)和控制流的表述，都屬于業(yè)務(wù)流程的狀態(tài)層。標(biāo)準(zhǔn)編程語(yǔ)言中的控制流來(lái)源于Von Neuman體系?？刂屏鞫x了必須被執(zhí)行的指令的順序，控制流由我們書(shū)寫(xiě)的命令、if語(yǔ)句、循環(huán)語(yǔ)句等確定。在業(yè)務(wù)流程中的控制流基本與此一致。但在業(yè)務(wù)流程中不是使用命令而是使用狀態(tài)作為基本元素。

    在流程中，狀態(tài) (或者說(shuō)等待狀態(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)常被用來(lái)做業(yè)務(wù)流程建模。作為一種直觀和通用的表達(dá)，活動(dòng)圖在圖形表述上有一個(gè)主要問(wèn)題，就是沒(méi)有區(qū)分狀態(tài)和動(dòng)作，它們都用活動(dòng)來(lái)表示。缺少這種區(qū)分（導(dǎo)致?tīng)顟B(tài)概念的缺失）是學(xué)術(shù)派對(duì)UML活動(dòng)圖的主要批評(píng)。UML活動(dòng)圖的第二個(gè)問(wèn)題是在UML2.0版中引入的。當(dāng)多個(gè)遷移（transitions）到達(dá)一個(gè)活動(dòng)時(shí)，以前的版本規(guī)定這是一個(gè)缺省合并（merge），在2.0版中規(guī)定這是一個(gè)需要同步的缺省聯(lián)合（join）。在我看來(lái)，UML活動(dòng)圖的圖形部分仍舊可以用來(lái)對(duì)業(yè)務(wù)流程狀態(tài)層次建模，只要使用時(shí)對(duì)兩條構(gòu)建語(yǔ)義作如下的變化：

1. 在用圖形表述業(yè)務(wù)流程時(shí)，只建模狀態(tài)層（狀態(tài)和控制流），不要包括動(dòng)作。這意味著圖形中的矩形都是狀態(tài)而不是活動(dòng)
2. 如果多個(gè)遷移到達(dá)一個(gè)狀態(tài)，缺省定義為不需要同步的合并（merges）

    在流程運(yùn)行過(guò)程中，工作流系統(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í)，才需要訪問(wèn)組織結(jié)構(gòu)信息。工作流系統(tǒng)通過(guò)分配令牌構(gòu)建任務(wù)列表。

上下文層

    流程上下文變量（process context variable） ，或簡(jiǎn)稱變量，是與流程實(shí)例相關(guān)的變量。流程開(kāi)發(fā)人員可以使用流程變量存儲(chǔ)跨越流程實(shí)例整個(gè)生命周期的數(shù)據(jù)。一些工作流管理系統(tǒng)有固定數(shù)目的數(shù)據(jù)類型，另一些你可以定義自己的數(shù)據(jù)類型。

    注意變量也可以用來(lái)存放引用（ 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ì)算。通過(guò)這種方式，從不同系統(tǒng)來(lái)的數(shù)據(jù)被轉(zhuǎn)換并展現(xiàn)為信息。

程序邏輯層

    如前所述，動(dòng)作是在流程運(yùn)行過(guò)程中，工作流系統(tǒng)響應(yīng)指定的事件（event）執(zhí)行的一段程序邏輯（programming logic）。程序邏輯可以是二進(jìn)制或源代碼形式的、用任何語(yǔ)言或腳本編寫(xiě)的軟件。程序邏輯層是所有這些軟件片斷和關(guān)于在什么事件發(fā)生時(shí)調(diào)用它們的信息的組合。程序邏輯的例子包括發(fā)Email、通過(guò)消息代理發(fā)消息、從ERP系統(tǒng)中拿數(shù)據(jù)和更新數(shù)據(jù)庫(kù)。

用戶界面層

工作流全景

可執(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ǔ)言，用來(lái)描述包括對(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ù)雜性之一來(lái)自消息相關(guān)性的處理。流程描述的一部分必須說(shuō)明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，客戶端通過(guò)調(diào)用API完成與所有流程實(shí)例的交互。在可執(zhí)行業(yè)務(wù)流程中，每個(gè)流程表現(xiàn)為一個(gè)服務(wù)。這意味著對(duì)于每個(gè)流程定義都有一個(gè)不同的訪問(wèn)點(diǎn)。

學(xué)術(shù)界

開(kāi)放源代碼項(xiàng)目

    最后我們看看真實(shí)世界中的工作流管理系統(tǒng)。選擇一個(gè)工作流管理系統(tǒng)是一件困難的事情，但有選擇總比沒(méi)有選擇好。:-) 本文闡述工作流基本概念的目的之一，就是使你能夠作更好的選擇。但我也意識(shí)到，對(duì)于現(xiàn)在的軟件架構(gòu)師來(lái)說(shuō)，選擇工作流系統(tǒng)是一件最具挑戰(zhàn)性的工作。

    下面的列表來(lái)源于三個(gè)地方：my previous article, the list of Carlos E Perez, 和 list by Topicus.

• jBpm - jBpm是本文作者編寫(xiě)的一個(gè)靈活可擴(kuò)展的工作流管理系統(tǒng)。作為jBpm運(yùn)行時(shí)server輸入的業(yè)務(wù)流程使用簡(jiǎn)單強(qiáng)大的語(yǔ)言表達(dá)并打包在流程檔案中。jBmp將工作流應(yīng)用開(kāi)發(fā)的便利性和杰出的企業(yè)應(yīng)用集成（EAI）能力結(jié)合了起來(lái)。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ù)流程到小范圍的用戶交互流程。通過(guò)使用可插拔和分層結(jié)構(gòu)，可以方便地容納各種工作流語(yǔ)義。
• OSWorkflow - OSWorkflow最獨(dú)到之處是絕對(duì)的靈活。
• wfmOpen - WfMOpen是WfMC和OMG中所謂工作流設(shè)施（workflow facility） (工作流引擎)的J2EE實(shí)現(xiàn)。工作流通過(guò)擴(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包括開(kāi)發(fā)人員使用的studio，管理環(huán)境和一個(gè)運(yùn)行時(shí)引擎。
• Breeze - Breeze一個(gè)輕量級(jí)、跨平臺(tái)、基于組件的工作流引擎原型。
• Open Business Engine - Open Business Engine是一個(gè)開(kāi)放源碼的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è)開(kāi)放源碼的Java工作流引擎。 它包括可升級(jí)的三個(gè)組件：引擎、工作列表和Web界面。它的流程定義語(yǔ)言雖然使用XML格式，其靈感來(lái)源于 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是第二代工作流開(kāi)發(fā)管理系統(tǒng)，也是一個(gè)開(kāi)放源碼產(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è)軟件提供商

• Carnot
• Dralasoft
• Filenet
• Intalio
• intelliFlow 
• Lombardi
• Q-Link
• Savvion
• Seebeyond
• Staffware
• Ultimus
• Versata

• http://dmoz.org/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ī)范。

    在我看來(lái)，導(dǎo)致規(guī)范如此之多而同時(shí)每個(gè)規(guī)范的應(yīng)用又很有限的原因是，在工作流最基礎(chǔ)概念上大家達(dá)成的共識(shí)很少。工作流是最容易讓你感到心煩的話題，因?yàn)?strong>工作流本身的概念會(huì)和其他相關(guān)概念和技術(shù)混淆在一起。可以舉一個(gè)具體的例子，比如說(shuō)工作流完全是對(duì)Web Service的補(bǔ)充。你可以通過(guò)暴露接口以Web Service的方式訪問(wèn)一個(gè)工作流管理系統(tǒng)，但是不能假定總是必須通過(guò)Web Service接口訪問(wèn)工作流系統(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)，開(kāi)始于 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í)階段，沒(méi)有發(fā)布任何內(nèi)容。專家小組成立于 March 2003.
• XPDL - WfMC是由約300家成員參加的組織，基于參考模型定義了一系列的標(biāo)準(zhǔn)。參考模型用用例（use case）的形式描述了工作流系統(tǒng)和其他相關(guān)部分之間的關(guān)系。XPDL是WfMC制定的描述業(yè)務(wù)流程控制流（control flow ）的XML格式規(guī)范。
• BPSS - ebXML是協(xié)同流程的相關(guān)標(biāo)準(zhǔn)集，主要關(guān)注不同公司流程之間的通訊?？梢钥醋鱁DI的繼承者。 ebXML是由OASIS和UN/CEFACT聯(lián)合發(fā)起。 BPSS 是ebXML的規(guī)范，其中的概念和本文闡述的很接近。
• 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)單的說(shuō)，可以將它看作XML形式的編程語(yǔ)言，提供將WSDL-Services組合成控制流的能力。顧名思義，此規(guī)范重點(diǎn)在（也不只限于）Web Service。
• - 基于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ǔ)充，因?yàn)閑bXML只定義了建立組織間流程的基礎(chǔ)。此規(guī)范的競(jìng)爭(zhēng)對(duì)手是 RosettaNet標(biāo)準(zhǔn)中的一個(gè)子集。

結(jié)論

    我在本文中指出工作流市場(chǎng)還屬于年輕而又混亂（young and wild）的階段，但已經(jīng)有可靠的工具存在了:

1. 到目前，像J2EE和.NET這樣成熟的集成平臺(tái)才可用。在這樣一個(gè)平臺(tái)上運(yùn)行 工作流 管理系統(tǒng)才能真正發(fā)揮工作流系統(tǒng)的附加價(jià)值。這也是為什么只有在今天，工作流系統(tǒng)才被重新發(fā)現(xiàn)。
2. 在 'The case for workflow'一節(jié)，我們介紹了引入工作流管理系統(tǒng)，是如何同時(shí)在技術(shù)和業(yè)務(wù)上帶來(lái)投資回報(bào)的。
3. 工作流在技術(shù)發(fā)展曲線的位置表明，BPM和工作流中使用的概念還需要明確。
4. “開(kāi)放源代碼項(xiàng)目”和“商業(yè)軟件提供商”列表中的工具，可以讓你獲得工作流和業(yè)務(wù)流程管理的益處。

    從以上所有這些中能得到的結(jié)論是：

1. 規(guī)范還沒(méi)有成熟，沒(méi)有標(biāo)準(zhǔn)被大范圍采用
2. 對(duì)于現(xiàn)在想應(yīng)用BPM的公司來(lái)講，比較工作流系統(tǒng)是一個(gè)極其困難的挑戰(zhàn)
3. 盡管標(biāo)準(zhǔn)化工作慢了一拍，可好的工作流管理系統(tǒng)還是有的。這對(duì)于已經(jīng)在挑選工作流系統(tǒng)的組織來(lái)說(shuō)是一個(gè)好消息。

    我希望本文能夠激發(fā)你對(duì)工作流的興趣并且能夠?yàn)槟氵M(jìn)行有效的對(duì)比提供正確的背景知識(shí)。

Further reading

• Workflow Patterns -Wil van der Aalst教授的工作流模式學(xué)術(shù)研究網(wǎng)站
• ebpml.org - 有關(guān)業(yè)務(wù)流程管理和工作流的網(wǎng)站，信息量大、全面
• Business process management group - The Business Process Management Group (founded in 1992) is a global business club exchanging ideas and best practice in business process and change management.
• Enix - 英國(guó)流程管理顧問(wèn)公司，在網(wǎng)站上有不錯(cuò)的內(nèi)容
• ebizq.net - Commercial community that has booths, webinars and other interesting stuff put together in a nice website.
• An introduction to petri nets - The title says it all.
• Organizational Management in Workflow Applications- An interesting article that discusses the relation between business processes and the organisational data involved.
• Web services orchestration - an HP-paper that reviews the emerging technologies tools and standards. (Januari 2003)
• Business process standards for web services - An article that discusses the various aspects involved in workflow and BPM.

  Thanks

      A special thanks for Gustavo Maciel Dias Vieira and Jef Vanbockryck for their valuable feedback on the draft versions of this article.

  about the author Tom Baeyens leads the jBpm support organisation, specialized in Java, workflow and business process management. His expertises are both at a technical, analysis and at a business level. Tom is the founder of jbpm.org, an open source workflow engine. Tom is also a member of the expertgroup of the JSR 207: Process Definition for Java. Tom Baeyens can be contacted at tom at jbpm.org