定義：工作流系統(tǒng)的定義接口使流程開發(fā)人員能夠部署流程定義。注意，這里的"流程開發(fā)人員"可以是業(yè)務分析師和軟件開發(fā)人員的組合。 圈套（Pitfall）許多工作流管理系統(tǒng)的開發(fā)商想使你相信，通過使用他 們的圖形化流程開發(fā)工具，只要業(yè)務分析師就可以生成流程定義。

這種幻想源于"編程很難"這樣的事實。開發(fā)商的銷售人員喜歡說"看，你不用寫一行代碼"。不用寫代碼是好事，可大部分開發(fā)商在這點上走的太遠，忽略了在某些場合提供一種將代碼集成到流程定義中的機制是很適合的。在將工作流系統(tǒng)作為EAI平臺時，必須在流程中集成代碼。開發(fā)流程定義需要業(yè)務分析師和軟件開發(fā)人員的合作。一個好的圖形流程設計工具應該能夠支持這種合作。

執(zhí)行：執(zhí)行接口使用戶和系統(tǒng)可以操作流程實例。流程實例是流程定義的執(zhí)行。流程定義的控制流通過狀態(tài)機描述。執(zhí)行接口的兩個主要方法是啟動一個流程實例和通知工作流系統(tǒng)一個狀態(tài)結束了。

應用：應用接口代表了由工作流系統(tǒng)發(fā)起的工作流系統(tǒng)和外部系統(tǒng)之間的交互。當一個用戶或系統(tǒng)操作一個流程實例的運行時，會生成一些事件（如一個遷移的執(zhí)行）。流程定義中可以指定一段響應一個事件的可執(zhí)行代碼邏輯，這段代碼和組織內外部的其他系統(tǒng)打交道。
監(jiān)控   管理人員通過監(jiān)控接口獲得流程運行的確切數(shù)據(jù)。有時，運行日志也可用于審計。
這些是WfMC參考模型（reference model of the WfMC）中定義的五個接口中的四個。

流程定義的四個層次

在下面這部分，我嘗試回答這樣的問題"什么是流程定義包括的內容？"。這是從各種規(guī)范和工具所使用模型的原則和概念中總結得來的，反映了大部分模型中通用的基本思想。流程定義的內容可以分為四個不同的層次：狀態(tài)（state）、上下文（context）、程序邏輯（programming logic）和用戶界面（UI）。
狀態(tài)層
所有狀態(tài)和控制流的表述，都屬于業(yè)務流程的狀態(tài)層。標準編程語言中的控制流來源于Von Neuman體系。控制流定義了必須被執(zhí)行的指令的順序，控制流由我們書寫的命令、if語句、循環(huán)語句等確定。在業(yè)務流程中的控制流基本與此一致。但在業(yè)務流程中不是使用命令而是使用狀態(tài)作為基本元素。

在流程中，狀態(tài) (或者說等待狀態(tài))代表了一種對外部參與者（actor）的依賴。狀態(tài)的意思就像"現(xiàn)在X系統(tǒng)或某某人必須作某些事，在此等待直到參與者通知這些任務已完成"。狀態(tài)定義了一種對外部提供結果的依賴。狀態(tài)典型的例子是批準步驟（step）。

流程定義中的狀態(tài)也指定了執(zhí)行依賴于哪個參與者。在活動圖中，泳道（swimlanes）的標注代表這些參與者的名字。工作流系統(tǒng)使用這些信息構建任務列表，這是一般工作流系統(tǒng)都有的功能。如前所述，參與者可以是人也可以是系統(tǒng)。對于需要人參與的狀態(tài)，工作流系統(tǒng)必須在運行時計算出具體的個人。這樣的計算使工作流系統(tǒng)必須依賴于組織結構信息。關于這方面的一篇非常有趣的文章是在further reading section提到的"工作流應用中的組織管理"（ ‘Organizational Management in Workflow Applications‘）。

