Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: AW: [jwt-dev] About the JWT Model

Le Monday 08 December 2008 14:06:20 Florian Lautenbacher, vous avez écrit :
> Hi all,
>
> I agree that currently the restrictions of ForkNode and JoinNode
> (DecisionNode and MergeNode respectively) (having only a single incoming or
> outgoing edge) are only contained in the workflow editor and that this is
> not a good thing. However, I would prefer to leave them in the metamodel,
> but additionally adding some OCL constraints which actually say that a
> DecisionNode is not allowed to have more than one incoming node (others
> similar).
>
> There are plenty of algorithms (e.g. for validation) that require that a
> process model has And-Split and And-Join (as well as XOR-Split and
> XOR-Join) and that would fail if we would remove these nodes from the
> metamodel.

Ok, I understand that.

> More specifically, I currently got a group of students who are creating a
> first version of a JWT validation plugin and that require the DecisionNode,
> MergeNode, ForkNode and JoinNode. If we would now remove these nodes from
> the metamodel, their work cannot be finished or is not valid or usable in
> the end anymore. Their validation approach builds on an idea of IBM called
> Fast Heuristics and makes some simple checks concerning deadlocks and lack
> of synchronization. I will soon create a bug describing their work.

Good. But, it seems to me that the following, rather simple algorithm, will 
tell you if a given node is actually a Fork or a Join (adapting that to 
Decision/Merge is staightforward):

public static boolean isFork(AndControlNode node) {
	return (node.getIn().size() == 1)  && (node.getOut().size() >= 1);
}

public static boolean isJoin(AndControlNode node) {
	return (node.getIn().size() >= 1)  && (node.getOut().size() == 1);
}

Again, since the model does not enforce anything, your student are working on 
instances of the model that only comes from the default JWT editor. 
Basically, the work done by your students will not work with other instances 
based on other JWT-based editors. Removing those leaf nodes will guarantee 
that those algorithms will actually pay attention to constraints. My claim, 
is that since informations about number of edges is already in any model 
instance (getIn() and getOut() methods on any node) and since the constraints 
are expressed elsewhere (either an OCL as you suggest, or in the graphical 
layers), I don't see the point of keeping those leaf nodes. They just don't 
serve any purposes as far as I see, other than making compatibility between 
JWT-based editors an issue.

I am aware of the impact on the current code base of such a removal. This 
modification is *not required* currently. But, we are sufficiently concerned 
on that issue to discuss it right now, and to come to a formal conclusion 
that will be implemented in one way or another at some stage (rather vague, 
huh?)

Of course, since I am quite fresh to JWT technology, it is quite possible that 
I haven't seen problems related to the removal of those leaf nodes.

[snip: we are all concerned about compatibility]

> >>Basically, in the model we may have only two elements : Node and Edges.
>
> Yes, I agree with that and refer to a comment made already before: when the
> aspect mechanism is perfectly working we might think about outsourcing all
> elements of the current metamodel to several profiles/conf-files. Then we
> could have a plugin with a metamodel ActivityNode / ActivityEdge, another
> one which introduces the concepts of Actions and some ControlNodes. A third
> one that has all ControlNodes, StructuredActivityNode and ActivityLinkNode
> and a forth one containing the extensions concerning Data, Application
> and/or Roles. 

I am not sure that this will not lead to some compatibility issues actually. 
What will happen if one tool use one profile, and another tool, another 
profile? At least, with the current model (apart from those leaf nodes 
IMHO ;-)), any tools written for JWT can deal with model instances designed 
with any JWT-based editors. Maybe, I misunderstood something.

> But for the moment I would rather stay with working things 
> than removing them and having something that doesn't work anymore.

Again, for us, the removal of leaf nodes from the model, is not urgent. But, 
discussing it now, will hopefully lead us to a conclusion.

Regards.

PS: Problem with bug tracker is that everyone is not reading to it! And we 
still don't know how to subscribe to all bugs in JWT in order to follow any 
JWT topic. Anyone, a solution?

PPS: Should I copy/paste this inside the related bug?


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


Back to the top