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