Skip to main content

[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


Back to the top