Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "JWT Metamodel"

(→‎Extending the JWT Metamodel)
 
(92 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.
  
−
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.
  
 +
* 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.
  
−
== JWT metamodel comparisons ==
+
=== 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.
  
−
=== Comparison with other metamodels ===
+
Metamodel Roadmap
−
A comparison with other meta-models as a result of an evaluation can be found in the following document: [[Image:EvaluationExistingMetamodels.pdf]].
+
* 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 ==
  
−
=== Metamodel and XPDL 1.0 ===
+
As said in the Roadmap, the metamodel has since changed so the following is not up to date, but still mostly valid.
  
−
The document [[Image:AgilPro_Metamodel.pdf]] describes an initial revision of the document comparing the JWT/AgilPro metamodel with the XPDL 1.0 schema.
+
=== Design ===
−
It covers all the XPDL elements as well as the Bonita engine vendor specific extensions.
+
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 and BPMN ===
+
=== Metamodel comparisons ===
  
−
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.
+
==== 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.
−
== Requirements ==
+
−
 
+
−
=== Sources and contributors ===
+
−
 
+
−
=== List of requirements ===
+
−
* BPMN2JWT transformation (SCOrWare project) : being able to store BPMN information that can't be mapped to JWT. This allows then to manipulate this information in JWT, but also to provide a perfectly bijective JWT2BPMN reverse transformation (notional "pivotal" metamodels)
+
−
* Bonita v4 XPDL "hook" support (Bull) : Hooks (as well as other Action-level features) should be stored in a Bonita specific metamodel extension. This extension should be typed so Bonita-specific UI extensions would know which metamodel extension they have to manage.
+
−
* Service (WebService, SCA) call support (SCOrWare project) : requires to store and manage information pertaining to these specific Actions or Action extensions.
+
−
* Custom Action support (Bryan Hunt, MWE) : JWT users should be able to define custom Actions with custom metamodels, that might be exploited at runtime. Marc : I link this with the "black box Action" point of view, where Actions are merely linked blank "do something" slates that users implement at will.
+
−
* Imixs.org specific Action features support (Ralph Soika, Imixs.org) : imixs.org features depend on numerous Action-level properties that should be stored and accessible in JWT metamodel.
+
−
 
+
−
 
+
−
 
+
−
== JWT metamodel extension ==
+
−
 
+
−
=== Goals of JWT metamodel extension (consolidated) ===
+
−
* allow JWT metamodel to be extended
+
−
* 1. for JWT developers (ex. allow complex metadata, using static EMF for performances)
+
−
* 2. for users : as easily as possible (ex. without writing java code, using dynamic EMF or XSD for ease of use, using simple concepts ex. a property map)
+
−
* in multiple orthgonal ways (ex. "typed" extensions), so different extensions with different aims and features can coexist, and each of them can be easily found and distinguished by their management code and business logic
+
−
* 3. IN A SECOND TIME (more complex, several consequences, see further) provide ways to manage consistency of all typed extensions
+
−
 
+
−
=== Technologies ===
+
−
Here is a list of available technologies to extend the JWT metamodel :
+
−
* static, "fixed" extension model done in static EMF (loaded as instances of JET-generated classes). Requires to generate classes using a .genmodel file. Those classes must be available to JWT and specified in the workflow file. STP-IM -like properties are in this case.
+
−
* custom designed extension model done with static EMF (loaded as instances of JET-generated classes). Requires to generate classes using a .genmodel file. Those classes must be available to JWT and specified in the workflow file.
+
−
* custom designed extension model done with dynamic EMF (loaded as instances of DynamicEObjectImpl). Ecore schema must be specified in schemaLocation and available there.
+
−
* custom designed extension model done withany XML following user-defined xsd schemas (loaded through XSDEcoreBuilder). XSD schema must be specified in schemaLocation and available there.
+
−
* custom designed extension content done withany XML (without xsd schema), read by EMF (loaded as instances of AnyTypeImpl)
+
−
* custom designed extension content done withany XML or other kind of text, read by EMF as string and parsed by custom XMLHandler or other custom parser
+
−
 
+
−
=== Simple extension alternative : property map ===
+
−
No metamodel extension has to be defined. However there is no proper typing ; therefore property names are to be well managed so properties created by different extension vendors don't conflict with each other.
+
−
 
+
−
=== Powerful extension alternative : EMF extensibility and Aspects ===
+
−
Benefits from the full expressivity of Ecore metamodeling. The dynamic EMF technology is especially interesting, because it blends ease of use (no code to write or generate) with power ; therefore we'll especially consider it in our analysis from now on.
+
−
 
+
−
What parts of the model are interesting to be extended ?
+
−
* Mainly Action, but possibly others :
+
−
* external subprocess to add information about how to execute it
+
−
* Model to add vendor-specific information about the process model
+
−
* actually, any model element could be interesting to put Vendor specific information on.
+
−
 
+
−
Therefore we'll try to stay as open as possible on the topic of what is extensible.
+
  
−
Are there limitations ?
+
==== JWT 0.5 Metamodel and BPMN ====
−
* performances. Dynamic EMF and mixed static - dynamic EMF models are slower to load, in proportion to the amount of dynamic EMF within. Most extensions will be small and sparse, and therefore performances will stay OK. If not, it is up to the extension vendor to choose static EMF for his extension in order to provide better performances.
+
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.
−
* Diagram - graph - GEF manipulations. We choose to evacuate this problem by not letting extensions be displayed or handled in any way in the diagram GEF editor. Manipulating them in a generic or vendor specific view is enough.
+
−
** Note that displaying them in GEF is still possible if the right GEF code is written - but that is more than a mere extension.
+
−
* In the specific case of Action, Directly extending JWT Action is only possible using static EMF, because it may contain static subelements (Location, Size). So it is possible, but not the most useful. Anyway it is more akin to modifying the core JWT model than to writing an extension (I think), so we won't talk about this possibility here. However this still implies that EMF extensions should be put in their own subelement, meaning Action (or other extensible model elements) should have a containment relation to extensions.
+
  
−
There is a common concept that is philosophically close to our needs (anything extensible, extension in their own subelements) : the concept of "Aspect" (or mixin etc.). An Aspect can be viewed as a "part of a type" designed to answer or implement a well-defined business or technical need. Therefore I'll use the term of Aspect when speaking of typed extensions from now on.
+
==== 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]].
  
