Re: [jwt-dev] About the JWT Model

[Pierre Vigneras <pierre.vigneras@xxxxxxxx>]

Le Friday 05 December 2008 14:03:07 Pierre Vigneras, vous avez écrit :
> Dear all,
>
> recently, we submitted a small modification of the JWT Model that
> introduces two new elements: AndControlNode and XorControlNode (initially
> called XorGateway and AndGateway).
>
> Please, see bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=256916
>
> The main point to get is the following:
>
> Since our modifications, the EMF model contains the following elements:
>
> ControlNode
> 	<- XorControlNode
> 		<- DecisionNode
> 		<- MergeNode
> 	<- AndControlNode
> 		<- ForkNode
> 		<- JoinNode
>
> We feel that leaf nodes (DecisionNode, MergeNode, ForkNode and JoinNode)
> are both very UML specific and redundant, i.e, not required. Obviously, a
> forkNode is just an AndControlNode with multiple outgoing transition. A
> MergeNode is just an XorControlNode with multiple incoming transition. Note
> that BPMN allows a node to have multiple incoming and outgoing transition.
> In this case the semantic for the Split and Synchronization is the same:
> either an Xor or an And. Currently the constraints on the number of
> transitions (either incoming or outgoing) are already in the controller
> (editpart) of the related model (e.g.: ForkEditPart for the ForkNode). So,
> using the new model, the behavior of the ForkNode is given by its father
> element, AndControlNode. Nothing else is provided by the model itself.
>
> We expect JWT to get wide community adoption, and therefore, new tools
> based on JWT and on this EMF model to be developed. We would like those
> tools to support any design (UML, BPMN, whatever) developed with any
> JWT-based designer as long as those tools deal with the model only (for
> example simulator, monitors and so on). We guess that developers of those
> tools may naturally use leaf nodes of the model (ForkNode, JoinNode, and so
> on) instead of their fathers (*ControlNode). And we guess that it may lead
> to
> compatibility problem between different tools.
>
> So the question is: can't we remove those leaf nodes?
>
>  We understand that it will have some impact on JWT but most of the logic
> is already in controllers anyway (editparts). Leaf nodes do not contain any
> information by themselves (as far as I can see, tell me if I am wrong).
>
> What are your opinions at JWT levels?
> What are the opinions of other contributors? (JBoss particularly)
>
> Regards.

Marc replied (taken from bug):
> > I'm really glad you take compatibility seriously, because it means we
> > have the same vision of JWT as a ways to unify the field workflow tools.

Sure! ;-) 

> > However I'm not sure what is the right thing to do here.
> >
> > Notably, you say that "By the
> > way, I have the feeling that those leaf nodes provide redundant
> > informations (a fork is an And with multiple outgoing transitions, and so
> > on)". But what about an And with single ingoing and outgoing transitions
> > ? If it were a fork, we would at least now that we CAN add one more
> > outgoing transition but no ingoing one.

The model does not enforce that "single incoming, multiple outgoing transition 
on fork" constraint anyway. To be more precise, the EMF model does not 
contain that information. Only the GEF part, I mean the controller part (aka 
EditPart in the GEF terminology of MVC) enforces that constraint. Therefore, 
from a strict EMF model point of view, there is nothing that tells someone 
that fork has only one incoming transition. Only the UML knowedge. But if 
tools will follow EMF, some of them will not follow UML anymore (ours will be 
BPMN based, not UML, but their may be others since JWT targets 
universality ;-)).

By the way, note that multiple incoming and outgoing transitions on the same 
node is possible in BPMN...

In my opinion, since the constraints are expressed in the graphical part 
anyway, it is not a big deal to remove that leaf nodes, and making the model 
more concise/precise. I mean, it will probably require quite a lot of change, 
but nothing very complex, I think. 

> > The only other way to store this information would be in another model /
> > configuration dedicated to behaviours / actions that are allowed on the
> > workflow model.
> >    * This behaviour model could be also used as a basis to validation
> > rules ; but note that validation rules on their own (i.e. checkThis()
> > methods) would not be enough to know wether a given action or metamodel
> > change is allowed (ex. a canDoThis() method).
> >    * I believe such validation rule model / configuration is needed to
> > foster share and reuse of existing rules (that would only have to use
> > another rule configuration), in opposition to having only java-hardcoded
> > rules that would only apply ex. for a given vendor.
> >    * one disadvantage would be that other tools would find it harder to
> > use, because it is yet another model / configuration that has to be used
> > / parsed / transformed in relation to the JWT model. At least runtime
> > tools, which are not interested in changing the model, would not have to
> > know it.
> >
> > Another solution to ensure everyone speaks the same "model language"
> > would be to provide by default a transformation that transforms a model
> > to a "normal form", which would be ex. the "most complete" form when
> > considering the amount of information it contains, therefore a form
> > without "And" but with "Fork" nodes.

As for me, the model with only 'And' and 'Xor' is self sufficient. Constraints 
are expressed somewhere else (at a graphical level currently, in a specific 
constraints engine in the future if required).

Thoughts?


-- 
Pierre Vignéras
Bull, Architect of an Open World TM
*BPM Team*, Bull R&D
1, rue de Provence
38130 Echirolles (France)
Direct Line: +33-4-76-29-74-06

*Orchestra*, The BPEL open source project: http://orchestra.ow2.org
*Bonita*, The XPDL open source project: http://bonita.ow2.org