在sourceforge的jBpm项目的论坛上看到的Tom的言论:
Ardian, The reason why jBpm sticks to UML-activity-diagrams is for easy-acceptance. Petri nets are easy, but not as easy and widespread as UML-activity-diagrams. The downside of UML-activity-diagrams is that they are not exact and they do not contain enough information to specify a complete business process. That is why each tool or standard that starts from an UML-activity-diagram has to extend the diagrams with information such as : which data-items are input/output on which activities, how does the process interact with other systems, to whom will the activity be assigned, ... jBpm specifies these extensions in http://jbpm.org/new/jpdl.html So after extending the UML-activity-diagram concepts, the resulting language will be quite close to high-level-petri-nets. That is why, in my opinion, high-level-petri-nets should be seen as the 'mother of all process languages' So a good BPM-system should present an easy interface to the users (=process developers) and base the internal impementation on high-level-petri-nets. As for jBpm I think using UML-activity-diagrams is an easy way of presenting the concepts to users that lowers the learning curve. But I did not yet have time to actually compare jBpm's interal model with high-level-petri-nets or YAWL. But I'm convinced they will not be far apart. I talked last month to Wil van der Aalst (after I wrote the initial message of this thread) and it is also his vision that BPM-tools should be based internally on high-level-petri-nets (or YAWL) and that they should try to present it as easy as possible to the user. YAWL is an exact specified version of high-level-petri-nets that is customized for building process definitions. He thinks of YAWL as a kind of playground for research-purposes. So I got the impression that he didn't expect that YAWL would be used in BPM-engines at this stage. Now, I'm starting to form a new vision on standards and languages. I want to build jBpm in 2 layers : a generic layer and a set of default implementations. jBpm's delegation principle (see http://jbpm.org/new/concepts.html#delegationprinciple) is in my opinion a very good basis for such an approach. The generic layer should be a kind of framework for BPM-systems. The generic layer should be the basis of a BPM-engine in which implementations can be plugged (i.e. in a process definition). The generic layer should be constructed in a way that implementations can be plugged that support all workflow-patterns (see http://tmitwww.tm.tue.nl/research/patterns) By separating these two layers, support of a specific standard or behaviour should be easy to add. Regards, Tom.
.: 
