[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
AW: [jwt-dev] Notes of JWT Meeting at Linux Solutions 20080130 - about model exensibility, STP IM runtime
|
Hi all,
thank you Marc for your notes about the last JWT meeting. I do hope that
some of us can follow up this discussion at EclipseCon in March.
Yes, there should be some way to transport further information in the model,
e.g. using EAnnotations or any other mechanism. If somebody has any ideas
how to implement this in a nice way, please don't hesitate to do so ;-) or
let me know about it. I think for the moment only elements in contact with
deployment time should be extensible, I don't see that all elements should
be extended right now (too much work for no use).
I'm looking forward to any suggestions how the metamodel shall be extended
which we will target for release 0.5.0 then.
Today (in about half an hour) will be the release review for version 0.4.0.
Keep your fingers crossed that our first release will be approved ;-)
Best regards,
Florian
-----Ursprüngliche Nachricht-----
Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im
Auftrag von Marc Dutoo
Gesendet: 19 February 2008 14:59
An: Java Workflow Toolbox
Betreff: [jwt-dev] Notes of JWT Meeting at Linux Solutions 20080130 - about
model exensibility, STP IM runtime
Hi all
Thanks for everyone that attended this meeting. Some very interesting ideas
here, notably about model exensibility, STP IM runtime !
Still trying to put words on all ideas, some of them are spot on considering
our (at Open Wide's) current work. I really believe for instance that
PVM-like custom typed nodes are a smart solution for model extensibility,
and that there's a need for what STP IM runtime expresses.
Comments are obviously welcome !
* meeting JWT mer 30/01 Linux Solutions
* with later comments from Florian Lautenbacher and Marc Dutoo
---++ participants
* Adrian Moss (OW2 INRIA)
* Koen Aers (jBoss, jBPM editor)
* Stéphane Drapeau (Obeo)
* Marc Dutoo (Open Wide)
* Goulven Le Jeune (Bull)
NB. Miguel Valdes could not be there (sick alas)
---++ Model extensibility :
Koen Aers had the idea that JWT was "like the PVM, but for the BP editor",
meaning :
as in PVM metamodel,
* should be able to add typed nodes,
* and use profiles to keep control on the set of authorized types
Why this is interesting for JWT :
* extending the JWT model (and further, its ability to be extended) has
been discussed before. Since the original proposal, it has been the object
of discussion witin the Metamodel Workgroup.
* its object : holding additional information that is specific to a
standard or (more usually) a runtime platform, ex. deployment information or
even a way of storing an SOA service call that would be better than an
Application whose class is "SCAServiceApplication"
requires input Data providing its service name and operation.
Concretely, there is an increasing need in extensibility the closer we go to
deployment time and the target platform / Information System.
* Moreover, during BPMN - JWT transformation spec and impl, we've talked
about how STP BPMN Ed.'s EAnnotations are of practical use to store
additional information, and how a similar simple thing might be useful in
the JWT model.
* PVM-like custom typed nodes and profiles is another extensibility
solution. It has the benefit of being strong typed and as such might
comparatively fit better in JWT (see "at is STP-IM, compared to JWT" below).
Which part of the model would need to be extended / extensible ?
* all of it ? ex. STP BPMN Ed with EAnnotations, or STP IM with
properties
* only elements in contact with deployment time / the target platform &
SI or SOA ? This seems to be the most pressing need, PVM-like custom typed
nodes may come in handy.
---++ how all that (JWT) works :
1. business editor : "visio-like", only purpose is notation or
representation, ex. BPMN
2. from there, using generation technology ex. as in MDA approach, we go to
the (a) pivotal metamodel and its open editor JWT. Concretely :
* Who can do the most can do less : "JWT to BPMN enriched with additional
annotated information (using STP ed. EAnnotations)" is far easier to do and
gives a spec for an opposite "enriched BPMN to JWT" to will be bijective.
* NB. BPMN - JWT bijection is not useful in itself, but allows
* to try for real the idea of editing an executable model in BPMN
(i.e. concept of editing in the same tool the representation and its mapped
executable definition, i.e. what had been thought about in august
2008 at the Bull - Open Wide JWT meeting),
* and to have a concrete idea of "completeness" of JWT models that
have been generated from a BPMN representation (otherwise there is no way of
knowing whether a model is complete or not, besides automatic validation
that we're not using for now). Another way to say it : it's like generating
Java code from UML in MDA top-down approach, where the generated code is not
"final / complete", meaning the developer has still to code additional
custom business behaviour in it, but it is indeed "correct", meaning it
compiles and might (should) work
3. from there to runnable process(es) ex.BPEL / Nova Orchestra, XPDL / Nova
Orchestra, XPDL / other ex. shark...
* see STP IM runtime ideas below for this part
---++ What is STP-IM, compared to JWT
STP-IM : carrier of properties between editors
To be compared to JWT: guardian of unicity and loose coupling (pivotal)
---++ What is STP-IM runtime and interest of concept for JWT
STP-IM runtime : describes which services may be chosen when using a
dedicated
editor
* we may need at some point something like that in JWT, typically for
the whole platform-specific features and information part : this way the
WE will be able to know and let the user graphically edit them.
* NB. this might be achieved with the previous idea of custom typed
nodes gathered in profiles (one profile per platform)
also in JWT and with SCA, STP-IM : unify "service" vision of integrated
runnable applications
* ex. choix service sémantique
---++ format / model interoperability
* various technologies for model transformations (for now ATL, XSL ;
why not Acceleo, JET, mere Java...)
* various validation methods (including mere human-driven ones, or
unit testing vs BP samples ; up to validation framework ex. EMF's or
Open Architecture Ware's)
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev
