在jBPM中，任務的分配有兩種模式：
- 推（Push）模式 在這種模式下，系統計算出應該由哪個參與者(actor)完成當前任務(task)，然後直接將此task送到該actor的任務列表中(tasklist)；
- 拉（Pull）模式 在這種模式下，系統首先計算出應該由哪個參與者池(pool of actors)完成當任務，並將該任務送入相應的任務池中；然後，再由參與者池中的任一人將任務拉到自己的任務列表中。
參與者池與角色、用戶組的差異
一般的應用中，角色與用戶組的概念比較常見，而參與者池則不常見。
針對一個Task一般會有多個可能的操作，而不同的角色有可能有權限進行其中的一部分或全部操作。所以，不同角色有可能屬於相同的參與者池，一個角色也有可能被加入到多個參與者池中。
一 般用戶組是按組織架構進行劃分的，在同一個用戶組可能會有多個不同的角色，或者具有不級別的權限。即使將同一角色、具有同一級別權限的用戶劃分爲一組，也 不能迴避具有更高級別權限的用戶操作低級別工作任務項的情形。另一方面，在Multi-Entity架構下，也存在跨Entity操作的情形。
總而言之，參與者池是區別於按角色、按組織進行劃分的、一種特別的用戶分組方法。換言之，參與者池其實也是可以預先定義的。
何時進行任務分配計算
既然參與者池是可以預見的，那麼在“拉模式”下，何時進行任務分配計算呢？
毫無疑問，在工作流系統中，計算是在任務狀態轉換時自動完成的。（當然，相對於應用的事務提交，工作流的這些操作都可以是異步完成的。）
因些，“拉”的含義，不是在用戶刷新任務列表時纔去計算他/她的所有工作項；恰恰相反，無論是“拉”或是“推”，工作流系統其實都預先計算好了參與者的任務列表或可以從中挑選任務的“任務池”。
jBPM參與者池的數據庫設計
jbpm_taskinstance與jbpm_pooledactor是典型的“多對多”的關係，中間通過jbpm_taskactorpool拆分成兩個“一對多”。
原文:http://dayubian.spaces.live.com/blog/cns!9E5A349DF844201E!365.entry
