Jump to: navigation, search

Difference between revisions of "JWT Metamodel"

(Extending the JWT Metamodel)
 
(19 intermediate revisions by 2 users not shown)
Line 3: Line 3:
  
  
== Architecture ==
+
== Architecture and governance ==
 
The JWT metamodel comprises
 
The JWT metamodel comprises
 
* a core workflow metamodel that is as generic as possible
 
* a core workflow metamodel that is as generic as possible
Line 21: Line 21:
 
* 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.
 
* 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 governance ===
+
=== 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.
 
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
 
Metamodel Roadmap
* initial metamodel : JWT up to 0.5. This was originally AgilPro's metamodel.
+
* initial metamodel : JWT up to 0.5 . This was originally AgilPro's metamodel.
* core metamodel and aspect extensions : JWT 0.6 (upcoming). Includes core metamodel improvements and the new aspect extension mechanism.
+
* aspect extensions : JWT 0.6 . Includes core metamodel improvements and the new aspect extension mechanism.
* externalized metamodel : later. The metamodel will be in its own plugin.
+
* 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 ==
  
== Initial metamodel ==
+
As said in the Roadmap, the metamodel has since changed so the following is not up to date, but still mostly valid.
This document [[Image:AgilPro_MetamodelDescription.pdf]] describes the metamodel of AgilPro as it is today (2007-02-21). This document will be the basis for discussions on all working groups who have requirements on the meta-model.
+
  
 +
=== 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.
  
== JWT metamodel comparisons ==
+
=== Metamodel comparisons ===
  
=== Comparison with other metamodels ===
+
==== JWT Metamodel and XPDL 1.0 ====
A comparison with other meta-models as a result of an evaluation can be found in the following document: [[Image:EvaluationExistingMetamodels.pdf]].
+
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.
 
+
=== Metamodel and XPDL 1.0 ===
+
The document [[Image:AgilPro_Metamodel.pdf]] describes an initial revision of the document comparing the JWT/AgilPro metamodel with the XPDL 1.0 schema.
+
 
It covers all the XPDL elements as well as the Bonita engine vendor specific extensions.
 
It covers all the XPDL elements as well as the Bonita engine vendor specific extensions.
  
=== Metamodel and BPMN ===
+
==== JWT 0.5 Metamodel and BPMN ====
Please find under [[Image:Comparison_JWT_BPMN_v0_3.pdf]] a document describing the differences between the JWT Metamodel on the one hand and BPMN on the other.
+
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 Metamodel Extension Specifications]] ==
+
* [[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]]
+
* [[JWT Metamodel Extension Specifications/Technical Specifications v2|Technical specifications v2]] - See bugzilla https://bugs.eclipse.org/bugs/show_bug.cgi?id=241567 .
+
 
+
 
+
== Model extensions : how to use store custom information in (workflow) models using Conf, Profiles and Aspects ==
+
 
+
=== What it is for ===
+
JWT provides a mechanism allowing to store typed custom information in workflow models (actually, it works for any kind of EMF model). Profiles describe what kind of additional information can be stored on model elements. They can be provided by JWT integrators to let their users provide complex information needed by their custom features, or designed by end users to let them add information as simple as key-value properties.
+
 
+
=== Which plugins you need in your JWT installation (or workspace) ===
+
* jwt-we obviously as well as jwt-we-conf.we, which contains aspect integration in jwt-we
+
* conf (aspects) plugins : jwt-we-conf and .edit (or)
+
* if you plan to use "dynamic" Properties, their plugins : jwt-we-conf-property and .edit
+
* TEMPORARY 20081223 patch the jwt-we HEAD using the patch provided at https://bugs.eclipse.org/bugs/show_bug.cgi?id=241567
+
 
