[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
AW: [jwt-dev] About the JWT Model
|
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.
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.
>>But we are concerned on compatibility issues raised by the model.
That's exactly what I am concerned about, too, so I guess we will come to a
conclusion that does fit all.
>>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. But for the moment I would rather stay with working things
than removing them and having something that doesn't work anymore.
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 11:30
An: Java Workflow Toolbox
Betreff: Re: [jwt-dev] About the JWT Model
Le Saturday 06 December 2008 02:52:09 Koen Aers, vous avez écrit :
> >> What are the opinions of other contributors? (JBoss particularly)
>
> Hi all,
>
> Actually my personal opinion in this discussion is 'the simpler the
> better'.
>
> From a 'drawing perspective' it doesn't really matter how much info
> the metamodel contains. We think that all the nodes can be expressed
> by one generic node type which contains a set of properties and a set
> of constraints on those properties.
Of course, and I was of the same opinion initially. Basically, in the model
we may have only two elements : Node and Edges. The remaining parts can be
roughly expressed by properties. On the other side, I have the feeling that
we have to agree on a common set of basic elements at the model level that
provide enough informations for any extensions/tools (especially simulators)
and that guarantee as far as possible, the compatibility of all of them.
I think that properties do not provide the required compatibility guarantee.
The model does as far as it is consistent and self-sufficient. In the case
of the leaf nodes (Fork and others), I think we have both redundant
informations, and mis-enforcement: I mean, that the requirement of UML Fork
-- only one incoming transition -- is not enforced at all in the model, but
in the graphical layer (edit part). Therefore, I propose either to remove
those nodes or to ensure those requirements are enforced (but I don't know
how to do it in a simple, straightforward manner).
> An 'execution perspective' would add behaviour to this generic node
> type but that is of lesser importance for modelling (it is for
> simulation though).
Right, and we are quite concerned by those simulators. We expect any
simulators based on JWT to understand any design based on JWT model.
> This is very close to what Marc describes earlier. I didn't take a
> close look yet, but as I understood it, aspects can take us a long way
> in that direction.
Of course, aspects can help for the actual implementation. But we are
concerned on compatibility issues raised by the model.
--
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
