[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: AW: AW: AW: [jwt-dev] About the JWT Model
|
Hi all
Pierre, Florian, Christian, thanks for your valuable contributions to
this discussion.
Here are the conclusions we've come to when I called you guys on the phone.
The long term goal is to have tools as flexible as possible so
integrators can build on it to answer a large panel of user needs, but
without conflicting with each other (ex. same metamodel information used
in two different ways) nor being incompatible (that would be shooting
oneself in the foot).
Obviously, the metamodel is at the heart of these issues, but there are
a lot of other issues that stem from it, like constraints (be it model
OCL or external validation), execution & engine features, and even
Workflow editor UI actions. When we take the global vision at the
metamodel level, we see that its purpose is to let users have different
specific information thanks to different extensions of the core
metamodel. In order not to have conflicts nor stray too far from the
core metamodel, there is the aspect (jwt-we-conf-model) technology that
allow to decorate the core model in a non-intrusive, typed manner. In
order not being incompatible, we have the transformations technology
that allow to build bridge from one use of the metamodel to another,
compatible one. However that is not enough : we also have to identify
these different uses of the metamodel, and measure their distance to the
"reference metamodel", and manage and publish this information in the
tools, documentation (wiki) and JWT project management.
So what is the reference metamodel ? It's the Workflow Editor's model,
not only as it is now but also as we envision it to evolve. Note that
these evolutions are meant to happen, we now we have to refactor it
progressively, in order to make it more generic, more simple and
therefore more easily extensible. Not that "ours is better" (though
hopefully it's a good one), but it's the main model in use in JWT, and
more importantly its evolutions and its extensions are managed by the
JWT community - "managed" meaning again that they are tracked, agreed
on, published, tooled. And not only are its alternate versions tracked
and must they provide transformations to the reference one, its
extensions are tracked also, and when several implement the same feature
using different metamodel extensions but with the same meaning, they
must work within the JWT community on merging together at the metamodel
level, or agree on one being the reference one and the other being an
alternate version and providing a transformation to the first. Aspects
are metamodel extension and have to be tracked, and it's better to do it
at the level of their Profiles. Ideally, dynamic Properties would also
have to be tracked, but since they are intended for the end user, it's
more logical to leave them unmanaged anyway. On another side, most needs
will rather be new features, so they won't need a different ID nor a
transformation, but only to publish their extended metadata on the JWT
wiki page that tracks metamodel versions and extensions.
So when somebody comes to JWT and says "I'd like to use your tools, but
my users need a different metamodel", we can't say "you're wrong"
because he (hopefully) knows his users and their requirements are valid.
Nor will we say "you can't", because we may be flexible enough. We will
rather say, "you can answer your needs using our tools, but your
metamodel is that far from the JWT reference one, and you'll have to
develop metamodel extensions ; and if they differ from the reference
one, also in order to be labelled as a good JWT citizen : a metamodel ID
that identifies it as different from the reference one, and a (partial)
transformation that makes both compatible". Obviously, if this cost is
too high from developing an entirely different metamodel and providing a
full fledged transformation, using the existing JWT tools is not the
right way to go (ex. for now, BPEL metamodels would be very hard to do
with the JWT Workflow Editor), and developing other tools would rather
be the way to go, and they would be welcome in JWT as well.
I'll open a bugzilla on the topic of "Tracking and making compatible
metamodel extensions and alternate versions", whose output will be a
wiki page, a methodology on what good JWT citizen must do at this level
and how to use JWT technologies to achieve it (aspecially aspects and
profiles), but dedicated tooling as well :
* something like a metamodel ID and two-way transformations to the
reference metamodel : as a preference or extension point or aspect. A
metamodel ID and transformations is only required when a metamodel or
its extensions differ from the reference one.
* identity transformations & sample transformations, as a quickstart
* optional ideas : a vendor-targeted "New metamodel extension" wizard
that will streamline the whole process of not only creating the
metamodel extension, but also if required an id and stub transformations
; a mechanism to associate transformation fragments to metamodel
extensions and assemble them automatically in the required
transformations to the reference model, using technologies like ATL or
model synchronization / reconciliation...
So how it translates to the problem at hand (Control Nodes) :
* since Pierre's solution (And and Or nodes) is simpler and everyone
agrees with it, it goes in the reference metamodel now.
* old Fork et al. control nodes are made obsolete now and tracked as
such on the metamodel wiki page. Users and developers are meant to use
the new nodes, or face what comes next.
* The old, obsolete nodes will be removed at some point (not in a
hurry), and go in a metamodel extension with an alternate ID and two-way
transformations, and be tracked in the metamodel wiki page. Note that
this will also allow backaward compatibility.
Feedback welcome, especially if you have ideas on how to achieve
extensibility + compatibility in the JWT metamodel in an easier manner !
Regards,
Marc
Christian Saad a écrit :
Hi Pierre,
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).
The constraints are actually in the model (the upper and lower bound of the
relationships) but not enforced by EMF. These constraints could be made to
work from the model level, either by putting OCL constraints on the model,
or reading the lower/upper bound from the EClasses in the EditParts using
reflection. However, I think there may be a problem with the generalization
hierarchy, since if the parent node allows an arbitrary number of
connections, the child will probably not be able to put restrictions on the
inherited relationship (but maybe I'm wrong here).
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.
You are right, it is important that this will be supported. The basic
question is: How can we integrate both options in a way that not only works,
but also makes sense ;)
One obvious (but ugly) solution would be to put AND, FORK, JOIN as childs of
ControlNode and activate/deactivate AND or FORK/JOIN using views.
Regards,
Chris
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev
