Skip to main content
Jump to: navigation, search

JWT Metamodel


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.

Initial metamodel

This document File: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.

JWT metamodel comparisons

Comparison with other metamodels

A comparison with other meta-models as a result of an evaluation can be found in the following document: File:EvaluationExistingMetamodels.pdf.

Metamodel and XPDL 1.0

The document File: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.

Metamodel and BPMN

Please find under File:Comparison JWT BPMN v0 3.pdf a document describing the differences between the JWT Metamodel on the one hand and BPMN on the other.


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.
  • specific Action features support (Ralph Soika, : 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) provide ways to manage consistency of all typed extensions

JWT metamodel extension in the broader picture (added 20080527)

JWT metamodel extension has an impact on other JWT components : for example, it implies these components have to be extensible themselves, or they may benefit from custom tailored extensions. These components and their impacts are :

  • JWT Workflow Editor tool : model extension display and edition
  • JWT Transformations : extended model transformation to representation or executable format, enriching existing ones
  • JWT Runtime technologies : extensions that are custom to a given technology, extensible runtime utilities
  • JWT Workflow Administration and Monitoring tool : custom extensions, ex. to configure monitoring


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 ?

  • 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.
  • 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.

Finally, EMF extensibility could also provide a simple extension alternative thanks to a base PropertiesAspectTemplate that has only to be extended.

Design alternatives

Here is a list of changes to the JWT model that are possible to implement said features.

"aspects" contained relation to EObject (better alternative : to Aspect) under ModelElement

  • 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).
  • 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...).
  • 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.

Trying easy aspect sample

  • 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

Trying profiles idea :

  • Profile class with requiredAspectTypes multivalued attribute
  • "profileDefs" contained relation to Profile under Model,
  • "profile" (not contained) relation under Scope (limitation : not on Action ; though on StructuredActivityNode)

Weighting design alternatives

(This weighting is based on tries and samples)

Typing aspects relation to EObject (rather than Aspect) ? (added 20080527)

  * pros : allows to use Dynamic EMF (else not DynamicEObjectImpl) ; but maybe a DynamicAspectEObjectImpl could be written ?
  * cons : the outline > new child feature can't be used out of the box anymore, because all children are added as aspects (and not profiles, nodes...) ; but maybe relations (at least aspects) could be made visible there ?

Working sample (added 20080527)

It demonstrates the mixed static and dynamic EMF technology, thanks to a JWT metamodel with an EObject-typed "aspects" relation on ModelElement (or Action). To be loaded in JWT, it requires some magic (to be polished and provided) in WEEditor.createModel().

Extract from proposed JWT Metamodel :

<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
    xmlns:xmi="" xmlns:xsi=""
    xmlns:ecore="" name="model"
    nsURI="org.eclipse.jwt" nsPrefix="">
  <eSubpackages name="core" nsURI="org.eclipse.jwt/core" nsPrefix="core">
    <eClassifiers xsi:type="ecore:EClass" name="ModelElement">
      <eStructuralFeatures xsi:type="ecore:EReference" name="aspects" upperBound="-1"
          eType="ecore:EClass" containment="true"/>

Here we define a LogAspect extension meant to provide an Action with additional information (messageFormat and logProtocol attributes) about how it might be logged at runtime.

Metamodel extension definition WEMetaModel_log1.workflow :

<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
    xmlns:xmi="" xmlns:xsi=""
    xmlns:ecore="" name="logModel"
    nsURI="org.eclipse.jwt.log" nsPrefix="">
    <eClassifiers xsi:type="ecore:EClass" name="LogAspect">
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="messageFormat" eType="ecore:EDataType"/>
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="logProtocol" lowerBound="1"

Workflow sample (inspired by a jwt2bpmn unit test workflow) activity_log1.workflow :

<?xml version="1.0" encoding="UTF-8"?>
<core:Model xmi:version="2.0" xmlns:xmi=""
xsi:schemaLocation="org.eclipse.jwt.log WEMetaModel_log1.ecore"
name="MainPackage" fileversion="0.4.0">
  <elements xsi:type="processes:Activity" name="Diagram1">
    <nodes xsi:type="processes:Action" name="Log Action" in="//@elements.0/@edges.0" out="//@elements.0/@edges.1" performedBy="//@elements.1" referenceEdges="//@elements.0/@referenceEdges.0">
      <properties name="testProp" value="testPropVal"/>
      <properties name="testProp2" value="testPropVal2"/>
      <aspects xsi:type="log:LogAspect" messageFormat="WARNING %" logProtocol="beep"/>
      <aspects xsi:type="core:SamplePropertiesAspect"/>
      <Location x="140" y="153"/>
      <Size width="71" height="31"/>
    <nodes xsi:type="processes:InitialNode" out="//@elements.0/@edges.0">
      <Location x="41" y="158"/>
    <nodes xsi:type="processes:FinalNode" in="//@elements.0/@edges.1">
      <Location x="294" y="157"/>
    <edges source="//@elements.0/@nodes.1" target="//@elements.0/@nodes.0"/>
    <edges source="//@elements.0/@nodes.0" target="//@elements.0/@nodes.2"/>
    <references reference="//@elements.1" referenceEdges="//@elements.0/@referenceEdges.0">
      <Location x="164" y="56"/>
    <referenceEdges reference="//@elements.0/@references.0" action="//@elements.0/@nodes.0"/>
  <elements xsi:type="organisations:Role" name="role" icon=""/>

Feedback :

Metamodel extensions and JWT WE (added 20080527)

Metamodel extensions and JWT WE - Issue

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.

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. However we obviously won't limit features to what EMF provides. So these needs may be implemented in the ecore (if possible), or through adapted or custom UI code or UI code generation, or even through ecore customization (see - though that wouldn't impact dynamic EMF ?).

Metamodel extensions and JWT WE - 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 :

  • to limit instanciation of an aspect of a given type to at most one, or exactly one : "single" and / or "unique" properties
  • (optional) to forbid deleting it (or require it to be instanciated again) : "undeletable" and / or "readonly" ; cons : typing these properties in an abstract aspect complexifies creating aspects
  • 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
  • to require instanciation of an aspect or aspect list on a model element : 1. globally defined list, in JWT release configuration (or possibly user preferences ?) ; 2. user-chosen list at instanciation time, by letting him chose an aspect list or a profile (aspect 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 rules : by modifying generated code emf, palette ? policies ??

Metamodel extensions and JWT Views

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 (tested by Marc) : 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-release-builder plugin

Metamodel extensions and JWT Transformations


Metamodel extensions and JWT Runtimes


still TODO upload code in bugzilla

Back to the top