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#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...