Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jwt-dev] About the JWT Model 
Hi Pierre, all

For now (i.e. till your/our next release) I'd let the existing control nodes be,
if only to avoid retrocompatibility issues, until we've found the best way to meet
all the criteria that have been listed, and especially model consistency - and
your/our scheduled work will surely help on this matter.

Please find below some thoughts about more long term solutiosn.


As I said at
https://bugs.eclipse.org/bugs/show_bug.cgi?id=256916 :

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.

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 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.

Thoughts ?

Regards,
Marc

Pierre Vigneras a é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.

Back to the top