−
Finally, EMF extensibility could also provide a simple extension alternative thanks to a base PropertiesAspectTemplate that has only to be extended.
+
== 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.
  
−
=== Design alternatives ===
+
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 :
−
Here is a list of changes to the JWT model that are possible to implement said features.
+
* '''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.  
  
−
"Aspects" contained relation to EObject (better alternative : to Aspect) under ModelElement
+
=== 1. "classical" EMF extension ===
−
* we can't directly extend JWT Action, because it contains static subelements (Location, Size) and therefore can not have Dynamic EMF extensions. Therefore every extensions are put in their own subelement (below the "aspects" relation).
+
* 1. define the EMF model
−
* typing it with EObject makes it more powerful and easier to extend. However it does not take advantage of typing, allows "illegal" models (ex. adding a DataType as aspect...).
+
* 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
−
* as a better alternative, it can be typed with a new Aspect class. In this case, we also create an Aspect class. Either Aspect is a static non abstract class, or a dynamic interface. The second is better because Aspect implementations will be loaded as DynamicEObjectImpl and not AspectImpl, and therefore fully dynamic ; but at the same time it forbids static EMF Aspect implementations.
+
* 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))
  
−
Trying easy aspect sample
+
(courtesy of Kim Nguyen and a lot of others)
−
* the goal of PropertiesAspectTemplate is to make simple extensions (i.e. property map like) trivial. It  is an abstract dynamic object that has only to be extended by the user to create a custom property map aspect.
+
−
* SamplePropertiesAspect is such a sample aspect providing information in the form of a mere property map
+
  
−
Trying STP-IM like inlined properties : "properties" contained relation to Property under ModelElement
+
=== 2. JWT Metamodel EMF Aspects Extension ===
−
* not factorized as Properties with PropertiesAspectTemplate to avoid complexity (parts) for now
+
−
* property map should follow best practice (as done by STP-IM) as explained here : http://wiki.eclipse.org/index.php/EMF-FAQ#How_do_I_create_a_Map_in_EMF.3F
+
  
−
Trying profiles :
+
==== Using JWT Metamodel Aspects Extension ====
−
* Profile class with requiredAspectTypes multivalued attribute
+
[[JWT_Metamodel_Extension]] documents how to use store custom information in (workflow) models using Conf, Profiles and Aspects :
−
* "profileDefs" contained relation to Profile under Model,
+
* prerequisites : [[JWT_Metamodel_Extension#Using_aspect_model_extensions|Using aspect model extensions]]
−
* "profile" (not contained) relation under Scope (limitation : not on Action ; though on StructuredActivityNode)
+
* [[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]]
  
−
TODO upload tries in bugzilla
+
==== (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 :
 +
** [[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 Marc Dutoo. Based on work by C. Saad and Florian Lautenbacher.

Copyright © Eclipse Foundation, Inc. All Rights Reserved.