Read JBPM Responsibilities

        jBpm3.0 out for 10 days, really just two days before the use of free time, simply turned over the document introduction, but there is no time to go over the source code. The 3.0 model definition has been changed a little, but it has expanded a lot: super-state, expanded the definition of event, added timer and Exception-handler. One of the biggest extensions, of course, is the GPD (jbpm graphical process definition) based on the Eclipse plug-in, unlike 2.0 or swing, and 2.0 is simply not available. --A brief look at the introduction, 3.0 of the graphic to do more human nature, and finally did not white by JBoss acquisition. Haha, the above is just a primer, the following to get to the point. Since I set the topic is "read JBPM responsibilities", that will be from the jbpm responsibilities said. (a) First of all, it is very ambitious to see JBPM's ambition jbpm. Perhaps this ambition was not fully revealed at the time of its 2.0. But to be able to be acquired by JBoss, it seems that JBoss still has a good eye, or perhaps should say Uncle Tom has foresight and ambition. The following passage is excerpted from jbpm responsibilites Description: A new proposalthe proposal below takes the best three worlds. In (short), this is how to you can be 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 we can see, jbpm to take a breath all three kinds of process modeling method (algorithm): Using state machine as the basis of control state transition, and expanding the modeling model of activity graph, The implementation mechanism adopts petrinet algorithm.         of course, because JBPM is still only located in workflow, so it is estimated that the EPC will not be built in a short timeModular method. But even the three process modeling methods mentioned above are enough to allow jbpm to sweep through all of the current open source workflow engines. It can even be said without a word, but from the engine point of view, has far surpassed the current many commercial workflow products.        yet, to be honest, at least for now. I think it's just one of Uncle Tom's dreams. In terms of previous analysis of JBPM kernel code and algorithms (mostly jbpm2.0 versions, 3.0 of which I haven't looked at), FSM estimates are more difficult to apply in jbpm unless JBPM expands the action meaning it describes, but this is simply not possible. For the other two, the activity diagram is JBPM's core idea, which is not said; As for the Petri net, jbpm is a bit of a disguise, but far from execution semantics this degree.   (ii) to explain the token        to jbpm token understand thoroughly, then also understand half jbpm.         as the whole process instance runs, JBPM wants a mechanism that can be quickly positioned to the current state. (about the current state, or the state concept, here is not explained, do not know, go to see the JBPM help document, so more direct).         We know (of course, if you're familiar with PN), Petri Net leverages a concept called token, Can quickly and accurately locate the place and transition, of course, for PN, Token's main purpose is not this (but for the ability to judge), but it can effectively solve the problem.         and jbpm then borrowed this concept, introduced the concept of token, we can quickly use token can get its current state.         but how to solve the problem of "parallelism" and so on the rapid positioning of the current state, such as Splite (jbpm called fork) situation? JBPM in order to solve this problem, so the token object to maintain theParent-child relationship, which arises when it comes to fork. This I have in the "Workflow engine scheduling algorithm and petrinet" in the analysis of the JBPM is also described.         jbpm Let token the object of a variety of missions: (1) Fast positioning of the current state (2) for Fork,join algorithm (3) A task index used to inform a task performer, whose function is similar to what we normally call WorkItem.         It's hard to say how good and bad this multiple-job approach is, at least I've found that foreign workflow gurus seem to be very inclined to use this approach, such as the yawl led by Alast. (iii) Activity, state and action                  This theme is not much in the  jbpm responsibilities , another article specifically introduced: Why the term ' activity ' should to be banned ...   (http://jbpm.org/2/state.of.workflow.html#activityshouldbebanned)                  Uncle Tom's most classic argument is that it confusing because an activity is either a State or a action. Indeed, in the concept of WFMC, the intensity of the description of the activity is not fine (so a whole bunch of application,tool,auto,manual) are used.         JBPM is a lot more straightforward, just state (where it is, or position) and action (the action performed). However, it is estimated that Tom has also forgotten an understanding of auto and manual. There's only state in the JBPM, and these sTate are artificial, the so-called automatic processing is done through the action-illustrious, as if jbpm such treatment, some unreasonable, at least I am not accustomed to.                 I support the concept of activity, But I also like jbpm's action and Osworkflow's action. --Oh, a bit messy. --at least I want to do the engine, will try to keep some extensible interface, the experience of the implementation of these years, I have to do so. Domestic customers, you must be a day for the proposed one you do not like the need to For example, the monkey fished for months.