1、什么是WfMS
（1）定義
l 工作流系統(tǒng)是以規(guī)格化的流程描述作為輸入的軟件組件,它維護(hù)流程的運行狀態(tài),并在人和應(yīng)用之間分派活動
l 基本概念：
Ø 流程定義（process definition）：一個業(yè)務(wù)流程或過程的規(guī)格化描述
Ø 流程實例（process instance）：流程定義的一個運行實體
Ø 狀態(tài) (state，或者說等待狀態(tài))：代表一種對外部參與者的依賴；這意味著在流程運行時流程引擎必須等待，直到外部參與者通知工作流系統(tǒng)指定的狀態(tài)完成了
Ø 動作（action）：在流程運行過程中，工作流系統(tǒng)為響應(yīng)指定事件運行的一段程序邏輯；當(dāng)流程運行過程中指定的事件發(fā)生時，工作流系統(tǒng)啟動并執(zhí)行這些動作
Ø 流程上下文變量（process context variable）：保存每一個流程運行的上下文信息；通常在流程定義中聲明這些變量，然后在流程實例生成時被實例化
（2）目標(biāo)
l 作為企業(yè)應(yīng)用系統(tǒng)集成（EAI）的平臺：當(dāng)前大部分企業(yè)級IT架構(gòu)中包含各種專門應(yīng)用；這些專門應(yīng)用提供了一組固定的自動化業(yè)務(wù)流程；而工作流系統(tǒng)將業(yè)務(wù)流程描述作為輸入并管理流程實例的執(zhí)行，比專門應(yīng)用更靈活；因此，工作流系統(tǒng)和專門系統(tǒng)是相互補(bǔ)充的，使用工作流系統(tǒng)管理全局的業(yè)務(wù)流程，結(jié)合所有的專門應(yīng)用，來構(gòu)建一個EAI平臺
l 協(xié)助涉及多人相關(guān)任務(wù)的工作流軟件的開發(fā)
l 將工作流引擎嵌入到其他應(yīng)用中：開發(fā)專門應(yīng)用的公司可以將工作流引擎嵌入到他們的軟件中；在這里，工作流引擎只是作為一個軟件組件，主要是為了重用和應(yīng)用軟件的可維護(hù)性
2、工作流案例
引入工作流能夠在軟件開發(fā)級和業(yè)務(wù)級受益。
（1）簡化開發(fā)
l 降低開發(fā)風(fēng)險 ：業(yè)務(wù)分析師和開發(fā)人員使用相同語言交談（如狀態(tài)和動作術(shù)語），這意味著開發(fā)人員沒有必要將用戶需求轉(zhuǎn)化成軟件設(shè)計
l 集中實現(xiàn)：業(yè)務(wù)流程經(jīng)常變化，使用工作流系統(tǒng)的最大好處是：實現(xiàn)不再是散落在各種系統(tǒng)中模糊整合的軟件片斷
l 加快應(yīng)用開發(fā) - 你的軟件不再有在流程終保持與參與者聯(lián)系的任務(wù)，開發(fā)更快，代碼更容易維護(hù)
（2）業(yè)務(wù)流程管理（BPM）
在你能夠自動化業(yè)務(wù)流程之前，分析它們并創(chuàng)建規(guī)范化描述是一件艱苦但會有很好回報的工作：
l 提高效率：許多業(yè)務(wù)流程自動化的結(jié)果是去除許多不必要的步驟
l 更好的流程控制：通過標(biāo)準(zhǔn)的工作方法和跟蹤審計，提高了業(yè)務(wù)流程的管理
l 改進(jìn)客戶服務(wù) - 流程的一致性，提高了各層次對客戶響應(yīng)的可預(yù)見性
l 靈活性：基于流程的軟件控制，使得可以重新設(shè)計以符合業(yè)務(wù)需要的變化
l 業(yè)務(wù)流程改進(jìn)：聚焦業(yè)務(wù)流程，導(dǎo)致它們的流線性和簡化性
l 改進(jìn)的迭代開發(fā)支持：工作流系統(tǒng)使得新業(yè)務(wù)流程很容易部署，業(yè)務(wù)流程軟件可以使用迭代方式開發(fā)，因此使用工作流系統(tǒng)使開發(fā)更有效、風(fēng)險更低
（3）缺失的環(huán)節(jié)
l 工作流系統(tǒng)是企業(yè)應(yīng)用開發(fā)中缺失的環(huán)節(jié)
l 在企業(yè)級軟件中并入業(yè)務(wù)流程邏輯的缺省方式是分散的，這意味著業(yè)務(wù)流程邏輯散布在各種系統(tǒng)中，如EJB容器、數(shù)據(jù)庫觸發(fā)器、消息代理等等
l 這導(dǎo)致軟件難于維護(hù)，結(jié)果使得改變業(yè)務(wù)流程軟件作為最后的選擇；他們經(jīng)常寧愿改變流程而不是軟件
l 假設(shè)我們認(rèn)識到這個問題，并打算集中一個流程相關(guān)的代碼；這對于一個流程可以很好的工作，但要實現(xiàn)多個流程時，管理狀態(tài)和流程變量的代碼被到處復(fù)制
l 第三種方法是提取出復(fù)制的代碼，放到一個集中的庫中；這就是一個工作流管理系統(tǒng)
l WfMS以流程定義為輸入
l 可以將流程定義看作UML活動圖、UML狀態(tài)圖或者有限狀態(tài)機(jī)
l 工作流系統(tǒng)負(fù)責(zé)維護(hù)這些流程定義的執(zhí)行狀態(tài)和上下文
l 為此，需要通知狀態(tài)的變化；運行流程的狀態(tài)變化可以記錄下來，以備監(jiān)控管理
l 下面是WfMS的接口：
Ø 定義接口：允許流程開發(fā)人員部署流程定義；這里的“流程開發(fā)人員”是業(yè)務(wù)分析師和軟件開發(fā)人員的組合
Ø 執(zhí)行接口：使用戶和系統(tǒng)可以操作流程實例；流程實例是流程定義的執(zhí)行；流程定義的控制流通過狀態(tài)機(jī)描述；執(zhí)行接口的兩個主要方法是啟動一個流程實例和通知工作流系統(tǒng)一個狀態(tài)的結(jié)束
Ø 應(yīng)用程序接口：表示由工作流系統(tǒng)發(fā)起的工作流系統(tǒng)和外部系統(tǒng)之間的交互。當(dāng)用戶或系統(tǒng)管理一個流程實例的運行時，會產(chǎn)生事件；流程定義中可以指定一段響應(yīng)事件的可執(zhí)行代碼邏輯，程序代碼能夠和組織內(nèi)外部的其他系統(tǒng)通信
Ø 監(jiān)控接口：管理人員通過監(jiān)控接口獲得流程運行記錄的統(tǒng)計數(shù)據(jù)；有時，運行記錄也可用于跟蹤審計
流程定義的內(nèi)容可以分為四個不同的層次：狀態(tài)（state）、上下文（context）、程序邏輯（programming logic）和用戶界面（UI）
l 狀態(tài)層
Ø 所有的狀態(tài)表述和控制流屬于業(yè)務(wù)流程的狀態(tài)層；
Ø 標(biāo)準(zhǔn)程序語言的控制流定義了必須被執(zhí)行的指令的順序，由我們書寫的命令、if語句、循環(huán)語句等確定；業(yè)務(wù)流程中的控制流基本相同，但使用基本元素替代指令；業(yè)務(wù)流程中的基本元素是狀態(tài)；
Ø 在流程中，狀態(tài)(或等待狀態(tài))指定一種對外部參與者的依賴；狀態(tài)的意思就像“現(xiàn)在X系統(tǒng)或Y人必須做某些事，在此等待直到參與者通知任務(wù)已完成的外部觸發(fā)”；
Ø 流程定義中的狀態(tài)也指定了執(zhí)行依賴于哪個參與者；WfMS使用代表參與者的名字的信息構(gòu)建任務(wù)列表，這是WfMS的通用特性；對于需要人參與的狀態(tài)，WfMS必須在運行時計算出具體人，這樣的計算使WfMS必須依賴于組織結(jié)構(gòu)信息；
Ø 流程定義的控制流是一組和結(jié)合狀態(tài)之間關(guān)系的狀態(tài)；
Ø 狀態(tài)之間的邏輯指定哪些執(zhí)行路徑可以并發(fā)執(zhí)行，那些是排它的；并發(fā)執(zhí)行路徑用交叉和聯(lián)合來建模，而排它執(zhí)行路徑用判斷和合入來建模；
Ø UML活動圖經(jīng)常被用來做業(yè)務(wù)流程建模；
Ø 雖然活動圖是一種直觀和通用的表達(dá)，但在圖形表述上有一個主要問題，就是沒有區(qū)分狀態(tài)和動作，都用活動來建模；
Ø UML活動圖的第二個問題是在UML2.0版本中引入的，當(dāng)多個遷移到達(dá)一個活動（只讀狀態(tài)）時，以前的版本指定為一個缺省合并，而在2.0版中指定為需要同步的缺省聯(lián)合；
Ø 只要對兩條構(gòu)建語義作如下的變化，UML活動圖仍舊可以用來對業(yè)務(wù)流程狀態(tài)層建模：
Ø 在用圖形表述業(yè)務(wù)流程時，只建模狀態(tài)層（狀態(tài)和控制流），不包括動作。這意味著圖形中的矩形都是狀態(tài)而不是活動；
Ø 如果多個遷移到達(dá)一個狀態(tài)，缺省定義為不需要同步的合并；
Ø 在流程執(zhí)行過程中，WfMS使用令牌（token）作為跟蹤流程狀態(tài)的指示器；當(dāng)令牌到達(dá)一個狀態(tài)時，被分配給WfMS等待的外部參與者；
Ø 外部參與者可以是個人、組織或者計算機(jī)系統(tǒng)，我們定義流程運行的執(zhí)行人或系統(tǒng)為參與者（actor）；
Ø 只有在WfMS需要訪問組織結(jié)構(gòu)信息時，才將令牌分配給一個參與者
Ø 工作流系統(tǒng)通過分配令牌構(gòu)建任務(wù)列表
l 上下文層
Ø 流程上下文變量或簡稱變量，是與流程實例相關(guān)的變量；
Ø 流程變量允許流程開發(fā)人員在流程實例的生命周期中存儲數(shù)據(jù)；
Ø WfMS具有固定的一組數(shù)據(jù)類型，也可以定義自己的數(shù)據(jù)類型；
Ø 注意變量也可以保存引用，例如可以引用數(shù)據(jù)庫中的記錄、網(wǎng)絡(luò)上的文件；
Ø 和流程變量相關(guān)的另一個有趣的方面是：WfMS如何將數(shù)據(jù)轉(zhuǎn)化為信息；
Ø 工作流用于在組織內(nèi)部的各種異構(gòu)系統(tǒng)之間實現(xiàn)任務(wù)和數(shù)據(jù)進(jìn)行協(xié)同；
Ø 對于業(yè)務(wù)流程中人工執(zhí)行的任務(wù)，WfMS負(fù)責(zé)從其他相關(guān)系統(tǒng)，如SAP、數(shù)據(jù)庫、CRM系統(tǒng)、文檔管理系統(tǒng)收集相關(guān)數(shù)據(jù)。在業(yè)務(wù)流程的每一個人工步驟，只有相關(guān)的數(shù)據(jù)項從異構(gòu)系統(tǒng)中收集和計算；
Ø 通過這種方式，從不同系統(tǒng)來的數(shù)據(jù)被轉(zhuǎn)換并呈現(xiàn)為信息
l 程序邏輯層
Ø 動作是在流程運行過程中WfMS為響應(yīng)指定事件而執(zhí)行的一段程序邏輯
Ø 程序邏輯可以是二進(jìn)制或源代碼形式的、用任何語言或腳本編寫的軟件片斷
Ø 程序邏輯層根據(jù)指定事件的信息將需要執(zhí)行的所有軟件片斷組合
l 用戶界面層
Ø 參與者通過向流程變量填充數(shù)據(jù)的事件，來觸發(fā)結(jié)束一個狀態(tài)
Ø 某些WfMS允許指定哪些數(shù)據(jù)可以填充到流程中，以及如何存儲到流程變量中
Ø 可以生成UI表單從用戶收集這些信息
l 當(dāng)前BPM領(lǐng)域的新趨勢是可執(zhí)行業(yè)務(wù)流程的集中規(guī)范
l XLANG、WSFL 和BPML合并為基于交互（消息交換）的BPEL
l BPEL在面向服務(wù)體系結(jié)構(gòu)(SOA)環(huán)境下定義，其前提條件之一是服務(wù)必須用WSDL聲明
l BPEL規(guī)定了一套看作一種編程語言的XML語法，通過掉用WSDL中定義的服務(wù)整合控制流
l 可執(zhí)行業(yè)務(wù)流程和基于狀態(tài)的WfMS所使用的方法中，有三點主要的區(qū)別：
Ø 基于狀態(tài)VS面向消息：基于狀態(tài)的WfMS以狀態(tài)（或者活動）概念為中心，工作流引擎維護(hù)狀態(tài)并計算從一個狀態(tài)到另一個狀態(tài)的遷移；另一方面，像BPEL這樣的可執(zhí)行流程以響應(yīng)輸入消息的定義為中心，可以將一組這樣的響應(yīng)以及其他信息看作一個業(yè)務(wù)流程，這解釋了為什么BPEL是基于狀態(tài)的WfMS的一些補(bǔ)充；例如，BPEL響應(yīng)輸入消息的onMessage事件處理器，可以在狀態(tài)之間遷移時執(zhí)行
Ø 流程實例ID VS消息關(guān)系：可執(zhí)行業(yè)務(wù)流程的復(fù)雜性之一是消息關(guān)系；流程描述的一部分必須說明BPEL引擎如何從輸入消息中確定流程實例的標(biāo)識，這必須基于輸入消息的一個數(shù)據(jù)項；而基于狀態(tài)的WfMS為每個創(chuàng)建的流程實例生成ID，客戶端可以在后面調(diào)用引擎API時使用這個ID
Ø 核心工作流引擎API VS抽象服務(wù)端點（endpoint）：基于狀態(tài)的WfMS提供一組核心API，這意味著客戶端通過調(diào)用核心API管理所有流程實例的執(zhí)行；在可執(zhí)行業(yè)務(wù)流程中，每個流程表現(xiàn)為一個服務(wù)，這意味著每個流程定義都有一個不同的訪問點
