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