工作流技術發端於 1970 年代中期辦公自動化領域的研究工作，但工作流思想的出現還應該更早， 1968 年 Fritz Nordsieck 就已經清楚地表達了利用信息技術實現工作流程自動化的想法。 1970 年代與工作流有關的研究工作包括：賓夕法尼亞大學沃頓學院的 Michael D. Zisman 開發的原型系統 SCOOP ，施樂帕洛阿爾託研究中心的 Clarence A. Ellis 和 Gary J. Nutt 等人開發的 OfficeTalk 系列試驗系統，還有 Anatol Holt 和 Paul Cashman 開發的 ARPANET 上的“監控軟件故障報告”程序。 SCOOP, Officetalk 和 Anatol Holt 開發的系統都採用 Petri 網的某種變體進行流程建模。其中 SCOOP 和 Officetalk 系統，不但標誌着工作流技術的開始，而且也是最早的辦公自動化系統。
1970 年代人們對工作流技術充滿着強烈樂觀情緒，研究者普遍相信新技術可以帶來辦公效率的巨大改善，然而這種期望最終還是落空了。人們觀察到這樣一種現象，一個成功的組織往往會在適當的時候創造性的打破標準的辦公流程；而工作流技術的引入使得人們只能死板的遵守固定的流程，最終導致辦公效率低和人們對技術的反感。 1970 年代工作流技術失敗的技術原因則包括：在辦公室使用個人計算機尚未被社會接受，網絡技術還不普遍，開發者還不瞭解羣件技術的需求與缺陷。
含有工作流特徵的商用系統的開發始於 1983 年至 1985 年間，早期的商用系統主要來自於圖像處理領域和電子郵件領域。圖像處理許多時候需要流轉和跟蹤圖像，工作流恰好迎合這種需求；增強的電子郵件系統也採用了工作流的思想，把原來點對點的郵件流轉改進爲依照某種流程來流轉。在這些早期的工作流系統中只有少數獲得了成功。
進入 1990 年代以後，相關的技術條件逐漸成熟，工作流系統的開發與研究進入了一個新的熱潮。據調查，截至 1995 年共有 200 多種軟件聲稱支持工作流管理或者擁有工作流特徵。工作流技術被應用於電訊業、軟件工程、製造業、金融業、銀行業、科學試驗、衛生保健領域、航運業和辦公自動化領域。
2.1 工作流概念
工作流是針對工作中具有固定程序的常規活動而提出的一個概念。通過將工作活動分解成定義良好的任務、角色、規則和過程來進行執行和監控，達到提高生產組織水平和工作效率的目的。工作流技術爲企業更好地實現經營目標提供了先進的手段。工作流管理系統（ workflow management systems , WFMS ）是以規格化的流程描述作爲輸入的軟件組件，它維護流程的運行狀態，並在人和應用之間分派活動。在此，我們先定義一些基本的術語：流程定義（ process definition ）和流程實例（ process instance ）。一個流程定義是一個業務流程或過程的規格化描述。一個流程實例是流程定義的一個運行實體。工作流管理系統還處於技術發展曲線上的初級階段。目前，工作流中使用了過多的概念。在這個領域中的大量規範和工具沒有一個是相似的，他們之間主要的分歧在於如何闡述流程中的步驟。
在介紹工作流時有一個話題必須包括，那就是工作流和業務流程管理（ BPM ）的關係。術語 “ 工作流 ” 通常描述人與計算機系統的一系列相關交互。在開發人員中，工作流經常被提及。有時，工作流的意思是指一些不同的 UI 界面。業務流程管理的範圍比較廣，相比之下工作流多半侷限於技術領域。業務流程管理還從管理人員的角度涉及了非技術問題，比如分析、組織的效率。
2.2 工作流管理系統概念
工作流管理系統是以規格化的流程描述作爲輸入的軟件組件，它維護流程的運行狀態，並在人和應用之間分派活動，推進工作流實例的執行，並監控工作流的運行狀態。
工作流管理系統可以描述不同覆蓋範圍和不同時間跨度的經營過程，根據經營過程以及組成活動的複雜程度，工作流管理系統可以採取多種實施方式，在不同實施方式中，所應用的信息技術、通信技術和支撐系統結構會有很大的差別，工作流管理系統的實際運行環境也可以在一個工作組內部，也可以在全企業所有業務部門。
工作流管理系統在實際系統中的應用一般分爲三個階段：即模型建立階段、模型實例化階段和模型執行階段。在模型建立階段，通過利用工作流建模工具，完成企業經營過程模型的建立，將企業的實際經營過程轉化爲計算機可處理的工作流模型。模型實例化階段完成爲每個過程設定運行所需的參數，並分配每個活動執行所需要的資源，模型執行階段完成經營過程的執行，在這一過程中，重要的任務是完成人機交互和應用的執行。
使用工作流管理系統的目的之一是作爲企業應用系統集成（ EAI ）的平臺。在當前大部分企業級 IT 架構中，各種各樣的異構應用和數據庫運行在企業內網中。在這些系統被應用到組織時，都有一個清晰的目標。例如，客戶管理、文檔管理、供應鏈、訂單、支付、資源計劃等等。讓我們稱這些系統爲專門應用。每一個專門應用都包含它們所支持業務流程的領域知識。這些專門應用中的自動化流程，被拼裝到企業中更大的非自動化流程中。每當一個這樣的專門應用安裝並投入使用，都會帶來涉及其他多個應用的新功能需求。企業應用系統集成（ EAI ）就是通過使用多個專門應用滿足軟件新需求的方法。有時，這只需要在兩個應用之間提供數據通訊的通道。專門應用將很多業務流程硬編碼在軟件中。可以這麼說，在你購買專門應用時，你是購買了一組固定的自動化業務流程。而工作流管理系統是不必事先知道問題域的相關信息的。工作流管理系統將業務流程描述作爲輸入並管理流程實例的執行，這使得它比專門應用更靈活（當然你也要花精力編寫業務流程的規格化描述）。這就是爲什麼說工作流管理系統和專門系統是相互補充的。工作流管理系統可以用來管理全局的業務流程。如果專門應用支持你所需要的業務流程，那麼使用專門應用。在此討論的工作流管理系統的第一種使用方式就是：結合所有的專門應用，使用工作流管理系統構建一個 EAI 平臺。
工作流管理系統能夠發揮很大價值的第二個使用方式是：協助涉及多人相關任務工作流軟件的開發。爲了達到這個目的，大部分工作流管理系統都有一個方便的機制，來生成執行任務的表單。對於專注於 ISO 或者 CMM 認證的組織，採用這種方式使用工作流管理系統能夠顯著提高生產率。不用將過程用文字的形式寫在紙上，工作流管理系統使你通過流程定義建模實現過程的自動化（如使用基於 Web 的應用）。
工作流管理系統的第三種使用方式是：將工作流引擎嵌入到其他應用中。在前面我們談到，專門應用將指定問題域相關的業務流程固化在軟件中。開發專門應用的公司也可以將工作流引擎嵌入到他們的軟件中。在這裏，工作流引擎只是作爲一個軟件組件，對於應用的最終用戶是不可見的。將工作流引擎嵌入到應用中的主要原因是爲了重用（不重複發明輪子）和應用軟件的可維護性。
在工作流管理系統概念的基礎上，演進出很多標準，總體上可分爲基於標準 XML 文檔的和基於 Web 服務技術的兩種規範。
4.1 基於標準XML文檔的規範
4.1.1 概述
此類規範最大的特點就是基於純 XML 技術。其中包括：
WfMC 的 XPDL ， WfMC 發佈的工作流管理系統參考模型提出了五類接口，有關過程模型的定義則構成了接口一（ XPDL ）的核心內容。 XPDL 是至今工作流領域最爲重要的一個標準 , 目前大多數工作流引擎是依據該標準設計開發的。
BPML （ Business Process Modeling Language ）， BPML 是 BPMI （ Business Process Management Initiative ）組織發佈的規範。 WfMC 和 BPMI 在 2002 年 6 月 26 日宣佈將合作制定業務流程和工作流標準，即採用 BPML 來描述工作流過程，同時採用 XPDL 所定義的工作流模型。 BPML 規範爲表達業務流程和支持實體提供一個抽象模型。 BPML 爲表達抽象和執行流程定義了一種正式模型，該模型代表了企業業務流程的面貌，包含了不斷變化的複雜行爲，事務和數據管理，合作，異常捕獲，操作語義。 BPML 爲了能夠持久化和通過異種系統進行定義交換以及使用建模工具，提供了 XML Schema 形式的語法。
在 WfMC 所定義的一系列規範基礎上， OMG （ Object Management Group ）聯合這些規範發佈了 Workflow Management Facility 規範，該規範定義瞭如何將工作流向 CORBA 轉換。
該領域的代表規範就是工作流管理聯盟（ Workflow Management Coalition ， WfMC ）發佈的。 1993 年， WfMC 的成立標誌着工作流技術開始進入相對成熟的階段。爲了實現不同工作流產品之間的互操作， WfMC 在工作流管理系統的相關術語、體系結構及應用編程接口等方面制定了一系列標準。 WfMC 給出的工作流定義是：工作流是指整個或部分經營過程在計算機支持下的全自動或半自動化。在實際情況中可以更廣泛地把凡是由計算機軟件系統（工作流管理系統）控制其執行的過程都稱爲工作流。
圖1 1994年11月 WfMC發佈工作流管理系統參考模型
Work Flow Enactment Service 這個組件就是我們平常說的工作流機或工作流引擎，主要功能是讀取工作流定義、根據工作流定義驅動工作流的流轉。
Process Definition(1) 在流程定義、建模工具、工作流引擎之間定義標準接口。使流程開發人員能夠部署流程定義。流程定義表示一種形式上的業務流程描述，由各種活動以及相互之間的網狀關係組成，標識了流程的開始和終止，並且包含個體行爲的信息，比如各個參與者、與 IT 相關的應用程序和數據，等等。該接口採用的標準是 XPDL （ Xml Process Definition Language ）。
Workflow Client Application(2) 工作流引擎的客戶端程序。該程序由用戶結合業務需求而開發，用它來驅動工作流。客戶端程序通過該接口與引擎交互。一般的工作流引擎用戶不需要懂引擎的實現，只要知道怎麼實現客戶端程序就可以了。
Invoked Application(3) 通過普通代理軟件調用該接口，允許調用工作流引擎之外的功能。
Other Work Flow Enactment Services(4) 與其他工作流引擎協作的接口。
Administration and Monitoring Tools(5) 管理人員通過監控接口獲得流程運行的確切數據。有時，運行日誌也可用於審計。
詳細說明 WfMC 參考模型
接口 1 早期的規範爲 WPDL （ Workflow Process Definition Language ）。後來，這一接口的規範變更爲 XPDL 。 XPDL 是至今工作流領域最爲重要的一個標準，目前大多數工作流引擎是依據該標準設計開發的。 XPDL 利用 XML 作爲流程定義相互轉換機制，在流程定義元模型中， XPDL 語法直接與定義在其中的對象、屬性相關聯。元模型描述了流程定義所需要的上層實體，以及它們的關係和屬性。對於 XPDL 基本元素更加詳細的介紹請參考 WFMC-TC-1025 FINAL Draft 。
接口 2&3 規範爲 WAPI （ Workflow Application Programming Interfaces ）。通過在 WFM 產品中支持這些接口，便於實現需要訪問 WFM 工作流引擎功能（工作流服務）的前端應用程序。此類應用程序的實現，可由 WFM 開發人員或 ISVs （獨立軟件開發商）完成。實現這些 API 調用，還有利於工作流應用程序使用該通用的 API 接口操作不同的工作流引擎。這些 API 調用，允許 WFM 開發人員使用一個單一的最終用戶接口和功能集合，而不用考慮已有的各種 WFM 工作流產品。 WAPI 調用可用各種語言實現。最初的聯盟規範將適用於 ’C’ 語言。該 API 採用 CALLS 的形式。在特定的 WFM 產品實現中，對 CALLS 的底層實現不做任何假設。 WAPI 調用用於運行時（ run-time ），就是說，當流程正在執行或將要執行時。它們通常被用於工作流應用程序（如工作表處理器和協同操作的應用程序等），當某一 WFM 引擎需要在 API 函數上下文內與其它 WFM 產品的工作流引擎交互時，它們也可用於 WFM 引擎。通過其函數集， WAPI 提供了一組由工作流定製服務（ Workflow Enactment Service ）提供的工作流服務。 WAPI 不假設任何特定的用戶接口，更確切地說，它特別地假定了支持工作流的應用程序用戶接口。該應用程序使用這些服務，提供其自己的用戶接口，實現這些接口，依賴於實現它的應用程序開發環境工具。 WFM 引擎的功能大致分爲以下幾類：
l WAPI 連接功能
l WAPI 工作流定義功能
l WAPI 過程控制功能
l WAPI 活動控制功能
l WAPI 過程狀態功能
l WAPI 活動狀態功能
l WAPI 工作表功能
l WAPI 管理功能
對於 WAPI 更加詳細的介紹請參考 WFMC-TC-1009 V 2.0 。另外，可同時參考 WFMC-TC-1013 V 1.4 ，該文檔爲符合 WAPI 的命名規則提供了方針和解決辦法，該文檔也包含 'C' 語言的通用頭文件。
接口 4 規範爲 Wf-XML 2.0 。有必要在流程引擎中集成跨越 Internet 和 Intranet 並能相互作用的標準協議。一個流程引擎，一個異步服務的特殊類型（被稱爲 Asynchronous Services Access Protocol (ASAP) ），一組描述服務運行步驟的活動，就這樣出現了。最後暴露這些步驟，允許服務調用者具有額外對那種服務狀態的瞭解能力。提出 ASAP 的主要目的在於通過 SOAP 提供一種控制和監視異步 Web 服務的基本能力，並傳遞編碼爲 XML 格式的結構信息。控制異步 Web 服務包括構建服務，安裝服務，啓動服務，結束服務，通知異常，通知服務的結束並獲得服務的結果。監視 Web 服務包括檢查當前服務狀態和該服務的歷史執行狀態。外部程序調用最基本的流程的開始和監視只能通過 ASAP 。 ASAP 已經建立了連接異步服務的標準協議，無論他們是否是像流程引擎那樣實現。 Wf-XML 提供一種方法把面向過程工具融入進通用的引用框架。現在流程定義工具就可以已一種標準方式來獲取或更新流程定義了。流程監視工具也一樣能跟蹤流程實例了，也可以跟蹤子流程鏈接和更低一層的子流程。對於 Wf-XML 2.0 更加詳細的介紹請參考 Wf-XML 2.0 Draft 。
接口 5 規範爲 CWAD （ Common Workflow Audit Data ）。通過在工作流產品中支持這一規範，就能在不同的工作流產品中提供一致的審計數據分析。在初始化和執行一個流程實例時，會發生許多影響業務的事件，包括 WAPI 時間，內部 WFM 引擎操作和其他系統以及應用程序函數。有了 CWAD 信息，業務就能確定已經在工作流管理中發生了什麼操作。我們希望審計信息被利用到分析和追溯狀態信息中。另外審計數據可被用作執行操作的證據。工作流分析工具將希望信息以一致的格式表現，描述全部事件，在一套規定的標準內發生 ... 例如，運行“ x ”流程用了多久時間，在一個給定的流程實例內進行了哪些活動？表現出的審計數據將會綁定很細節的內容。對於 CWAD 更加詳細的介紹請參考 WFMC-TC-1015 V1.1 。
其他基於標準 XML 定義的標準發展很弱，在這裏不作介紹了。
4.2 基於 Web 服務技術的規範
4.2.1 概述
Web 應用的巨大成功和不斷髮展，使其滲透到商業領域和個人生活的各個方面。人們只要使用瀏覽器，就可以享受到各種各樣的服務，例如網上購物，網上交易，網絡遊戲，預定車票，網上聊天和交友等等。與此同時，由於 Web 技術所帶來的優勢（統一的客戶端和較好的維護性），使一些傳統的應用紛紛轉型到基於 B/S 架構的瘦客戶端應用程序，這是因爲它能夠避免花在桌面應用程序發佈上的高成本，也能夠很好的解決客戶和服務器之間的通信問題。在客戶端和服務器之間的通信，一個完美的解決方案是使用 HTTP 協議來通信。這是因爲任何運行 Web 瀏覽器的機器都使用 HTTP 協議，可以很好地透過防火牆進行通信。
許多商業程序還面臨另一個問題，那就是與其他程序的互操作性。目前有很多商業數據仍然在大型主機上以非關係文件（ VSAM ）的形式存放， 並由 COBOL 語言編寫的大型機程序訪問。而且，還有很多商業程序使用 C++ 、 JAVA 、 VB 和其 他各種各樣的語言編寫。現在初了最簡單的程序之外，所有的程序都需要與運行在其他異構平臺上的應用程序集成並進行數據交換。在以前，沒有一個應用 程序通信標準是獨立於平臺、組建模型和編程語言的。只有通過 Web 服務、客戶端和服務器才能夠自由的用 HTTP 進行通信，不論兩個程序的平臺和編程語言是什麼。 Web 服務技術完全基於標準的技術，只有基於標準，所有的開放廠商纔能有相同的標準，才能夠在各自的平臺上開發出具有跨平臺互操作能力的軟件產品和解決方案。
經過近幾年的發展， Web 服務的概念漸漸深入人心，隨着社會的發展， Web 服務將越來越流行。基於 Web 服務的工作流規範將推動 Web 服務進入一個全新的階段。
4.2.2 WSCI
2002 年 6 月 26 日 BEA 、 Intalio 、 SAP 和 Sun 在美國發布了基於 XML 的 Web 服務協作接口 WSCI （ Web Services Choreography Interface ）。 WSCI 描述了在特殊流程中通過 Web 服務實現消息流的交流，並描述了集合性信息在互動的 Web 服務間的交流，提出了一種涉及到多種 Web 服務的複雜流程的全球觀點。當今的服務描述語言對於簡單的獲取信息是足夠的，例如股市報價，但它們沒有提供充足的動作細節，來描述服務作爲一個大型的、更全面的協作的一部分所扮演的角色。 WSCI 的關鍵優勢之一在於，它通過描述 Web 服務如何在大型的、全面的業務流程中應用，從而在業務流程管理與 Web 服務之間架起了橋樑。這些業務流程可以只是一個公司內的，也可以是跨越多個公司的。
圖 2 WSCI 層次
Web 服務是才興起的關鍵組件，提供鬆弛耦合和基於 Web 的計算體系。 Web 服務就是可以通過已有的基於 Web 的協議進行訪問的自治領域，有着良好界定，而且基於標準的組件。按照標準劃分出層次的 " 堆 (stack)" 主要目的是保證 Web 服務的語義和技術互用性。這個堆由 W3C 開發，仍然處於初級階段，目前正在被重新構建；爲了使真實的 Web 服務協作成爲可能，還需要多個附加層。平行的，其他標準爲業務流程和協作構建一種嚴密的語義和互用性。可以預見，這兩個堆將在中間見面（ meet in the middle ）。儘管仍需要爲總體框架在一種有效的方式裏發生， WSCI 提供第一步連結這兩個堆。 WSCI 在自下而上的堆裏是一個主要參加者，但可以預見，這會在協作區域的更高一級別層次出現和集成。
對於 WSCI 更詳細的內容請參考 W3C （ World Wide Web Consortium ）的 WSCI 1.0 。
4.2.3 ebXML
ebXML 是一個規範集，這些規範共同實現了模塊化電子商務框架。 ebXML 的構想是實現一個全球電子市場，其中，不同規模和不同地區的企業可以通過交換基於 XML 的消息來合作和進行商業活動。 ebXML 是一項倡議，其參與者與認可者包括幾百家大公司和團體。 ebXML 的直接贊助者是 OASIS （ Organization for the Advancement of Structured Information Standards ）和 UN/CEFACT （ United Nations Centre for Trade Facilitation and Electronic Business ）。許多標準團體也參與其中，包括 NIST （ National Institute of Standards and Technology ）和 W3C 。
ebXML 體系規範定義：
1. 一種描述業務流程和關聯信息模型的標準機制。
2. 一種註冊和存儲業務流程及信息元模型，便於共享和複用的機制。
3. 關於每個參與者的信息的發現包括：
* 他們所支持的業務流程。
* 他們提供支持的業務流程的業務服務接口。
* 各自業務服務接口所交換的業務消息。
* 傳送，安全和編碼協議所支持的技術配置。
4. 一種寄存先前出現的信息的機制，以便它能被發現和挽回。
5. 一個描述能由第 3 項以前，由每個參與者提供的信息組成的相互認可的業務契約的機制。 (CPA)
6. 標準業務消息服務框架，它允許互操作，安全且可靠的在貿易雙方交換消息。
7. 依照業務契約的約束，配置各自的消息服務的機制。
讓我們先來了解一些概念。
註冊表 ：一箇中央服務器，它存儲使 ebXML 工作所需的各種數據。在這些信息中，“註冊表”以 XML 形式顯示給用戶的有：“商業過程和信息元模型”、“核心庫”、“協作協議概要”以及“商業庫”。基本上，當商家要與另一個商家建立 ebXML 關係時，它向“註冊表”發出請求，以查找合適的夥伴並查找有關處理那個夥伴的需求方面的信息。
業務流程 ：商家可以參與的活動（對於業務流程，商家通常需要一個或多個夥伴）。“業務流程”由“業務流程規範模式” ( 一種“ W3C XML 模式”和一個 DTD ）正式描述，但也可以用 UML 建模。
協作協議概要 (CPP) ：由希望參與 ebXML 事務的商家用“註冊表”歸檔的概要。 CPP 將指定商家的某些“商業過程”，以及它支持的某些“商業服務接口”。
業務服務接口 ：商家可以執行其“業務流程”中必需的事務的方式。 “業務服務接口”還包括商家所支持的“業務消息”種類以及傳遞這些消息可能採用的協議。
業務消息 ：作爲商業事務一部分進行通信的實際信息。一條消息將包含多層。在外層，必須使用實際的通信協議（例如 HTTP 或 SMTP ）。 SOAP 是 ebXML 推薦的消息“酬載”信封。其它層可以處理加密或認證。
核心庫 ：可以在更大的 ebXML 元素中使用的標準“部件”集。例如，“業務流程”可以引用“核心流程”。“核心庫”由 ebXML 發起者本身提出，而更大的元素可能由特定廠家或商家提出。
協作協議協定 (CPA) ：本質上是兩個或多個商家之間的契約，它可以從各自公司的 CPP 中自動獲取。如果一個 CPP 說：“我可以做 X ”，則 CPA 會說“我們將一起做 X 。”
圖 3 ebXML 工作流程
上圖中，公司 A 已經知道在互聯網上可訪問一個 ebXML 註冊表（第 1 步）。接着，公司 A 在複查 ebXML 註冊表的內容後，決定構建和部署適合自己的 ebXML 應用（第 2 步）。客戶端軟件開發不是 ebXML 參與者的必要先決條件。適合 ebXML 的應用和組件是很容易通過商業途徑獲得，比如收縮包裝膜這樣的方案。公司 A 接着提交自己的業務描述信息（包括實現的詳情和參考鏈接）到 ebXML 註冊表（第 3 步）。業務描述被提交到 ebXML 註冊表，來說明該企業的 ebXML 能力和限制條件，以及它的支持的業務腳本。這些業務腳本是 XML 版本的業務流程和關聯信息包（比如營業稅計算）。在接受確認後，業務腳本的形式和用法就是正確的了，一個認可被髮送到公司 A （第 3 步）。公司 B 在 ebXML 註冊表上發現了由公司 A 提供的業務腳本（第 4 步）。接着，公司 B 發送一個請求到 公司 A ，他們使用 ebXML 共同參與業務腳本（第 5 步）。公司 B 從 ebXML 獲得收縮包裝膜方案。在參與該腳本的公司 B 直接提交被提議的業務協定到公司 A 相應的 ebXML 軟件接口之前。這個被提議的業務協定要概述雙方達成的業務腳本和詳細協議。該這個業務協定還包含了屬於將用於事務發生的要求的信息，偶然作出的計劃，以及與安全相關的必備條件（第 5 步）。公司 A 隨即接受該業務協定。最後，公司 A 和 B 現在準備從事使用 ebXML 的電子商務。
ebXML 規範集還包含了：業務流程計劃規範、註冊表信息模型、註冊表協議規範、 EbXML 需求規範、 CPP 和 CPA 規範、消息服務規範等。
作者：Rosen Jiang 轉載： http://www.blogjava.net/rosen