+
=== Enabling model extensions ===
+
To enable its custom Conf in your (workflow) model : if it is not already enabled for your xxx.workflow model, i.e. if it has no custom Conf already (xxx.workflow_conf file),
+
* start from a vanilla (workflow) model xxx.workflow and open it.
+
* open the ManageProfiles UI. One way is to select the corresponding editor sheet, or open it if it is not already by right click > Editor sheets > Manage Profiles. Another way could be : right click and select ExternalActions > ManageProfiles, which opens the ManageProfiles dialog.
+
* Since there is no conf yet, the ManageProfiles UI is empty and only permits to activate profiles by clicking on a button
+
* click on this button, which creates a related, empty conf file, named xxx.workflow_conf .
+
NB. this would also work for any kind of EMF model.
+
 
+
=== Using existing model extensions ===
+
To enrich your (workflow) model with custom information using Aspects from existing Profiles provided in your JWT installation,
+
* ensure the conf file is not in embeddedConf mode,
+
* then using the ManageProfiles dialog, select which profiles you want to activate for your (workflow) model
+
* then design your (workflow) model and enrich them with custom information stored in allowed aspects
+
** ex. creating aspects on nodes using right click on node > New Child > xxxaspect
+
** or merely creating new nodes which have automatically created aspects registered on it
+
** or using aspect-enriched views (like the "dynamic" Property PropertySheet tab, or the StaticAspect example PropertySheet tab)...
+
* NB. extensions information and configuration are stored in the *_conf file, which must be provided along with your (workflow) model file
+
  
=== Installing third-party model extensions ===
+
==== JWT 0.5 Metamodel and various others ====
To install third-party model extensions in your JWT installation,
+
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]].
* if they are provided as plugin(s), install them from their update-site or put their jars in the "plugins" directory of your JWT installation and restart
+
* if they are provided as autodiscovered _conf and .ecore (dynamic EMF case) files, put them in the "conf" autodiscovery directory and restart
+
  
=== Setting up simple additional model extensions ===
+
== Extending the JWT Metamodel ==
This can be done (without code nor EMF design) by designing and using "dynamic" Properties :
+
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.
* put the (workflow) model file in profile design mode (also called "embeddedConf" mode, by using the ManageProfile UI, or the PropertySheet on the ConfModel). This will allow the (workflow) model to directly use profiles available in its _conf file, and not only Profiles that are provided by the JWT installation.
+
* create your own custom Profile in the _conf file, ex. by right-click > New Child> Profile on the ConfModel in the outline. Give it a distinct name and URL.
+
* then start designing and testing new Property aspects in it :
+
** ex. define one (or more) aspect(s) on your Profile using right click on it > New Child > New Aspect
+
** then select jwt.we.conf.property.Property as its aspect instance type,
+
** also give it a unique id and select which model element type(s) it will be available on
+
** optionally, disable "autocreated" (so it will not be automatically created on any newly created node but will have to be created explicitly), enable "multiple" (so more than one can be created) or give it a default value (works only with primitive types for now)
+
* and when they are ok, export it using the ManageProfile UI to astandalone .conf file,
+
* which you'll register in a plugin or put in the "conf" autodiscovery directory of your JWT installation.
+
* Now you can put the ConfModel's "embeddedConf" property to false again, since your new profile is available among the installed ones.
+
* Therefore you can start using your custom designed model extensions in (workflow) models as shown previously.
+
* NB. as said, property information and configuration are stored in the *_conf file, which must be provided along with your (workflow) model file
+
  
