Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "JWT Metamodel"
(→Metamodel extensions and JWT WE (added 20080527)) |
(→Extending the JWT Metamodel) |
||
| (24 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
== Introduction == | == Introduction == | ||
| + | This page describes the architecture, requirements and discussions for the meta-model of JWT. Starting from the original meta-model of AgilPro, it summarizes all evolutions, extensions, wishes etc. | ||
| − | |||
| − | + | == Architecture and governance == | |
| + | The JWT metamodel comprises | ||
| + | * a core workflow metamodel that is as generic as possible | ||
| + | * extensions that allow to provide specific additional features | ||
| + | * overall governance that allows extensions to coexist within the JWT ecosystem. | ||
| + | === Core metamodel === | ||
| + | Its aim is to be a workflow metamodel that is as generic as possible. | ||
| − | + | Changes to the core metamodel should rather go in metamodel extensions, because they affect possibly all JWT users and must therefore be considered very carefully. | |
| − | + | === Metamodel extensions === | |
| + | Metamodel extensions allow to provide specific additional features, be it UI like JWT views, runtime like a WebServiceApplication or other features like logging. | ||
| − | + | * Official JWT metamodel extensions : an official JWT metamodel extension is the standard for its domain model. To make your metamodel extension official, there must be none yet for its domain model, it must be approved by project leads and listed in [[JWT Metamodel Extensions/Official]] | |
| + | * JWT Labelized metamodel extensions : if there is already an official JWT extension for your domain model, you can make it JWT labelized by implementing a two-way transformation to an existing official or labelized metamodel extension along with its transformation documentation and test kit, make it approved by project leads and list it in [[JWT Metamodel Extensions/Labelized]] | ||
| + | * extensions can obviously still be developed by anyone without being official or labelized, though their users can't be sure they'll be able to freely benefit from other parts of the JWT ecosystem, because of possible domain model specific incompatibility. | ||
| − | === | + | === Metamodel evolution === |
| − | + | In order to become better and answer more user requirements, the JWT metamodel evolves. In order to avoid conflicts and compatibility problems, it does so in a governed manner, and with the help of tools such as an automated version converter. | |
| + | Metamodel Roadmap | ||
| + | * initial metamodel : JWT up to 0.5 . This was originally AgilPro's metamodel. | ||
| + | * aspect extensions : JWT 0.6 . Includes core metamodel improvements and the new aspect extension mechanism. | ||
| + | * externalized metamodel : JWT 0.7 The metamodel will be in its own plugin. | ||
| + | * small improvements are expected for the next version. | ||
| − | == | + | == About JWT up to 0.5 and AgilPro metamodel == |
| − | + | As said in the Roadmap, the metamodel has since changed so the following is not up to date, but still mostly valid. | |
| − | + | ||
| − | === | + | === Design === |
| + | This document [[Image:AgilPro_MetamodelDescription.pdf]] describes the metamodel of AgilPro as it was of 2007-02-21. This document has been the basis for discussions on all working groups who have requirements on the meta-model. | ||
| − | + | === Metamodel comparisons === | |
| + | ==== JWT Metamodel and XPDL 1.0 ==== | ||
| + | The document [[Image:AgilPro_Metamodel.pdf]] describes an initial revision of the document comparing the JWT 0.5/AgilPro metamodel with the XPDL 1.0 schema. | ||
| + | It covers all the XPDL elements as well as the Bonita engine vendor specific extensions. | ||
| − | == | + | ==== JWT 0.5 Metamodel and BPMN ==== |
| − | + | The document [[Image:Comparison_JWT_BPMN_v0_3.pdf]] describes the differences between the JWT 0.5 Metamodel on the one hand and BPMN on the other. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | === | + | ==== JWT 0.5 Metamodel and various others ==== |
| − | + | A comparison with other meta-models (including BPM Guide's Simple BPM, BPDM, AgilPro, UML Activity Diagram, Event-driven Process Chains, List/Korherr's metamodel) as a result of an evaluation can be found in the following document: [[Image:EvaluationExistingMetamodels.pdf]]. | |
| − | + | ||
| − | + | == Extending the JWT Metamodel == | |
| − | + | Extending the JWT Metamodel is necessary as soon as you need to enrich your model with custom information, for example information that is specific to your business or to your runtime execution platform. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | JWT's Metamodel is based on EMF, for which there are several ways to add custom information, that are analyzed at [[JWT_Metamodel_Extension#EMF_model_extension_alternatives]] . Two ways are available out of the box in JWT : | |
| − | + | * '''1. "classical" EMF extension''' : extend an existing type of the model with your own type. This is only interesting to create well identified subtypes, i.e. that could have been provided in the base model beforehand. If it is the case, please consider contributing it to JWT's core metamodel. | |
| − | + | * '''2. EMF Aspects extension''' : manage instances of your own types in another model that let them refer to the main model's elements. This non-intrusive solution works with any model without prerequisite and allows to share type extensions between model types. In JWT, Aspects do this in a simple, typed way that allows for having custom-information coming from different third-party providers, while the genmodel file is a more complex example. | |
| − | + | ||
| − | + | ||
| − | + | === 1. "classical" EMF extension === | |
| − | + | * 1. define the EMF model | |
| + | * 2. To enable EMF child extenders, extensibleProviderFactory="true" has to be set on the genModel package of the EMF class you want to extend, and on your side you have to set childCreationExtenders="true" on the genModel package of your extending EMF class. See an example in jwt-we-plugins/jwt-we-sample-aspectchildextenders and Ed Merks' blog at http://ed-merks.blogspot.com/2008/01/creating-children-you-didnt-know.html | ||
| + | * 3. create a new FactoryRegistry and override the Palette (or create new Palette) | ||
| + | * 4. in Palette just add new model item ex. activityGroup.add(createCreationToolEntry(ModelPackage.Literals.TRANSPORT_OBJECT)) | ||
| − | + | (courtesy of Kim Nguyen and a lot of others) | |
| − | + | ||
| − | + | === 2. JWT Metamodel EMF Aspects Extension === | |
| − | + | ||
| − | + | ||
| + | ==== Using JWT Metamodel Aspects Extension ==== | ||
| + | [[JWT_Metamodel_Extension]] documents how to use store custom information in (workflow) models using Conf, Profiles and Aspects : | ||
| + | * prerequisites : [[JWT_Metamodel_Extension#Using_aspect_model_extensions|Using aspect model extensions]] | ||
| + | * [[JWT_Metamodel_Extension#Creating_custom_aspect_model_extensions|Creating custom aspect model extensions]] | ||
| + | ** [[JWT_Metamodel_Extension#Setting_up_simple_.28key-value.29_additional_model_extensions|Setting up simple (key-value) additional model extensions]] thanks to the jwt-we-conf-property official JWT metamodel extension | ||
| + | ** [[JWT_Metamodel_Extension#For_advanced_users_:_designing_complex_additional_model_extensions_without_code|For advanced users : designing complex additional model extensions without code]] | ||
| + | ** [[JWT_Metamodel_Extension#For_developers_:_developing_complex_additional_model_extensions_using_EMF-generated_code|For developers : developing complex additional model extensions using EMF-generated code]] | ||
| + | * For other EMF-based tool developers: [[JWT_Metamodel_Extension#For_other_EMF-based_tool_developers_:_enriching_a_model_with_extensions|allowing aspect extensions in an EMF model]] | ||
| + | * [[JWT_Metamodel_Extension#Aspect_model_extension_samples|Summary of all Aspect model extension samples]] | ||
| − | == [[JWT Metamodel Extension Specifications/Technical Specifications v2|Technical specifications v2]] | + | ==== (for JWT developers only) Design and development of Aspects metamodel extension feature ==== |
| − | See bugzilla https://bugs.eclipse.org/bugs/show_bug.cgi?id=241567 . | + | * Development : See bugzilla https://bugs.eclipse.org/bugs/show_bug.cgi?id=241567 |
| + | * Design : [[JWT Metamodel Extension Specifications]] describes the initial specifications of the aspects metamodel extension mechanism : | ||
| + | ** [[JWT Metamodel Extension Specifications/Requirements|Extension Requirements and Use Cases]] | ||
| + | ** [[JWT Metamodel Extension Specifications/Alternatives Study|Specification Alternatives Study]] | ||
| + | ** [[JWT Metamodel Extension Specifications/Prototype|Metamodel Extension Prototype]] - working samples (added 20080527) | ||
| + | ** [[JWT Metamodel Extension Specifications/WE|Metamodel extensions and JWT WE (added 20080527)]] | ||
| + | ** [[JWT Metamodel Extension Specifications/Transformations|Metamodel extensions and JWT Transformations]] - TODO | ||
| + | ** [[JWT Metamodel Extension Specifications/Runtime|Metamodel extensions and JWT Runtimes]] - TODO | ||
| + | ** [[JWT Metamodel Extension Specifications/Technical Specifications v1|Technical specifications v1]] (obsolete) | ||
| + | ** [[JWT Metamodel Extension Specifications/Technical Specifications v2|Technical specifications v2]] - See bugzilla https://bugs.eclipse.org/bugs/show_bug.cgi?id=241567 . | ||
Latest revision as of 09:45, 20 August 2010
Contents
Introduction
This page describes the architecture, requirements and discussions for the meta-model of JWT. Starting from the original meta-model of AgilPro, it summarizes all evolutions, extensions, wishes etc.
Architecture and governance
The JWT metamodel comprises
- a core workflow metamodel that is as generic as possible
- extensions that allow to provide specific additional features
- overall governance that allows extensions to coexist within the JWT ecosystem.
Core metamodel
Its aim is to be a workflow metamodel that is as generic as possible.
Changes to the core metamodel should rather go in metamodel extensions, because they affect possibly all JWT users and must therefore be considered very carefully.
Metamodel extensions
Metamodel extensions allow to provide specific additional features, be it UI like JWT views, runtime like a WebServiceApplication or other features like logging.
- Official JWT metamodel extensions : an official JWT metamodel extension is the standard for its domain model. To make your metamodel extension official, there must be none yet for its domain model, it must be approved by project leads and listed in JWT Metamodel Extensions/Official
- JWT Labelized metamodel extensions : if there is already an official JWT extension for your domain model, you can make it JWT labelized by implementing a two-way transformation to an existing official or labelized metamodel extension along with its transformation documentation and test kit, make it approved by project leads and list it in JWT Metamodel Extensions/Labelized
- extensions can obviously still be developed by anyone without being official or labelized, though their users can't be sure they'll be able to freely benefit from other parts of the JWT ecosystem, because of possible domain model specific incompatibility.
Metamodel evolution
In order to become better and answer more user requirements, the JWT metamodel evolves. In order to avoid conflicts and compatibility problems, it does so in a governed manner, and with the help of tools such as an automated version converter.
Metamodel Roadmap
- initial metamodel : JWT up to 0.5 . This was originally AgilPro's metamodel.
- aspect extensions : JWT 0.6 . Includes core metamodel improvements and the new aspect extension mechanism.
- externalized metamodel : JWT 0.7 The metamodel will be in its own plugin.
- small improvements are expected for the next version.
About JWT up to 0.5 and AgilPro metamodel
As said in the Roadmap, the metamodel has since changed so the following is not up to date, but still mostly valid.
Design
This document File:AgilPro MetamodelDescription.pdf describes the metamodel of AgilPro as it was of 2007-02-21. This document has been the basis for discussions on all working groups who have requirements on the meta-model.
Metamodel comparisons
JWT Metamodel and XPDL 1.0
The document File:AgilPro Metamodel.pdf describes an initial revision of the document comparing the JWT 0.5/AgilPro metamodel with the XPDL 1.0 schema. It covers all the XPDL elements as well as the Bonita engine vendor specific extensions.
JWT 0.5 Metamodel and BPMN
The document File:Comparison JWT BPMN v0 3.pdf describes the differences between the JWT 0.5 Metamodel on the one hand and BPMN on the other.
JWT 0.5 Metamodel and various others
A comparison with other meta-models (including BPM Guide's Simple BPM, BPDM, AgilPro, UML Activity Diagram, Event-driven Process Chains, List/Korherr's metamodel) as a result of an evaluation can be found in the following document: File:EvaluationExistingMetamodels.pdf.
Extending the JWT Metamodel
Extending the JWT Metamodel is necessary as soon as you need to enrich your model with custom information, for example information that is specific to your business or to your runtime execution platform.
JWT's Metamodel is based on EMF, for which there are several ways to add custom information, that are analyzed at JWT_Metamodel_Extension#EMF_model_extension_alternatives . Two ways are available out of the box in JWT :
- 1. "classical" EMF extension : extend an existing type of the model with your own type. This is only interesting to create well identified subtypes, i.e. that could have been provided in the base model beforehand. If it is the case, please consider contributing it to JWT's core metamodel.
- 2. EMF Aspects extension : manage instances of your own types in another model that let them refer to the main model's elements. This non-intrusive solution works with any model without prerequisite and allows to share type extensions between model types. In JWT, Aspects do this in a simple, typed way that allows for having custom-information coming from different third-party providers, while the genmodel file is a more complex example.
1. "classical" EMF extension
- 1. define the EMF model
- 2. To enable EMF child extenders, extensibleProviderFactory="true" has to be set on the genModel package of the EMF class you want to extend, and on your side you have to set childCreationExtenders="true" on the genModel package of your extending EMF class. See an example in jwt-we-plugins/jwt-we-sample-aspectchildextenders and Ed Merks' blog at http://ed-merks.blogspot.com/2008/01/creating-children-you-didnt-know.html
- 3. create a new FactoryRegistry and override the Palette (or create new Palette)
- 4. in Palette just add new model item ex. activityGroup.add(createCreationToolEntry(ModelPackage.Literals.TRANSPORT_OBJECT))
(courtesy of Kim Nguyen and a lot of others)
2. JWT Metamodel EMF Aspects Extension
Using JWT Metamodel Aspects Extension
JWT_Metamodel_Extension documents how to use store custom information in (workflow) models using Conf, Profiles and Aspects :
- prerequisites : Using aspect model extensions
- Creating custom aspect model extensions
- Setting up simple (key-value) additional model extensions thanks to the jwt-we-conf-property official JWT metamodel extension
- For advanced users : designing complex additional model extensions without code
- For developers : developing complex additional model extensions using EMF-generated code
- For other EMF-based tool developers: allowing aspect extensions in an EMF model
- Summary of all Aspect model extension samples
(for JWT developers only) Design and development of Aspects metamodel extension feature
- Development : See bugzilla https://bugs.eclipse.org/bugs/show_bug.cgi?id=241567
- Design : JWT Metamodel Extension Specifications describes the initial specifications of the aspects metamodel extension mechanism :
- Extension Requirements and Use Cases
- Specification Alternatives Study
- Metamodel Extension Prototype - working samples (added 20080527)
- Metamodel extensions and JWT WE (added 20080527)
- Metamodel extensions and JWT Transformations - TODO
- Metamodel extensions and JWT Runtimes - TODO
- Technical specifications v1 (obsolete)
- Technical specifications v2 - See bugzilla https://bugs.eclipse.org/bugs/show_bug.cgi?id=241567 .