流程定義的控制流包含一組狀態(tài)和它們之間的關系。狀態(tài)之間的邏輯關系描述了哪些執(zhí)行路徑可以同時執(zhí)行，那些不可以。同步執(zhí)行路徑用分叉（forks）和聯(lián)合（joins）建模，異步執(zhí)行路徑用判斷（decisions）和合并（ merges）建模。注意在大多數(shù)模型中，在每個狀態(tài)之前都有一個隱式合并。

UML活動圖經(jīng)常被用來做業(yè)務流程建模。作為一種直觀和通用的表達，活動圖在圖形表述上有一個主要問題，就是沒有區(qū)分狀態(tài)和動作，它們都用活動來表示。缺少這種區(qū)分（導致狀態(tài)概念的缺失）是學術派對UML活動圖的主要批評。UML活動圖的第二個問題是在UML2.0版中引入的。當多個遷移（transitions）到達一個活動時，以前的版本規(guī)定這是一個缺省合并（merge），在2.0版中規(guī)定這是一個需要同步的缺省聯(lián)合（join）。在我看來，UML活動圖的圖形部分仍舊可以用來對業(yè)務流程狀態(tài)層次建模，只要使用時對兩條構建語義作如下的變化：

在用圖形表述業(yè)務流程時，只建模狀態(tài)層（狀態(tài)和控制流），不要包括動作。這意味著圖形中的矩形都是狀態(tài)而不是活動

如果多個遷移到達一個狀態(tài)，缺省定義為不需要同步的合并（merges）

在流程運行過程中，工作流系統(tǒng)用一個令牌（token）作為指針跟蹤流程的狀態(tài)。這相當于Von Neuman體系中的程序計數(shù)器。當令牌到達一個狀態(tài)時，它被分配給工作流系統(tǒng)等待的外部參與者。外部參與者可以是個人、組織或者計算機系統(tǒng)。我們定義流程運行的執(zhí)行人或系統(tǒng)為"參與者"（actor）。只有在工作流系統(tǒng)將令牌分配給一個參與者時，才需要訪問組織結構信息。工作流系統(tǒng)通過分配令牌構建任務列表。

上下文層

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

注意變量也可以用來存放引用（ references）。一個變量可以引用如數(shù)據(jù)庫中的記錄、網(wǎng)絡上的文件。什么時候使用引用，取決于使用引用數(shù)據(jù)的其他應用。

和流程變量相關的另一個令人感興趣的方面是：工作流系統(tǒng)如何將數(shù)據(jù)轉化為信息。工作流是用于組織內部跨越各種異構系統(tǒng)實現(xiàn)任務和數(shù)據(jù)協(xié)同的。對于業(yè)務流程中人工執(zhí)行的任務，工作流系統(tǒng)負責從其他相關系統(tǒng)，如SAP、數(shù)據(jù)庫、CRM系統(tǒng)、文檔管理系統(tǒng)收集數(shù)據(jù)。在業(yè)務流程的每一個人工步驟，只有相關聯(lián)的數(shù)據(jù)項被從異構系統(tǒng)中收集和計算。通過這種方式，從不同系統(tǒng)來的數(shù)據(jù)被轉換并展現(xiàn)為信息。

程序邏輯層

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

用戶界面層

一個參與者通過向流程變量中填充數(shù)據(jù)的事件，來觸發(fā)結束一個狀態(tài)。比如，在請假的例子中，老板提供"同意"或"不同意"數(shù)據(jù)到流程中。某些工作流系統(tǒng)允許指定哪些數(shù)據(jù)可以填充到流程中，以及它們如何在流程變量中存儲。通過這些信息，可以生成從用戶收集信息的UI表單?；诹鞒潭x生成用戶提交表單的Web應用例子，可以訪問the jBpm online demo。

工作流全景

