JWT Metamodel Extension Specifications/Alternatives Study

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

Technologies

Technologies overview

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). Those classes must be available to JWT and specified in the workflow file. STP-IM -like properties are in this case. Christian Saad's proposition for the "dynamic properties" requirement also, but in order to control their semantics and behaviour, uses an additional metamodel that must be provided in workflow model, in workflow bundle, in autodiscovery directory or in plugin.xml.
• custom designed extension model done with static EMF (loaded as instances of JET-generated classes). Requires the extension developer 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, or if loading is customized in workflow bundle, in autodiscovery directory or in plugin.xml.
• custom designed extension model done with XML following user-defined xsd schemas, loaded as EMF / XML using through XSDEcoreBuilder. XSD schema must be specified in schemaLocation and available there, or if loading is customized in workflow bundle, autodiscovery directory or in plugin.xml. Alternatively but at the risk of lowering the typing of the whole model, any XML (without schema) could be allowed and loaded EMF / XML AnyTypeImpl. Alternatively, loading could be done not by base EMF but delegated to a custom EMF XMLHandler or even any non-EMF parser ; Imixs.org's Ralph Soika proposal follows this, and alternatively suggests that a model's extension content could even live in its own file.

Simple static 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.

Typed static extension alternative : typed properties (Christian Saad)

Dynamic EMF extension limitation

To make the actual additions to the JWT metamodel, I’ve experimented a bit with dynamic EMF. At first, it seemed that possibly the simplest solution to extend existing classes would be to directly inject dynamically created EAttributes or EReferences into the metaobjects because in this case EMF would take care of most issues concerning the management of the new items.

However, I’ve learned that, sadly, it’s not possible to extend existing static metaelements with dynamic structuralfeatures. It is only allowed to create completely new dynamic classes or to subclass existing static classes. Unfortunately this makes the whole process of an almost automatic management of extensible metaelements quite difficult (or maybe I’m just missing an obvious solution).

Doing it using an additional extension metametamodel

The alternative would be to create a static metaelement for dynamic properties as described in task 225704 and write code that simulates the behavior of EMF EAttributes or EReferences using instances of this class.

I hope I got the basic idea that is behind this extension mechanism right. To see if this is the case, I drew a small diagram outlining a very concrete implementation of this extension of how I perceived the problem (see below). Please correct me if I missed the point or if this would be not viable solution.

The basic idea is that dynamic properties are specified using a small, external meta-model, in which a set of properties is part of a special container element (just like Model is in the JWT metamodel). Sets of dynamic properties can be serialized to and loaded from XMI files by the user or created by Plugins using Eclipse extension points (being converted into the corresponding properties model). This would represent a generic interface to JWT.

Once a set (or multiple sets) of dynamic properties is loaded into JWT, it (they) can be added by the user to a model file. This means that when selecting a ModelElement, the itemprovider searches all sets of activated dynamic properties for properties that were declared for this EClass-type and creates corresponding instances of DynamicPropertyValue. The displaying of the dynamic properties can done by the modified propertypage.

Marc : this alternative can be viewed as being like STP-IM's properties (EObject valued static properties) with an additional metatyping system to manage their consistency ("profile").

How the typed dynamic properties extension works :

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

"Aspects" 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 (i.e. containment reference objects : 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...). However custom ItemProvider could be made to control how it is used in the WE.
• as another alternative, it can be typed with a new Aspect class. In this case, we also create an Aspect class. EMF imposes that either Aspect is a static non abstract class (with a generated implementation e.g. "AspectImpl"), or a dynamic interface.
• Typing it with a dynamic "Aspect" interface implies all Aspect implementations will be loaded as DynamicEObjectImpl and not AspectImpl, and therefore fully dynamic. It is simpler but at the same time forbids static EMF Aspect implementations and their performance benefits.
• Typing it with a static (non interface, non abstract, generated) Aspect class allows either dynamic or static extensions. However such "dynamic type extending static base type" extensions have limitations : they can only contain references that are typed by a type defined within the extension ecore (and not a JWT core type), while obviously their static base type can only contain statically-typed references.

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

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

Look up prototype and sample at JWT Metamodel Extension Specifications/Prototype

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 ?