[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: AW: AW: [jwt-dev] About the JWT Model
|
Le Tuesday 09 December 2008 16:21:24 Florian Lautenbacher, vous avez écrit :
> 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.
What will prevent the user (in other words what will enforce constraints) will
be an external part. The current model does not guarantee constraints. So you
only rely on the editor to get that a fork node is actually an UML Fork Node.
Basically, my point is that current leaf nodes do not represent any useful
information at the model level (again, the external layer will guarantee that
the Fork is what you expect to be a Fork, the model does not tell that).
> This means that a user can now
> have an AndControlNode with several incoming and several outgoing edges.
Sure, this is possible. BPMN allows that. By the way, our end-users want that.
Therefore, at least one JWT-based editor will have such a feature: ours!
I bet that if JWT gain some wide adoption, you will find some other editors
with the same pattern.
> 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 agree, several algorithms would fail in that case. My point, is that if the
JWT model does not change, then other editors and tools may be based on that
model, but they may misuse it since constraints are not at the model level.
For exemple, one may not use the JWT editors, but still use a Fork Node with
multiple incoming and outgoing transitions --- this is allowed by the JWT
model. This is where I actually see some compatibility issues.
> 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!
Yes, in the view, you have to make the distinction. This distinction does not
exist in the model currently.
> 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.
Actually, there is no concept of AND-Split or AND-Join *Node* similar to the
one in JWT, in YAWL as far as I know (but I don't know YAWL very much, so I
may be wrong). You attach such an And-Split to a Task (a JWT Action). This
looks much like XPDL actually. This also means that you may have one Task
with both an AND-JOIN and an XOR-Split for example. This pattern cannot be
mapped directly to JWT anyway. A transformation YAWL2JWT will have to be
developed, but it is an interesting topic. Note that BPMN also allows such
patterns on a given task: an XOR-JOIN and an AND-SPLIT on the same task. Both
patterns are not supported by the current JWT-model natively (but the
transformation is quite obvious).
> 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.).
Right.
> 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.
Currently, the JWT model does not prohibit a Fork to have several incoming
transitions. The model does not enforce such constraints. Since this model is
supposed to be used by different editors, you must consider that the current
constraints in the JWT editors may not be enforced anymore.
> 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.
Right, this may be an option as those aspects may be relevant on a per-editor
basis.
> 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
Right.
> - 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)
Well, that may be an option, among others (see our next proposition by Marc
about FactoryRegistry for high extensibiliy probably posted by tomorrow).
> Do you think that it would be a problem to have these nodes (DecisionNode,
> MergeNode, ForkNode, JoinNode) again in aspect-based views?
Well I am not sure of anything! ;-) Neither that it would be a problem,
neither of the reverse. I have to get a clear picture of that aspect-based
view before saying anything! ;-)
> What are the
> thoughts from others concerning this topic?
Right. What are other opinions on that (important IMHO) topic?
> Are there other things in the metamodel that you think should be removed?
I don't see any currently. Again, we are not in a hurry for a removal of that
nodes. I am quite aware of the burden it will push on all current projects
that rely on the current JWT model. And of course, this "cost" problem is a
clear argument toward not changing the current JWT model. Its perfectly
understandable to me. On the other side, I just want to share my views on
that important topic since it seems to impact compatibility issues.
Therefore, the real questions are actually the following:
1. if we keep the current model, how to ensure compatibility between
JWT-based editors?
2. if we remove those nodes, how to help reducing the migration cost?
I don't have any reply currently.
And again, I may be completely wrong considering my new knowledge of JWT
technology. In this case, just sorry for all that burden! ;-)
[snip]
Regards.
--
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