可執(zhí)行流程與工作流管理系統(tǒng)的比較（Executional processes versus a WFMS）
當前在BPM領域中，關于可執(zhí)行業(yè)務流程的規(guī)范有趨向于統(tǒng)一集中的趨勢。 XLANG, WSFL 和BPML合并為基于交互（消息交換）的BPEL。BPEL在面向服務體系結構(SOA)的大背景下定義。它的前提條件之一是涉及的服務必須用WSDL聲明。BPEL規(guī)定了一套XML語法，這套語法可以看作一種編程語言，用來描述包括對WSDL定義的服務調用的控制流。
在可執(zhí)行業(yè)務流程和基于狀態(tài)的工作流管理系統(tǒng)所使用的方法中，我注意到了三點主要的區(qū)別：

基于狀態(tài)與面向消息：基于狀態(tài)的工作流系統(tǒng)以狀態(tài)（或者活動）概念為中心。工作流引擎維護狀態(tài)并計算從一個狀態(tài)到另一個狀態(tài)的遷移。另一方面，像BPEL這樣的可執(zhí)行流程以對輸入消息響應的定義為中心。一組這些響應外加其他信息（other bells and whistles）可以看作一個業(yè)務流程。這也解釋了為什么BPEL可以看作是對基于狀態(tài)的工作流系統(tǒng)的某些方面的補充。一個響應輸入消息的BPEL onMessage事件處理器，可以在工作流狀態(tài)之間的遷移中執(zhí)行。

流程實例ID與消息相關處理：可執(zhí)行業(yè)務流程的復雜性之一來自消息相關性的處理。流程描述的一部分必須說明BPEL引擎如何從輸入消息中確定具體流程的標識。這必須基于輸入消息的一個數(shù)據(jù)項。而工作流系統(tǒng)在每個流程實例生成同時生成了實例ID，客戶端在后續(xù)調用引擎API時使用這個ID。

工作流引擎API與抽象服務端點（endpoint）：工作流系統(tǒng)提供一組集中的API，客戶端通過調用API完成與所有流程實例的交互。在可執(zhí)行業(yè)務流程中，每個流程表現(xiàn)為一個服務。這意味著對于每個流程定義都有一個不同的訪問點。

學術界

學術界對工作流的研究可以回溯到上個世紀七十年代。在當前，研究領域趨向于認為petr 網(wǎng)是所有流程定義語言之母。關于petri網(wǎng)已有大量先進的分析技術，去年在 2003 conference on Business Process Management上我有幸會晤了Petri教授。對于大部分人能夠訪問和理解的有關Petyri網(wǎng)最好的研究之一是工作流模式(workflow patterns)。工作流模式比較了大量的工作流管理系統(tǒng)并以petri網(wǎng)的術語表述了通用流程建模概念。

開放源代碼項目

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

下面的列表來源于三個地方：my previous article, the list of Carlos E Perez, 和 list by Topicus.
jBpm - jBpm是本文作者編寫的一個靈活可擴展的工作流管理系統(tǒng)。作為jBpm運行時server輸入的業(yè)務流程使用簡單強大的語言表達并打包在流程檔案中。jBmp將工作流應用開發(fā)的便利性和杰出的企業(yè)應用集成（EAI）能力結合了起來。jBmp包括一個Web應用程序和一個日程安排程序。jBmp是一組J2SE組件，可以作為J2EE應用集群部署。

OpenEbXML - OpenebXML項目致力于提供一個ebXML框架，主要支持不久將由 UN/CEFACT和OASIS發(fā)布的ebXML規(guī)范2.0版。

Werkflow - Werkflow是一個靈活可擴展的基于流程和狀態(tài)的工作流引擎。它的目標是滿足可以想象的所有工作流程，從企業(yè)級的業(yè)務流程到小范圍的用戶交互流程。通過使用可插拔和分層結構，可以方便地容納各種工作流語義。

