工作流現(xiàn)狀 (原文) 作者Tom Baeyens 翻譯dinghong 前言如果數(shù)據(jù)庫系統(tǒng)( database systems)像受人尊敬的智者講述的條理清晰的故事,那么工作流(workflow)就像一群乳臭未干的小子在大談各自的“哲理”。之所以這樣講,我是想指出,工作流系統(tǒng) (workflow management systems)還處于技術(shù)發(fā)展曲線( technology hype curve)上的初級階段。在這個領(lǐng)域我們將面臨一個激動人心的階段。 為了描述這一點,可以將工作流和關(guān)系數(shù)據(jù)庫系統(tǒng)(RDBMS)做一個對比。當(dāng)在軟件開發(fā)團隊中談?wù)揜DBMS時,大部分人會有一個清晰的概念,在你和他們交流的時候,人們會通過輕微的點頭表示認(rèn)可或理解你所說的。可當(dāng)使用工作流術(shù)語討論工作流時,他們會搖頭表示不同意,因為每個人對工作流術(shù)語都有不同的理解。
![]() Figure 1: Workflow vs. RDBMS positioned in the hype-curve 導(dǎo)致形成這種狀況的原因之一,是在工作流中使用了過多的概念。在這個領(lǐng)域中的大量規(guī)范和工具沒有一個是相似的。當(dāng)然,它們相互之間有重疊并且會相互參考引證。 在本文中,我首先解釋什么是工作流管理系統(tǒng),然后介紹業(yè)務(wù)流程管理的優(yōu)點。接下來描述一下為什么工作流市場乍看起來如此混亂。本文給出的主要結(jié)論是:選擇工作流系統(tǒng)是想用工作流系統(tǒng)的公司,將要面對的最困難的事情。為此,本文的核心部分描述了一個流程定義(process definition)的四個層次,為你選擇工作流提供一個基礎(chǔ)。本文還用中立的語言描述了工作流和BPM的通用概念。最后,給出了一些規(guī)范和工具的指導(dǎo)性描述。 什么是工作流管理系統(tǒng)(WFMS)定義工作流系統(tǒng)是以規(guī)格化的流程描述作為輸入的軟件組件,它維護流程的運行狀態(tài),并在人和應(yīng)用之間分派活動。 為了后面的描述,我們先定義一些基本的術(shù)語:流程定義(process definition)和流程實例(process instance). 一個流程定義是一個業(yè)務(wù)流程或過程的規(guī)格化描述。一個流程實例是流程定義的一個運行實體。 都目前為止,概念還比較清晰是不是?但當(dāng)再深入一步時,我們就要小心使用文字了。如何闡述流程中的步驟,現(xiàn)在還沒有一個統(tǒng)一的方式。這是各種工作流規(guī)范和工具之間主要的分歧。
工作流系統(tǒng)另一個重要的職責(zé)是維護每一個流程運行的上下文信息。 流程上下文變量(process context variable) ,或簡稱變量,是與流程實例相關(guān)的變量。如,休假申請的開始日期、數(shù)據(jù)庫中一條記錄的鍵值、文檔管理系統(tǒng)中一篇文檔的索引等。通常在流程定義中聲明這些變量,然后在流程實例生成時,這些流程變量被實例化。所有成熟的工作流管理系統(tǒng)都支持定制的變量類型。 目標(biāo)領(lǐng)域(Target usage)使用工作流管理系統(tǒng)的目的之一是作為企業(yè)應(yīng)用系統(tǒng)集成(EAI)的平臺。在當(dāng)前大部分企業(yè)級IT架構(gòu)中,各種各樣的異構(gòu)(heterogeneous)應(yīng)用和數(shù)據(jù)庫運行在企業(yè)內(nèi)網(wǎng)中。在這些系統(tǒng)被應(yīng)用到組織時,都有一個清晰的目標(biāo)。例如,客戶管理、文檔管理、供應(yīng)鏈、訂單、支付、資源計劃等等。讓我們稱這些系統(tǒng)為專門應(yīng)用( dedicated applications)。每一個專門應(yīng)用都包含它們所支持業(yè)務(wù)流程的領(lǐng)域知識。這些專門應(yīng)用中的自動化流程,被拼裝到企業(yè)中更大的非自動化流程中。每當(dāng)一個這樣的專門應(yīng)用安裝并投入使用,都會帶來涉及其他多個應(yīng)用的新功能需求。企業(yè)應(yīng)用系統(tǒng)集成(EAI)就是通過使用多個專門應(yīng)用滿足軟件新需求的方法。有時,這只需要在兩個應(yīng)用之間提供數(shù)據(jù)通訊的通道。專門應(yīng)用將很多業(yè)務(wù)流程硬編碼在軟件中。可以這么說,在你購買專門應(yīng)用時,你是購買了一組固定的自動化業(yè)務(wù)流程。而工作流管理系統(tǒng)是不必事先知道問題域的相關(guān)信息的。工作流系統(tǒng)將業(yè)務(wù)流程描述作為輸入并管理流程實例的執(zhí)行,這使得它比專門應(yīng)用更靈活(當(dāng)然你也要花精力編寫業(yè)務(wù)流程的規(guī)格化描述)。這就是為什么說工作流系統(tǒng)和專門系統(tǒng)是相互補充的。工作流系統(tǒng)可以用來管理全局的業(yè)務(wù)流程。如果專門應(yīng)用支持你所需要的業(yè)務(wù)流程,那么使用專門應(yīng)用。在此討論的工作流系統(tǒng)的第一種使用方式就是:結(jié)合所有的專門應(yīng)用,使用工作流系統(tǒng)構(gòu)建一個EAI平臺。 工作流系統(tǒng)能夠發(fā)揮很大價值的第二個使用方式是:協(xié)助涉及多人相關(guān)任務(wù)工作流軟件的開發(fā)。為了達到這個目的,大部分工作流系統(tǒng)都有一個方便的機制,來生成執(zhí)行任務(wù)的表單。對于專注于ISO 或者CMM認(rèn)證的組織,采用這種方式使用工作流系統(tǒng)能夠顯著提高生產(chǎn)率。 不用將過程用文字的形式寫在紙上,工作流系統(tǒng)使你通過流程定義建模實現(xiàn)過程的自動化(如使用基于Web的應(yīng)用)。 工作流系統(tǒng)的第三種使用方式是:將工作流引擎嵌入到其他應(yīng)用中。在前面我們談到,專門應(yīng)用將指定問題域相關(guān)的業(yè)務(wù)流程固化在軟件中。開發(fā)專門應(yīng)用的公司也可以將工作流引擎嵌入到他們的軟件中。在這里,工作流引擎只是作為一個軟件組件,對于應(yīng)用的最終用戶是不可見的。將工作流引擎嵌入到應(yīng)用中的主要原因是為了重用(不重復(fù)發(fā)明輪子)和應(yīng)用軟件的可維護性。 The case for workflow對于引入工作流的組織,能夠在軟件開發(fā)和業(yè)務(wù)兩個層次受益。 方便開發(fā)工作流管理系統(tǒng)能夠簡化企業(yè)級軟件開發(fā)甚至維護。
業(yè)務(wù)流程管理 (BPM)在自動化業(yè)務(wù)流程之前,分析并將它們規(guī)格化是一件艱苦但會有很好回報的工作。e-workflow.org對于分析流程能夠帶了的益處有不錯的闡述:
我認(rèn)為他們還遺漏了一個使用工作流系統(tǒng)最重要的因數(shù):提高對迭代開發(fā)的支持。如果軟件中業(yè)務(wù)流程部分不容易更改,組織就會花很大的精力在開發(fā)前的業(yè)務(wù)流程分析中,希望一次成功。但可悲的是,在任何軟件項目開發(fā)中,這都很少能實現(xiàn)。工作流系統(tǒng)使得新業(yè)務(wù)流程很容易部署,業(yè)務(wù)流程相關(guān)的軟件可以一種迭代的方式開發(fā),因此使用工作流系統(tǒng)使開發(fā)更有效、風(fēng)險更低。 缺失的一環(huán)(Missing link)我確實認(rèn)為工作流系統(tǒng)是企業(yè)應(yīng)用開發(fā)中缺失的一環(huán)。將企業(yè)業(yè)務(wù)流程邏輯在企業(yè)級軟件中實現(xiàn)的缺省方式是分散的。這意味著業(yè)務(wù)流程邏輯散布在各種系統(tǒng)中,如EJB、數(shù)據(jù)庫觸發(fā)器、消息代理等等。這樣得到的軟件難于維護,結(jié)果,企業(yè)只能將改變業(yè)務(wù)流程軟件作為最后的選擇。他們經(jīng)常能夠做的是,改變流程以適應(yīng)軟件。上述問題也適用于采用大型外部ERP軟件包的企業(yè)。進一步,假設(shè)我們認(rèn)識到這個問題,并打算將一個流程相關(guān)的代碼都集中起來。對于一個流程來說這很不錯,但當(dāng)你要實現(xiàn)多個流程時,你會看到管理狀態(tài)和流程變量的代碼被到處復(fù)制。最后,我們會整理這些代碼放到一個集中的庫中。好,...這就是一個工作流管理系統(tǒng)了,不用費心自己來實現(xiàn),你可以從本文后面的列表中選擇一個。A closer lookWFMS interfaces一個工作流管理系統(tǒng)以流程定義作為輸入。在這里,可以將流程定義看作UML活動圖、UML狀態(tài)圖或者有限狀態(tài)機。在提交一張費用單據(jù)、申請休假、要求一個報價、...之后,工作流系統(tǒng)負(fù)責(zé)維護這些流程定義的執(zhí)行狀態(tài)和上下文。為此,需要通知工作流系統(tǒng)狀態(tài)的變化。運行流程的狀態(tài)變化可以記錄下來,以備監(jiān)控管理。
![]() Figure 2: Interfaces of a WFMS
流程定義的四個層次在下面這部分,我嘗試回答這樣的問題“什么是流程定義包括的內(nèi)容?”。這是從各種規(guī)范和工具所使用模型的原則和概念中總結(jié)得來的,反映了大部分模型中通用的基本思想。流程定義的內(nèi)容可以分為四個不同的層次:狀態(tài)(state)、上下文(context)、程序邏輯(programming logic)和用戶界面(UI)。狀態(tài)層所有狀態(tài)和控制流的表述,都屬于業(yè)務(wù)流程的狀態(tài)層。標(biāo)準(zhǔn)編程語言中的控制流來源于Von Neuman體系。控制流定義了必須被執(zhí)行的指令的順序,控制流由我們書寫的命令、if語句、循環(huán)語句等確定。在業(yè)務(wù)流程中的控制流基本與此一致。但在業(yè)務(wù)流程中不是使用命令而是使用狀態(tài)作為基本元素。 在流程中,狀態(tài) (或者說等待狀態(tài))代表了一種對外部參與者(actor)的依賴。狀態(tài)的意思就像“現(xiàn)在X系統(tǒng)或某某人必須作某些事,在此等待直到參與者通知這些任務(wù)已完成”。狀態(tài)定義了一種對外部提供結(jié)果的依賴。狀態(tài)典型的例子是批準(zhǔn)步驟(step)。 流程定義中的狀態(tài)也指定了執(zhí)行依賴于哪個參與者。在活動圖中,泳道(swimlanes)的標(biāo)注代表這些參與者的名字。工作流系統(tǒng)使用這些信息構(gòu)建任務(wù)列表,這是一般工作流系統(tǒng)都有的功能。如前所述,參與者可以是人也可以是系統(tǒng)。對于需要人參與的狀態(tài),工作流系統(tǒng)必須在運行時計算出具體的個人。這樣的計算使工作流系統(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í)行路徑可以同時執(zhí)行,那些不可以。同步執(zhí)行路徑用分叉(forks)和聯(lián)合(joins)建模,異步執(zhí)行路徑用判斷(decisions)和合并( merges)建模。注意在大多數(shù)模型中,在每個狀態(tài)之前都有一個隱式合并。 UML活動圖經(jīng)常被用來做業(yè)務(wù)流程建模。作為一種直觀和通用的表達,活動圖在圖形表述上有一個主要問題,就是沒有區(qū)分狀態(tài)和動作,它們都用活動來表示。缺少這種區(qū)分(導(dǎo)致狀態(tài)概念的缺失)是學(xué)術(shù)派對UML活動圖的主要批評。UML活動圖的第二個問題是在UML2.0版中引入的。當(dāng)多個遷移(transitions)到達一個活動時,以前的版本規(guī)定這是一個缺省合并(merge),在2.0版中規(guī)定這是一個需要同步的缺省聯(lián)合(join)。在我看來,UML活動圖的圖形部分仍舊可以用來對業(yè)務(wù)流程狀態(tài)層次建模,只要使用時對兩條構(gòu)建語義作如下的變化:
在流程運行過程中,工作流系統(tǒng)用一個令牌(token)作為指針跟蹤流程的狀態(tài)。這相當(dāng)于Von Neuman體系中的程序計數(shù)器。當(dāng)令牌到達一個狀態(tài)時,它被分配給工作流系統(tǒng)等待的外部參與者。外部參與者可以是個人、組織或者計算機系統(tǒng)。我們定義流程運行的執(zhí)行人或系統(tǒng)為“參與者”(actor)。只有在工作流系統(tǒng)將令牌分配給一個參與者時,才需要訪問組織結(jié)構(gòu)信息。工作流系統(tǒng)通過分配令牌構(gòu)建任務(wù)列表。 上下文層流程上下文變量(process context variable) ,或簡稱變量,是與流程實例相關(guān)的變量。流程開發(fā)人員可以使用流程變量存儲跨越流程實例整個生命周期的數(shù)據(jù)。一些工作流管理系統(tǒng)有固定數(shù)目的數(shù)據(jù)類型,另一些你可以定義自己的數(shù)據(jù)類型。 注意變量也可以用來存放引用( references)。一個變量可以引用如數(shù)據(jù)庫中的記錄、網(wǎng)絡(luò)上的文件。什么時候使用引用,取決于使用引用數(shù)據(jù)的其他應(yīng)用。 和流程變量相關(guān)的另一個令人感興趣的方面是:工作流系統(tǒng)如何將數(shù)據(jù)轉(zhuǎn)化為信息。工作流是用于組織內(nèi)部跨越各種異構(gòu)系統(tǒng)實現(xiàn)任務(wù)和數(shù)據(jù)協(xié)同的。對于業(yè)務(wù)流程中人工執(zhí)行的任務(wù),工作流系統(tǒng)負(fù)責(zé)從其他相關(guān)系統(tǒng),如SAP、數(shù)據(jù)庫、CRM系統(tǒng)、文檔管理系統(tǒng)收集數(shù)據(jù)。在業(yè)務(wù)流程的每一個人工步驟,只有相關(guān)聯(lián)的數(shù)據(jù)項被從異構(gòu)系統(tǒng)中收集和計算。通過這種方式,從不同系統(tǒng)來的數(shù)據(jù)被轉(zhuǎn)換并展現(xiàn)為信息。 程序邏輯層如前所述,動作是在流程運行過程中,工作流系統(tǒng)響應(yīng)指定的事件(event)執(zhí)行的一段程序邏輯(programming logic)。程序邏輯可以是二進制或源代碼形式的、用任何語言或腳本編寫的軟件。程序邏輯層是所有這些軟件片斷和關(guān)于在什么事件發(fā)生時調(diào)用它們的信息的組合。程序邏輯的例子包括發(fā)Email、通過消息代理發(fā)消息、從ERP系統(tǒng)中拿數(shù)據(jù)和更新數(shù)據(jù)庫。 用戶界面層一個參與者通過向流程變量中填充數(shù)據(jù)的事件,來觸發(fā)結(jié)束一個狀態(tài)。比如,在請假的例子中,老板提供“同意”或“不同意”數(shù)據(jù)到流程中。某些工作流系統(tǒng)允許指定哪些數(shù)據(jù)可以填充到流程中,以及它們?nèi)绾卧诹鞒套兞恐写鎯ΑMㄟ^這些信息,可以生成從用戶收集信息的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)一集中的趨勢。 XLANG, WSFL 和BPML合并為基于交互(消息交換)的BPEL。BPEL在面向服務(wù)體系結(jié)構(gòu)(SOA)的大背景下定義。它的前提條件之一是涉及的服務(wù)必須用WSDL聲明。BPEL規(guī)定了一套XML語法,這套語法可以看作一種編程語言,用來描述包括對WSDL定義的服務(wù)調(diào)用的控制流。 在可執(zhí)行業(yè)務(wù)流程和基于狀態(tài)的工作流管理系統(tǒng)所使用的方法中,我注意到了三點主要的區(qū)別:
學(xué)術(shù)界學(xué)術(shù)界對工作流的研究可以回溯到上個世紀(jì)七十年代。在當(dāng)前,研究領(lǐng)域趨向于認(rèn)為petr 網(wǎng)是所有流程定義語言之母。關(guān)于petri網(wǎng)已有大量先進的分析技術(shù),去年在 2003 conference on Business Process Management上我有幸會晤了Petri教授。對于大部分人能夠訪問和理解的有關(guān)Petyri網(wǎng)最好的研究之一是工作流模式(workflow patterns)。工作流模式比較了大量的工作流管理系統(tǒng)并以petri網(wǎng)的術(shù)語表述了通用流程建模概念。開放源代碼項目最后我們看看真實世界中的工作流管理系統(tǒng)。選擇一個工作流管理系統(tǒng)是一件困難的事情,但有選擇總比沒有選擇好。:-) 本文闡述工作流基本概念的目的之一,就是使你能夠作更好的選擇。但我也意識到,對于現(xiàn)在的軟件架構(gòu)師來說,選擇工作流系統(tǒng)是一件最具挑戰(zhàn)性的工作。 下面的列表來源于三個地方:my previous article, the list of Carlos E Perez, 和 list by Topicus.
商業(yè)軟件提供商
工具目錄
規(guī)范Michael zur Muehlen作了一個所有工作流相關(guān)規(guī)范的介紹性的幻燈片,很不錯。 我同意John Pyke 和 Wil van der Aalst 的觀點:工作流標(biāo)準(zhǔn)還處于制定階段。現(xiàn)在存在大量相互叢疊的規(guī)范。 在我看來,導(dǎo)致規(guī)范如此之多而同時每個規(guī)范的應(yīng)用又很有限的原因是,在工作流最基礎(chǔ)概念上大家達成的共識很少。工作流是最容易讓你感到心煩的話題,因為工作流本身的概念會和其他相關(guān)概念和技術(shù)混淆在一起。可以舉一個具體的例子,比如說工作流完全是對Web Service的補充。你可以通過暴露接口以Web Service的方式訪問一個工作流管理系統(tǒng),但是不能假定總是必須通過Web Service接口訪問工作流系統(tǒng)接口。一些規(guī)范造成了這樣的假設(shè)。除了Web Service,其他容易混淆的概念和技術(shù)包括:Email、流程之間的通訊、Web應(yīng)用和組織結(jié)構(gòu)。 在工作流領(lǐng)域第一個致力于標(biāo)準(zhǔn)化工作的是Workflow Management Coalition (WfMC),開始于 1993。 WfMC發(fā)布的參考模型很不錯,它定義了工作流管理系統(tǒng)和其他相關(guān)部分之間的接口。WfMC的另一項成果是XPDL規(guī)范。 XPDL定義了描述工作流聲明部分(declarative part)的XML結(jié)構(gòu)。我個人認(rèn)為,參考模型和XPDL是目前最好的規(guī)范。
結(jié)論我在本文中指出工作流市場還屬于年輕而又混亂(young and wild)的階段,但已經(jīng)有可靠的工具存在了:
從以上所有這些中能得到的結(jié)論是:
我希望本文能夠激發(fā)你對工作流的興趣并且能夠為你進行有效的對比提供正確的背景知識。 Further reading
ThanksA special thanks for Gustavo Maciel Dias Vieira and Jef Vanbockryck for their valuable feedback on the draft versions of this article.
|