[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
AW: AW: AW: AW: [jwt-dev] About the JWT Model
|
Hi Marc, Hi all,
some great thoughts, alterations to the core metamodel are definitly steps
which should be carefully planned because of the vast impacts they tend to
have and aspects will help to 1. Keep the original metamodel clean of very
specific extensions and 2. allow very powerful additions to the core model.
Since I'm currently concerned with the redesign of the view system, my
requirements in this matter are at this point limited to restructuring the
information in the metamodel that is view-related. I'm hoping this won't
have too many sideeffects, since the visual information isn't used in
transformations anyway.
In the future, we're also going to need a new update mechanism until the
core model is definitely stable since the incompatible parts of the
workflows have to be updated each time a new version is released. I'm also
thinking whether we could provide an easy mechanism to plug in small
transformations (e.g. in ATL) which are executed each time a workflow is
opened or saved (maybe also for aspects, since aspect providers will
probably also release new versions of their definitions).
Regards,
Chris
> -----Ursprüngliche Nachricht-----
> Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx]
> Im Auftrag von Marc Dutoo
> Gesendet: Donnerstag, 11. Dezember 2008 12:21
> An: Java Workflow Toolbox
> Betreff: 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
> >
> _______________________________________________
> jwt-dev mailing list
> jwt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jwt-dev