OSWorkflow - OSWorkflow最獨到之處是絕對的靈活。 wfmOpen - WfMOpen是WfMC和OMG中所謂工作流設施（workflow facility） (工作流引擎)的J2EE實現(xiàn)。工作流通過擴展的XPDL描述。 OFBiz - OFBiz工作流引擎基于WfMC和OMG的規(guī)范，使用XPDL作為流程定義語言。 ObjectWeb Bonita - Bonita是一個符合WfMC規(guī)范、靈活的協(xié)同工作流系統(tǒng)。 對于各種動作如流程概念建模、定義、實例化、流程控制和用戶交互等提供了全面的集成圖形工具。 100% 基于瀏覽器、使用SOAP和XML數(shù)據(jù)綁定技術的Web Services封裝了已有的工作流業(yè)務方法并將它們以基于J2EE的Web Service形式發(fā)布?；诨顒宇A測模型的第三代工作流引擎。

Bigbross Bossa -速度非?？?、輕量級的引擎，使用富有表達能力的Petri網(wǎng)定義工作流，不要求關系數(shù)據(jù)庫，使用簡單，能和Java應用集成。事實上，它是按嵌入式設計的。
XFlow - XFlow運行于EJB和servlet容器中。 Taverna - Taverna項目的目標是提供一種語言和軟件工具，方便在eScience中使用工作流和分布計算技術。 Enhydra Shark - Shark完全基于WfMC和OMG標準，使用 XPDL作為工作流定義語言。流程和活動的存儲使用Enhydra DODS。 PowerFolder - PowerFolder包括開發(fā)人員使用的studio，管理環(huán)境和一個運行時引擎。
Breeze - Breeze一個輕量級、跨平臺、基于組件的工作流引擎原型。 Open Business Engine - Open Business Engine是一個開放源碼的Java工作流引擎，支持WfMC規(guī)范，包括接口1（XPDL）、接口2/3（WAPI）和接口5。OBE為活動的運行提供了一個可控的集中環(huán)境。OBE主要基于J2EE實現(xiàn)。

OpenWFE - OpenWFE是一個開放源碼的Java工作流引擎。 它包括可升級的三個組件：引擎、工作列表和Web界面。它的流程定義語言雖然使用XML格式，其靈感來源于 Scheme，一種Lisp方言。 Freefluo - Freefluo是一個使用Web Service的工作流協(xié)同工具，可以處理WSDL的Web Service調用。支持兩種XML格式的工作流語言：IBM的WSFL和XScufl。Freefluo非常靈活，它的核心是不與任何工作流語言或執(zhí)行架構關聯(lián)的可重用協(xié)同框架。 Freefluo包括可執(zhí)行使用WSFL一個子集描述的工作流的運行庫。

ZBuilder - ZBuilder3是第二代工作流開發(fā)管理系統(tǒng)，也是一個開放源碼產(chǎn)品。它為不同的工作流引擎和工作流定義了一組標準的JMX管理接口。

Twister - Twister的目標是提供新一代、易集成、應用Java領域中最新成果、面向B2B的工作流解決方案。流程引擎基于BPEL業(yè)務流程規(guī)范和Web Service標準。 Con:cern - con:cern工作流引擎基于擴展的案例（case）處理方法，流程由一組具有前后條件的活動組成。

