[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[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)