完整的jBPM4 PVM介绍发表在《程序员》第8期，这里截取部分的意思是PVM的过程调度是非常灵活的，PVM提供了一套和token类似的execution过程调度机制，通过对execution的完全操控，节点运行期行为有了无限的可能。
PVM的流程定义模型
首先要说明的是，上图里的类全是接口。位于最上层的是ObservableElement，其提供给流程元素以附加Event（事件）的能力。在 ObservableElementImpl里，它持有一个events的集合属性。对于流程元素来说，典型的事件有：流程启动/结束，节点启动/结束和转移线执行（take）。
Java代码
protected Map<String, EventImpl> events;
Event又做了些什么呢？EventImpl透过EventListenerReference实例的集合持有EventListener实例。这样在引擎执行过程调度时，就非常容易地通过流程元素本身获取事件监听器并在相应的时候执行它们。
Java代码
protected List<EventListenerReference> listenerReferences;
和传统的观察者模式一致，EventListener接口有且只有一个方法：
Java代码
void notify(EventListenerExecution execution) throws Exception;
紧接着ObservableElement的是CompositeElement，其扩展了ObservableElement接口。先看看它的方法：
Java代码
List<? extends Activity> getActivities();
boolean hasActivity(String activityName);
Activity getActivity(String activityName);
很明显，它持有了Activity的集合，对于ProcessDefinition来说，这是一件很自然地事情：流程定义包含多个节点定义。重要的是Activity自身华丽的变身：节点定义实现了嵌套，出现了结构块。看图说话：
这一设计在jBPM3里是没有的，但是在jBPM4里则必须出现，因为结构块是BPEL和BPMN里的重要概念。既然号称PVM，则必须向BPEL和 BPMN致敬。稍后我们可以看到，结构块的引入给引擎过程调度增加了很大的复杂度。在jPDL里，与之对应的实现是group。这是jBPM4流程定义模型的最重要改变。
ProcessDefinition和Activity分别继承自CompositeElement，Activity和Transition建立起双向关联，这三者也是工作流模型里的标准建模。