商業(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作了一個所有工作流相關規(guī)范的介紹性的幻燈片，很不錯。
我同意John Pyke 和 Wil van der Aalst 的觀點：工作流標準還處于制定階段?，F(xiàn)在存在大量相互叢疊的規(guī)范。

在我看來，導致規(guī)范如此之多而同時每個規(guī)范的應用又很有限的原因是，在工作流最基礎概念上大家達成的共識很少。工作流是最容易讓你感到心煩的話題，因為工作流本身的概念會和其他相關概念和技術混淆在一起?？梢耘e一個具體的例子，比如說工作流完全是對Web Service的補充。你可以通過暴露接口以Web Service的方式訪問一個工作流管理系統(tǒng)，但是不能假定總是必須通過Web Service接口訪問工作流系統(tǒng)接口。一些規(guī)范造成了這樣的假設。除了Web Service，其他容易混淆的概念和技術包括：Email、流程之間的通訊、Web應用和組織結構。

在工作流領域第一個致力于標準化工作的是Workflow Management Coalition (WfMC)，開始于 1993。 WfMC發(fā)布的參考模型很不錯，它定義了工作流管理系統(tǒng)和其他相關部分之間的接口。WfMC的另一項成果是XPDL規(guī)范。 XPDL定義了描述工作流聲明部分（declarative part）的XML結構。我個人認為，參考模型和XPDL是目前最好的規(guī)范。

JSR 207: Java的流程定義 -是由Java Community Process (JCP) 發(fā)起，如何在J2EE應用服務器中實現(xiàn)業(yè)務流程自動化的標準。其基本模型是定義一個特殊類型的ejb session bean，作為一個業(yè)務流程的接口。JSR207標準化一組XML元標記（meta tags）作為JSR175元數(shù)據(jù)的一部分。JSR207 將session bean和元數(shù)據(jù)作為ejb容器的輸入，然后生成綁定方法的代碼，這些方法在元數(shù)據(jù)中描述。此規(guī)范還處于初級階段，沒有發(fā)布任何內容。專家小組成立于 March 2003.

WfMC‘s XPDL - WfMC是由約300家成員參加的組織，基于參考模型定義了一系列的標準。參考模型用用例（use case）的形式描述了工作流系統(tǒng)和其他相關部分之間的關系。XPDL是WfMC制定的描述業(yè)務流程控制流（control flow ）的XML格式規(guī)范。

ebXML‘s BPSS - ebXML是協(xié)同流程的相關標準集，主要關注不同公司流程之間的通訊?？梢钥醋鱁DI的繼承者。 ebXML是由OASIS和UN/CEFACT聯(lián)合發(fā)起。 BPSS 是ebXML的規(guī)范，其中的概念和本文闡述的很接近。

BPMI‘s BPML & WSCI - (Intalio, Sun, SAP, ...)BPMI 也定義了一個規(guī)范 (BPMN) ，描述如何將"可執(zhí)行"業(yè)務流程可視化的表現(xiàn)。

BPEL - (Microsoft, BEA, IBM, SAP & Siebel) BPEL由一系列基于消息交換的規(guī)范（ XLANG, WSFL, BPML）產(chǎn)生。還有一個將此規(guī)范引入到Java的提案: BPELJ。 此規(guī)范描述如何處理輸入的消息，而不是對流程狀態(tài)進行建模。就像本文提到的，它不是一個關于業(yè)務流程規(guī)格化定義的規(guī)范。簡單的說，可以將它看作XML形式的編程語言，提供將WSDL-Services組合成控制流的能力。顧名思義，此規(guī)范重點在（也不只限于）Web Service。 OMG‘s Workflow management facility - 基于WfMC規(guī)范，定義如何向CORBA轉換。

UML - UML定義了建模和設計軟件系統(tǒng)的9類圖。每類圖包括可視化的表示和語義。其中活動圖的目的就是要可視化的表現(xiàn)業(yè)務流程。 注意到在一個流程定義包含四個層次的內容，我想指出的是：一個流程定義包含的內容遠遠多于它的可視化部分。UML只涉及了可視化部分。

RosettaNet - RosettaNet主要定義了一組 Partner Interface Processes (PIP). 一個 PIP 描述了一個有兩個交易參與者、包括消息格式的流程。 UBL - The Universal Business Language (UBL)定義了用于不同組織間通訊的XML文檔標準庫。可以看作是對ebXML的補充，因為ebXML只定義了建立組織間流程的基礎。此規(guī)范的競爭對手是 RosettaNet標準中的一個子集。