Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "JWT Metamodel"

(→‎Metamodel Extension Prototype - working samples (added 20080527))
(→‎Extending the JWT Metamodel)
 
(25 intermediate revisions by the same user 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.
  
−
This page describes the discussions and requirements for the meta-model of JWT. Based on the existing meta-model of AgilPro we will summarize all wishes, extensions etc. on this page.
 
  
−
An important part is JWT metamodel's extensibility.
+
== 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.
  
−
== Initial metamodel ==
+
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.
  
−
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.
+
=== 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.
  
−
== JWT metamodel comparisons ==
+
* 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.
  
−
=== Comparison with other metamodels ===
+
=== Metamodel evolution ===
−
A comparison with other meta-models as a result of an evaluation can be found in the following document: [[Image:EvaluationExistingMetamodels.pdf]].
+
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.
  
−
=== Metamodel and XPDL 1.0 ===
+
== About JWT up to 0.5 and AgilPro metamodel ==
  
−
The document [[Image:AgilPro_Metamodel.pdf]] describes an initial revision of the document comparing the JWT/AgilPro metamodel with the XPDL 1.0 schema.
+
As said in the Roadmap, the metamodel has since changed so the following is not up to date, but still mostly valid.
−
It covers all the XPDL elements as well as the Bonita engine vendor specific extensions.
+
  
−
=== Metamodel and BPMN ===
+
=== 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.
  
−
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.
+
=== 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 Metamodel Extension Specifications]] ==
+
==== JWT 0.5 Metamodel and BPMN ====
−
* [[JWT Metamodel Extension Specifications]]
+
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/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)]] ==
+
−
 
+
−
=== Metamodel extensions and JWT WE - overview ===
+
−
Or : how should the JWT Workflow Editor behave in the case of metamodel extensions ?
+
−
 
+
−
Now that we've got a basic idea of how it could work at model level, let's focus on what is its first use : display and edition in JWT WE.
+
−
 
+
−
Let's remember JWT WE comprises the following display and edition capabilities :
+
−
* JWT GEF / EMF diagram
+
−
* JWT EMF outline
+
−
* JWT EMF property view
+
−
* aditionally, the JWT EMF property view could be enhanced by custom tabs
+
−
* aditionally, custom views could be made
+
−
 
+
−
As said before, we prioritize manipulating metamodel extensions in a generic (i.e. JWT outline and property view) or vendor specific view. It is enough and evacuates GEF diagram extension complexities. We will here focus on what JWT WE itself provides : the JWT outline and property views, and how it should best behave in the case of metamodel extensions.
+
−
 
+
−
NB. What is possible with extensions should be as much as possible specified in the ecore metamodel, since not only will it improve what features the generated EMF editors provide by default, but it will also prevent any illegal, non-conforming workflow model. However we obviously won't limit features to what EMF provides. So these needs could be additionally implemented through an additional behaviour metamodel, adapted or custom UI code or UI code generation - or even through ecore customization (see http://www.ibm.com/developerworks/opensource/library/os-eclipse-emfmetamodel/ ) though it would be hard to maintain and not agile enough.
+
−
 
+
−
=== Metamodel extensions and JWT WE behaviour ===
+
−
How do we want extensions / Aspects to behave in the Workflow Editor ?
+
−
 
+
−
==== functional needs ====
+
−
Based on the previous metamodel extension ideas, and on trying things with the above sample and others, I've listed the following functionalities, from "most required" to "nice to have" ones :
+
−
 
+
−
* "single" and / or "unique" : to limit instanciation of an aspect of a given type to at most one, or exactly one (i.e. pre-instanciated). Useful for all aspects that model "activable features".
+
−
* (optional) "undeletable" and / or "readonly" : to forbid deleting it (or require it to be instanciated again).
+
−
* "instanciation" : to require instanciation of an aspect or aspect list on a model element. This could be 1. a globally defined list, in JWT release configuration (or possibly user preferences ?) ; 2. a user-chosen list at model element instanciation time, by letting him chose an aspect list or a profile (aspect list)
+
−
* "aspect choice list" : restrain aspect instanciation to at most one of a given list of aspect: "single" and / or "unique" property on an abstract Aspect that is a common ancestor to all aspects of the list ; ex. at most one aspect specifying what "does" a given Action, by making all such Aspect types inherit from the same ApplicationAspectTemplate, which has its "single" property set to "true", or making this abstract aspect inherit from ListConstraintAspect ; cons : requires to introspect inheritance to know the list
+
−
* restrain an aspect type to be instanciated on model elements of a given type : using aspect subtypes, ex. ActionAspect, ModelAspect ; cons : complexifies aspect creation
+
−
* other custom rules required by the extension developer
+
−
 
