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