BPMN的流程模型
我們使用業務流程建模來交流信息，正如在上一節里所述，根據不同模型的用戶（客戶、業務人員、分析人員、開發人員），建模有著不同的風格。BPMN被設計用來涵蓋各種風格的流程模型（以滿足不同角色人員交流的需要）和創建端到端的業務流程，它支持三種基本類型的流程模型：
Ø 流程編制（Process Orchestration），包含：
- 私有的不可執行的（內部的）業務流程；
- 私有的可執行（內部的）業務流程；
- 公開流程。
Ø 編排（Choreography）
Ø 協作（Collaborations），包含流程與/或編排。
私有的（內部的）業務流程
私有的業務流程是指某一組織的內部工作流程，我們通常稱之為稱為工作流，在WEB服務領域，我們也稱之為服務的編制（Orchestration）。存在兩種類型的私有業務流程：可執行的和不可執行的。可執行的私有業務流程以被計算機執行為建模目的，由相應的BPMS系統來自動化流程的執行，它包含了足夠的執行細節，這些細節包括執行規則、條件表達式等計算機解釋執行所需要的技術信息，該模型最直接的用戶是開發人員。不可執行的私有業務流程則以文檔化為建模的目的，它缺少執行細節，但是包括足夠的交流信息，該模型的用戶包括了業務人員與分析人員。
作為一個例子，我們一起來看看我在公安局戶籍科為兒子辦理戶口的流程，如下圖所示：
圖1公安局戶籍科上戶口的流程
當我來到戶籍科，遞上足夠的資料，然后就開始等待。我能看到共有四個工作人員，第一個工作人員負責接收資料，查看資料是否完備，接下來，她將所有的資料傳遞到下一個工作人員，第二個工作人員對資料進行審核，在計算機上查看我們的戶口信息是否正確，接下來，如果資料無誤，他將資料傳遞到第三個工作人員，第三個工作人員負責在計算機上為我的兒子錄入新的戶口，最后打印出一張戶口頁，第四個工作人員是職位最大的警員，她負責蓋章，然后將兒子的戶口頁傳遞給在窗口外等待的我。
根據上面對私有業務流程的定義，我們很容易的判斷出這個流程是個不可執行的私有業務流程，因為該流程是戶籍科的內部工作流程，作為該流程服務對象的我，我根本不用關心戶籍科內部是如何對我的申請進行處理的，所以它是私有業務流程。該流程是由規章或制度所規定的，由工作人員來驅動，并非通過計算機協調，所以這是個不可執行的私有業務流程。
因為私有業務流程是內部流程，所以它只能存在于一個池（pool，池代表一個參與者）里，如下圖所示，我們可以將私有業務流程建模在一個池里，但通常這樣做沒有太大的意義，更經常的情況是，我們選擇將池忽略。
圖2公安局戶籍科私有業務流程的另一種建模形式
公開流程
公開流程表現一個私有業務流程與其他流程或參與者之間的交互。
還是以戶口辦理作為例子，作為戶口申請人，我來到公安局戶籍科，我心揣揣，我不知道我該做些什么，于是我看到大廳里如下圖所示的流程，于是我立刻就明白了，我只需要將資料交給辦事人員，然后等待取新的戶口頁即可。
注意下圖所示的公開流程與圖1所示的私有流程有哪些不同。第一是圖中出現了多個參與者，參與者間通過消息流連接（圖中虛線箭頭連線）；第二是戶籍科的辦理流程被縮減到只剩兩個與外部參與者交互的活動，兩個原有的內部活動被忽略了。這兩點不同即是公開流程的特點：表現與外部參與者、流程間的交互，忽略內部活動。聯想到我們實際的編程，總結成一句話，就是隱藏內部實現細節，僅僅展現對外接口，表現流程的外部行為。
圖3公安局戶籍科辦理戶口的公開流程
協作
協作描繪兩個或多個業務實體間的交互。一個協作通常包含兩個或多個池，每個池代表一個參與者（業務實體）。參與者之間的消息交換通過連接兩個池（或池中的對象）的消息流表現。協作可以表現為兩個或多個公開流程之間的交互，在上一節里，我們提到，與對應的私有流程相比，公開流程隱藏了內部細節活動。池也可以是黑盒，即里面什么對象都沒有。
那么，這里有一個問題，公開流程與協作有什么區別？區別在于表現的范圍，公開流程只是表現一個私有流程與外部的交互，而協作則能表現多個流程/參與者之間的交互。
還是看戶口辦理的例子，在前面的例子中，我們看到了公安局戶籍科辦理戶口的私有流程和公開流程，似乎辦理戶口是一件很簡單的事情，但這僅僅只是辦理戶口中的一步而已。在此之前，我先要去醫院辦理小孩出生證明，接下來，我要去居委會登記小孩信息，再接下來，我要去計生辦辦理符合計劃生育政策的證明，最后，我才來到戶籍科。下圖是整個戶口辦理的協作圖，作為簡化，這里將除申請人和戶籍科之外的池都黑盒了：
圖4戶口辦理協作圖
編排
同樣是表現多個參與者之間的交互，編排做的更為純粹，它取消掉了池的概念，改由編排活動直接表現多個參與者之間的消息交互，為協作模型提供了一種基于流程圖的視圖。戶口辦理的編排圖如下圖所示，其中每個活動都能看到上下的方形區域有參與者信息，這表明這個活動的參與者，淺色部分為活動的發起者，深色部分為活動的響應者，我們會在接下來的BPMN元素小節里詳細描述這一活動類型：
圖5戶口辦理編排圖
與協作圖相比，編排圖省略掉了更多的細節，例如與各個參與者具體的交互過程，它關心誰和誰產生了交互，至于如何交互，分幾步交互，它并不關心。例如辦理戶口這個活動，實際上我是分別和兩個警官進行了交互，一個是負責接受資料的年輕女警官，一個是負責蓋章復核的領導警官，在協作圖中，我可以通過公開流程展現出這一點，但是在編排圖中，這并不是要表現的重點。
協作圖表現出參與者之間的交互，并包含交互的細節信息（交互的接口、如何交互）；編排圖則以流程圖的形式表現出參與者之間的交互，它關心的是某個任務需要哪些參與者發生交互，交互的細節不是其表現的重點。
編制與編排的區別 |
在上文中，我們提到了服務的編制（Orchestration），這里，我們又提到了編排（Choreography），這兩者是有很大區別的。 WS-BPEL將SOA中的服務按照一定的順序靈活組裝在一起的流程就是編制（Orchestration）。編制后的WS-BPEL流，通常代表了某個特定的業務中的服務的執行流。而編排（Choreography）則是描述參與者之間交互關系的流程。與編制不同的是，編排并不需要一個執行引擎，它只是描述關系。編制代表的是一個可執行流程，它必須通過執行引擎來執行。而編排實質上是代表一種描述，即參與者之間如何互相協調來完成一個目標。 John Reynolds在其博客中是這樣描述編制和編排的區別[1]： 編制 == 可執行過程 Web服務編制與執行特定的業務流程相關。WS-BPEL是一種用來定義可以在一個編制引擎中執行的流程語言。 編排 == 多方合作 因此編制必須對應一個執行引擎，而編排由于涉及到多方合作，所以它是不能被直接部署的。 |
協作的會話視圖
會話視圖為協作圖提供了另外一種非正式的表現形式，與編排圖一樣，它的目標同樣在于表現參與者之間的關系，它將一系列相關的信息交互定義為一次會話。戶口辦理的會話圖如下圖所示，圖中只存在池與會話（Communication）元素，會話元素由圖中的六邊形代表，它代表兩個或多個參與者之間一系列相關的信息交互，我們可以看到，辦理戶口需要申請人與四個組織發生四次會話：
圖6戶口辦理會話圖
會話視圖的作用之一是能夠有效減少模型中消息流的數量，便于我們理解。
圖7會話視圖簡化交互模型