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