[jbpm-dev] [Design of JBoss jBPM] - First look at jBPM4 Alpha1

Tom Baeyens tbaeyens at redhat.com
Wed Jan 14 09:43:36 EST 2009


> This sounds like a lot of criticism, but my general impression is good. The docs
> cover sufficiently what is there already. Designer and implementation seem to be in
> sync. The list of examples covers available functionality.

thanks.  you might have noticed your good influence here and there :-)
thanks for those ideas and the constructive critisism.  it's really appreciated.


as for BPMN: over the course of the last iteration, it became clear to me that aiming 
for full BPMN support will be too hard to do with jPDL itself.  i do want to stick to 
the strategy we set out in the antwerp: big BPMN influence in jPDL and align it there 
where we can, but opt for practicality in those situations where it conflicts with 
pure BPMN semantics.

we can always pursue exact BPMN semantics in a separate language.

regards, tom.


thomas.diesler at jboss.com wrote:
> First of all, congratulation for getting out the long awaited release - well done.
> 
> I got the download from SF, installed the GPD, read the docs, had a look at the API and generally tried a few things - here my impressions. May it be helpful ;-)
> 
> The new graphical designer (GPD) looks really nice. It finally adopts the BPMN standard for its graphical elements, which looks really nice. 
> 
> There is the notion of start event, and end event, a few gateway types and a significant number of tasks.
> 
> What is a little bit confusing is some inconsistency in the terminology that is being used in the GPD, the docs and the API. BPMN talks about exclusive, inclusive, parallel and complex gateways. These have a specific semantics and everybody who knows BPMN would also know their semantics. GPD on the other hand talks about exclusive, fork, join
> 
> The jbpm4 docs sais
> 
> anonymous wrote : 
>   | (BPMN note: when we mention activities here, we are not only refering to BPMN activities, but also to BPMN events and BPMN gateways.) 
>   | 
> 
> If possible, I would not do that. An activity is an activity (namely a task or a sub-process), an event is an event, a gateway is a gateway.
> 
> jBPM4 allows multiple outgoing flows on a task. This combines the notion of task with the notion of gateway. It is however not clear what type of gateway is being combined here and if we assume that it is an exclusive gateway, it not clear whether the full functional set of an exclusive gateway is also available on the task.
> Can every task have multiple outgoing flows?
> 
> I would recommend not to mix task and gateway (just yet). Let the user draw a task with a single outgoing flow followed by a gateway. A condensed notation can always be added later when the individual components reached enough stability (i.e. after CR)
> 
> The docs talk about "end state" - this should be "end event" - cancel and error are "event details" that if attached to an end event are called "result"
> 
> Generally, I'd recommend not to invent new terminology for a concept in the BPMN editor that already has a "standard" name in BPMN. Also don't use existing BPMN terminology to mean something different.
> 
> The API combines the notion of ProcessInstance with that of Token in a single interface and calls it "Execution". This will not allow these two concepts to evolve independently for example when you want to add state independently to the ProcessInstance and the Token. It is generally better to model a concept like ProcessInstance as such and call it by it's name. If you cant do much (yet) with a ProcessInstance you will have a short method list, which is ok.
> 
> The GPD elements in the process definition should be defined in their own namespace
> 
> Instead of
> 
> 
>   |    <start g="32,22,80,40">
>   | 
> 
> jBPM should have 
> 
> 
>   |    <start gpd:g="32,22,80,40">
>   | 
> 
> This allows GPD metadata to evolve independently of the process definition itself and also makes it clear that 'g' is a presentational and not a functional element.
> 
> During GPD installation, the license text is missing. 
> 
> This sounds like a lot of criticism, but my general impression is good. The docs cover sufficiently what is there already. Designer and implementation seem to be in sync. The list of examples covers available functionality.
> 
> Thanks for Alpha1, I'm looking forward to stuff to come. 
> 
> View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201795#4201795
> 
> Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201795
> _______________________________________________
> jbpm-dev mailing list
> jbpm-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbpm-dev

-- 
regards, tom.




More information about the jbpm-dev mailing list