+
−
==== technical solutions ====
+
−
* solution 1 : by configuring those features in "special" properties of Aspects, like "singleton", "removable". For example, EMF / XML uses such special properties (ex. "xmlns:prefix"). However, these properties configure how the behaviour of the Aspect type (how it is instanciated etc.), and not of each of the Aspect instances, and therefore are not at the appropriate conceptual level, which complexifies their understanding.
+
−
* solution 2 : modify ecore genmodel to store these information at the right conceptual level, and the EMF ecore JET templates to exploit them at generation time. However besides being difficult to do and maintain, it has not the level of flexibility we need : supporting new Aspect behaviours by adding new information there would be just as costly.
+
−
* solution 3 : using a custom "metametamodel", that would also be in line with future jwt-views management, like Christian Saad advocates. Developing it in EMF would the development of an editor, while still allowing to package it in different ways : standalone, in a plugin.xml extension, or even bundled within a .workflow.
+
−
* other custom rules required by the extension developer would however require coding : either by implementing them in their own custom view UI, or by modifying EMF-generated code or generation templates (EMF.edit's ItemProviders), or even palette ? policies ??
+
−
 
+
−
==== specifications ====
+
−
A gordian knot answer to these is to say that aspects can only be
+
−
* either "singleton", i.e. instanciated along with a model element,
+
−
* or "feature" (transversal, activable feature), that can be added or removed on its own ;
+
−
 
+
−
configure their behaviour in an additional metamodel comprising
+
−
* singleton or feature
+
−
* extension name and version
+
−
* their assigned model element
+
−
* Instanciating a model element with different singleton aspect sets can be made available using additional "newChild" commands
+
−
 
+
−
and to delegate as much of the complex requirements as possible to the aspect implementors :
+
−
* choice list is done within aspects
+
−
* as well as more complex features
+
−
 
+
−
=== Metamodel extensions and JWT Views ===
+
−
JWT Views are a way to customize how a Model is displayed. For now it is able to configure which model elements and subelements are displayed. Note that in the future, this functional perimeter may be extended / included in the issue of JWT configuration and packaging.
+
−
 
+
−
How do work JWT views :
+
−
* edited in swing application jwt-view, by using the above cited code, using the ecore with harcoded path "jwt-we/src/org/eclipse/jwt/we/model/WEMetaModel.ecore" (but if there's none, allows to choose it) ; AppWindow saves the view name in the plugin*.properties files of jwt-we
+
−
* handled in the org.eclipse.jwt.we.misc.views package of jwt-we : read by ViewResourceManager, Views, list of the read ecore's packages built by AnalyseEcore
+
−
 
+
−
Enabling metamodel extension at JWT views level (propositions) :
+
−
* basis (works !) : Making it visible in the (outline) UI ! How : in Views.displayObject(), display by default (opposite of current behaviour), so model objects that are not specified in the view will be displayed. This is good behaviour, because, all default model elements will be specified in the view, and it is still possible to specify not to display one by setting it to false (unchecking its checkbox in jwt-view).
+
−
* better : in jwt-view, allow to choose another ecore, many ecores, to merge their properties
+
−
* later : change jwt-view to an eclipse plugin with an eclipse UI, make it the bases of the jwt-configuration/packaging/release-builder plugin
+
−
 
+
−
=== Metamodel extensions and JWT WE - finding and loading models and ecores ===
+
−
About extension loading among the various files, EMF has nice out of the box features. An XMI file that refers relatively to an available ecore extension file will load as dynamic EMF. If XML rather than XMI is used, EMF can be configured so an XMI file that refers relatively to an available XSD extension file will load as EMF / XML (thanks to XSDEcoreBuilder). And EMF can be configured to load unknown extensions as XML without schema (concretely, the EObject implementation is AnyTypeImpl), though it is of little use since it is not typed. However this is not enough.
+
−
 
+
−
Requirements for finding and providing extension definition files
+
−
* the end user must be able to provide them in a simple way, like a standard directory whose ecores will be loaded at WE startup (csaad) ; and another way to add one from the editor UI, like a button "add extension model" allowing to choose an ecore file.
+
−
* vendors will want to be able to have a more built-in way to provide their ecore extensions, like a path in a plugin jar, if necessary referred to in their plugin.xml .
+
−
 
+
−
Technologies available to find extension definition files (typically metamodel extension file, and possibly an additional extension configuration file) , from the lighter to the deeper :
+
−
* files in an autodiscovery directory
+
−
* zipped files in a workflow bundle (zipped .workflow + extension definition files)
+
−
* EMF model element in a workflow model, as a subtree of the root Model element ; works for EMF or EMF / XML built extension definitions
+
−
* files specified in an extension point in plugin.xml
+
−
* XML inlined in an extension point in plugin.xml ; works for XML or EMF / XML (not static EMF ?) built extension definitions
+
−
* files found in a fixed path in the classpath (i.e. in a vendor's extension jar)
+
−
 
+
−
=== Metamodel extensions and JWT WE - versioning ===
+
−
Another issue is versioning (csaad)
+
−
* Extension versioning : it requires a naming and versioning mechanism for extensions (a list of which must be centrally stored in the model file, e.g. in the model-element) to ensure compatibility. See proposition of Christian Saad for custom typed properties.
+
−
* Note that Model is already versioned.
+
−
* Model update algorithm : it should be modified so it can make the difference between model version error and extension version error (including unknown extension). Note that it is for now limited to the "addition only" changes in the ecore, which is enough.
+
−
 
+
−
=== Metamodel extensions and JWT WE - tabbed properties view (Christian Saad) ===
+
−
The change of the properties view to a version that supports multiple tabs (as described in http://www.eclipse.org/articles/Article-Tabbed-Properties/tabbed_properties_view.html) is quite simple. The “old” properties can be loaded into the view using an adapter, so there is almost no additional effort to this solution (see attachment). Concerning the new dynamic properties, probably a similar approach can be used (write a propertypage that reads the dynamic properties from the itemproviders, creates the corresponding propertyeditors and can be fitted into the propertyview using the same kind of adapter).
+
−
 
+
−
== [[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]] ==
+
−
 
+
−
Building on all that has been said, here is my proposition.
+
−
 
+
−
Its strong points are
+
−
* it unifies the simple, static EMF DynamicProperties and the powerful, EMF-extensible Aspects solutions
+
−
* once the model has been defined, functionnalities can be added step by step, meaning it will be usable from day 1, and we can add other features (like using visibleOnChildren to impact the outline and property page UI behaviour, or loading externally defined profiles in JWT, or code handling extension versioning check) later, when we are sure of them and when we have time. I'll outline this here by "LATER".
+
−
 
+
−
It relies on two concepts :
+
−
* aspect (or dynamicproperty) : a single typed extension of a model element
+
−
* profile (or DynamicPropertyContainer, or ModelExtension) : a model extension made of a consistent collection of aspects
+
−
 
+
−
It has been filed in bugzilla as bug 241567 "Typed metamodel extensions (Aspects)" (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=241567 ).
+
−
 
+
−
 
+
−
=== Metamodel specification ===
+
−
 
+
−
ProfileDefModel metamodel
+
−
  * done in static EMF
+
−
  * contained in Model or / and independent XMI file, which could be the same as the new Views one
+
−
 
+
−
ProfileDefModel :
+
−
profiledefs : ProfileDef *
+
−
 
+
−
ProfileDef :
+
−
name
+
−
description
+
−
author
+
−
version
+
−
JWT version (modelversion ?)
+
−
aspectdefs : AspectDefs *
+
−
 
+
−
AspectDef :
+
−
id (jwt type) (string, reference ??)
+
−
etype (those extending Aspect are aspects, the others e.g. primitives or EObject are supported using Property) : EString
+
−
singleton : EBoolean
+
−
assignedto (? EClass but requires to refer to the ecore, or EString)
+
−
visibleAsChild : EBoolean
+
−
 
+
−
 
+
−
=== JWT metamodel ===
+
−
  * depends on the static ProfileDefs metamodel
+
−
 
+
−
Model
+
−
profiledefs : ProfileDefs
+
−
 
+
−
ModelElement :
+
−
aspects : Aspect *
+
−
 
+
−
Aspect :
+
−
id (jwt type)
+
−
 
+
−
Property extends Aspect :
+
−
value : EObject
+
−
 
+
−
 
+
−
=== Simple Property Example ===
+
−
 
+
−
Now an example of properties (csaad's) :
+
−
  * an instance of ProfileDef (name="Example1")
+
−
  * containing an AspectDef (name=id="internal_id1", etype="EString", assignedto="Action", singleton="true")
+
−
  * and another AspectDef (name=id="internal_id2", etype="EInteger", assignedto="ActivityNode", singleton="true")
+
−
 
+
−
Which automatically creates property instances under said model elements, for example :
+
−
  * an instance of JoinNode (name="node1") containing an instance of Property (name=id="internal_id2", value="intvalue1")
+
−
  * an instance of ActionNode (name="node1") containing an instance of Property (name=id="internal_id2", value="intvalue2") and another instance of Property (name=id="internal_id1", value="stringvalue1")
+
−
 
+
−
 
+
−
=== Extended Model Example ===
+
−
Now an example of an extended model :
+
−
  * an instance of ProfileDef (name="BonitaProfile")
+
−
  * containing an AspectDef (name=id="BonitaTaskAspectDef", etype="BonitaTaskAspect", assignedto="Action", singleton="false")
+
−
  * which makes BonitaTaskAspect available to be created under Action,
+
−
  * BonitaTaskAspect being defined as such :
+
−
 
+
−
BonitaTaskAspect :
+
−
bonitahooks : BonitaHook*
+
−
 
+
−
BonitaHook
+
−
event : EString (listbox)
+
−
javaClass : EString
+
−
jar : EString
+
−
 
+
−
 
+
−
=== Original DynamicProperty Metamodel ===
+
−
Note : csaad's was :
+
−
 
+
−
ModelElement :
+
−
properties *
+
−
 
+
−
DynamicPropertyContainer :
+
−
name
+
−
description
+
−
author
+
−
version
+
−
JWT version
+
−
dynamicproperties *
+
−
 
+
−
DynamicProperty :
+
−
id
+
−
type (of value ?)
+
−
assignedto
+
−
visibleOnChildren (?)
+
−
 
+
  
−
=== Features ===
+
==== JWT 0.5 Metamodel and various others ====
−
Localization :
+
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]].
−
  * Names displayed in the UI (such as those of Property instances) have to be localized. It should be done in the Eclipse manner, using bundles, and if necessary a bit of our code. However I don't think we should put localized names in the model.
+
  
−
Managing the model :
+
== Extending the JWT Metamodel ==
−
  * Configuration : Which profiles among the ones loaded in JWT are activated in a given workflow model ?
+
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.
−
      * all those explicitly defined in this workflow model,
+
−
      * LATER and all those in files configured in plugin.xml .
+
−
      * LATER buttons allowing to save a workflow containg all profile definitions (including JWT configured ones)
+
−
  * Versioning :
+
−
      * updating existing version check code so it works with the new model
+
−
      * updating existing version check code so it works with the extended EMF metamodels
+
−
      * LATER adding profile versioning check
+
  
−
UI
+
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 :
−
  * LATER Property / Outline : according to visibleAsChild, Aspect instances's content (including Property instances' content) will be either shown as a subelement of their assigned model element instance, or merged in the assigned model element instance's property page. Proposition : this property page's layout could separate each Aspect content by bars.
+
* '''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.
−
  * LATER in the outline, commands for creating "not singleton" aspects ; and forbidding deletion of "singleton ones".
+
* '''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.  
−
  * LATER in the outline, finer extensibility of the "new Child" commands, including allowing to configure in plugin.xml commands that create a type with a given set of aspects.
+
−
  * LATER Diagram : nothing
+
  
−
Transformation
+
=== 1. "classical" EMF extension ===
−
  * LATER define an extension point on transformation allowing to specify additional transformation rules for a given profile (not sure of this one, typed profiles sure are nice for this, but has to be tried first).
+
* 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))
  
−
Packaging
+
(courtesy of Kim Nguyen and a lot of others)
−
  * LATER Using EMF.Edit, create a simple editor for the ProfileDefModel metamodel and make it available in the jwt packaging tool
+
  
−
Finding and loading extension
+
=== 2. JWT Metamodel EMF Aspects Extension ===
−
  * LATER static EMF extension models can be configured in plugin.xml to be loaded
+
−
  * LATER dynamic EMF extension ecores can be provided in given directory to be loaded
+
  
 +
==== 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

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

Retrieved from "https://wiki.eclipse.org/index.php?title=JWT_Metamodel&oldid=216322"

This page was last modified 09:45, 20 August 2010 by Eclipsepedia anonymous user Unnamed Poltroon.

Back to the top