=== For advanced users : designing complex additional model extensions without code ===
+
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 :
This can be done by designing and using "dynamic EMF" aspects, i.e. with EMF design but without code :
+
* '''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.
* design an EMF type extending jwt.we.conf.AspectInstance :
+
* '''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.  
** create a new EMF model file near your (workflow) model file by using the Eclipse New Ecore EMF model wizard
+
** in it, name its package as you want and create there a new EMF type
+
** in the sample EMF editor, right-click on it, choose "Load Resource..." and select among plugin resources jwt-we-conf-model's the ConfMetaModel.ecore
+
** so you can let your new type extend jwt.we.conf.AspectInstance using the Extend Type dialog
+
** design your custom model extension : add EMF attributes and references on your type, create other types or load them from other resources and refer to it...
+
* then set it up in a custom Profile :
+
** as above for setting up custom "dynamic" Properties, go in profile design mode, and in a custom Profile create a new Aspect
+
** in the sample EMF editor, right-click on it, choose "Load Resource..." and select among file resources your custom metamodel
+
** so you can let your aspect's instance type by the custom EMF type you've just designed
+
* NB. you must provide your custom EMF metamodel file (and possible additional loaded file models), along with the _conf file in the same directory as your workflow models.
+
  
=== For developers : developing complex additional model extensions using EMF-generated code ===
+
=== 1. "classical" EMF extension ===
This can be done by designing a custom EMF metamodel and generating its code to be used in Aspects :
+
* 1. define the EMF model
* use the Eclipse new EMF plugin project wizard to create a new project with an EMF model in it and its .genmodel companion file for configuring java code generation
+
* 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
* like above, design in this new EMF model your own type extending jwt.we.conf.AspectInstance
+
* 3. create a new FactoryRegistry and override the Palette (or create new Palette)
* open the companion .genmodel file and configure it accordingly, then use it to generate the model and .edit code, and optionally .editor code.
+
* 4. in Palette just add new model item ex. activityGroup.add(createCreationToolEntry(ModelPackage.Literals.TRANSPORT_OBJECT))
* then again, set it up in a custom Profile, like above, and export it to its own .conf file.
+
* Finally, register this .conf file in the project's plugin.xml using the jwt.we.conf extension point, along with the EMF model.
+
** NB. this solution of registering the conf file can also be used in the "dynamic" EMF case above, though it is too complex for it
+
  
 +
(courtesy of Kim Nguyen and a lot of others)
  
== For EMF-based tool developers : enriching a model with extensions ==
+
=== 2. JWT Metamodel EMF Aspects Extension ===
  
=== For EMF-based tool developers : Extension alternatives ===
+
==== Using JWT Metamodel Aspects Extension ====
If you're developing an EMF-based tool, there are three ways to add custom information to an EMF model :
+
[[JWT_Metamodel_Extension]] documents how to use store custom information in (workflow) models using Conf, Profiles and Aspects :
* 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.
+
* prerequisites : [[JWT_Metamodel_Extension#Using_aspect_model_extensions|Using aspect model extensions]]
* add instances of your own type to an openly typed reference (Any, EObject...). This is a good all-around solution but requires that such a reference exists in the model, and doesn't provide management of information coming from different third-party providers.
+
* [[JWT_Metamodel_Extension#Creating_custom_aspect_model_extensions|Creating custom aspect model extensions]]
* 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. 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.
+
** [[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]]
  
=== For EMF-based tool developers : allowing aspects (jwt-we-conf*) in your EMF model ===
+
==== (for JWT developers only) Design and development of Aspects metamodel extension feature ====
* put the aspects (jwt-we-conf*) plugins in your plugin Feature
+
* Development : See bugzilla https://bugs.eclipse.org/bugs/show_bug.cgi?id=241567
* let your model plugin depend from jwt-we-conf and the base classes of your EMF.edit's ItemProviders extend AspectsEnrichedBaseItemProvider rather than BaseItemProvider. This enables right-click > New Child > aspectxxx commands, as well as aspect behaviours (mainly autocreated aspects). Alternatively, you can write its code in your root generated class.
+
* Design : [[JWT Metamodel Extension Specifications]] describes the initial specifications of the aspects metamodel extension mechanism :
* that's it ! If you want, you can now also develop a custm Property Sheet tab for your aspect, or a view, an editor sheet...
+
** [[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 08:45, 20 August 2010

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 :

(for JWT developers only) Design and development of Aspects metamodel extension feature