[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
AW: AW: [jwt-dev] About the JWT Model
|
Hi Pierre,
>>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); }
Yes, I agree that with the help of such simple methods one can find out
whether it is a join or a fork node. But those do not prevent a user
actually to model a fork and a join in one. This means that a user can now
have an AndControlNode with several incoming and several outgoing edges. And
then several algorithms would fail and the only thing the system could tell
the user is to model according to predefined modeling guidelines where the
restriction is made, that either an AndControlNode has several incoming OR
several outgoing edges. I can't say whether this is an advantage or more a
disadvantage.
I know that UML is not the best example, because its semantics is very often
only defined by texts, but in the definition of Activity Diagrams the
following different kinds of control nodes are defined: DecisionNode,
MergeNode, ForkNode and Join Node (besides others). For DecisionNode the
specification says that it has one incoming edge. So at least for our UML
view we will later on need this distinction again!
Other languages like YAWL also assume that there are differences between
AND-split and AND-join, but of course, this comes from the academic area and
was defined according to the "Workflow Patterns" by the group around van der
Aalst, so might not be so important for practical interoperability.
On the other hand I also see EPCs or BPMN, where there is no distinction
between Fork and Join (Decision/Merge), but where on the other hand
additional gateways are introduced (like event-based XOR, Complex, etc.).
So in order to allow JWT to have a full BPMN view it is probably strange, if
there are several gateways that only allow to have one incoming or outgoing
edge and have other gateways that don't prohibit that.
Therefore, in the longterm I agree that removing these more specific
AndControlNodes (ForkNode and JoinNode) and XorControlNodes (DecisionNode
and MergeNode) would make sense, but then these should be available in
aspect-extended plugins such as the UML view that we currently have.
But of course, this will require
- a new conversion mechanism between old workflow-files and the new files.
Currently the update-mechanism only allows to have additional nodes, but not
to have less nodes in a newer (meta)model
- the finalization of the new view-mechanisms Chris is currently working on
including a conversion mechanism between different views (a DecisionNode in
UML is displayed as XorControlNode in other views, but should be displayed
as DecisionNode again in the UML view, but of course this is related to all
kinds of aspects later on)
Do you think that it would be a problem to have these nodes (DecisionNode,
MergeNode, ForkNode, JoinNode) again in aspect-based views? What are the
thoughts from others concerning this topic?
Are there other things in the metamodel that you think should be removed?
Best regards,
Florian
-----Ursprüngliche Nachricht-----
Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im
Auftrag von Pierre Vigneras
Gesendet: 08 December 2008 16:41
An: Java Workflow Toolbox
Betreff: 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
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev
