Read jBpm Responsibilities

JBpm3.0 has been out for more than ten days. It is only two days ago that I used my spare time to simply flip through the document, but I really don't have time to flip through the source code. The model definition of 3.0 is not changed much on the whole, but it is extended a lot: the super-state is added, the event definition is extended, and timer and exception-handler are added. Of course, there is also the biggest extension, that is, the GPD based on eclipse plug-ins (jBpm graphical process definition), unlike 2.0 or swing, and 2.0 is useless. -- After a brief introduction, 3.0 of the graphics are more human-oriented, and jboss has not yet acquired the image. Haha, the above is just an introduction, and the subject is entered below. Now that I have set the title to "read jBpm Responsibilities", we should start with jBpm Responsibilities. (1) Let's first look at jBpm's ambitions. jBpm is very ambitious. Perhaps this ambition was not fully revealed in its 2.0 s. However, if we can be acquired by jBoss, it seems that jBoss is still very insightful, or it may be said that Uncle Tom has great foresight and ambition. The following section is taken from the jBpm Responsibilites description: A new proposalThe proposal below takes the best of three worlds. in short, this is how you can think of the proposed model: Finite state machines are taken as the basis. then the concurrency features of activity diagrams are added. and at runtime, the execution semantics of petri nets are used. from this sentence, we can see that jBpm needs to use three process modeling methods (algorithms) in one breath: using the state machine as the basis for controlling state changes, and expanding the modeling model of activity graphs, the execution mechanism adopts Petr INet algorithm.
Of course, because jBpm is still only positioned in workflow, it is estimated that the EPC modeling method will not be incorporated in a short time. However, even the three process modeling methods mentioned above can make jBpm sweep all open source workflow engines. It can even be said bluntly, but from the engine perspective, it has far surpassed many commercial workflow products.
However, to be honest, at least now. I think this is just a dream of Uncle Tom. From the previous analysis of jBpm kernel code and algorithms (mainly jbpm2.0 and 3.0 I haven't looked at them yet), FSM is estimated to be difficult to apply in jBpm, unless jBpm expands the description of the action, this is impossible at all. For the other two, the Activity divisor is the core idea of jBpm. As for Petri Net, jBpm is used in disguise, but far from execution semantics.
(2) Here we will explain how Token understands jBpm Token thoroughly, so we will understand jBpm in half.