Difference between revisions of "JWT Metamodel"

From Eclipsepedia

Jump to: navigation, search
(JWT metamodel extension)
(Extending the JWT Metamodel)
 
(44 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.
  
== 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.
  
== Requirements ==
+
==== JWT 0.5 Metamodel and BPMN ====
 
+
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.
=== Sources and contributors ===
+
* BPMN2JWT transformation : SCOrWare project, especially Obeo and Open Wide ; see JWT CVS
+
* Nova Bonita v4 XPDL "hook" support : Miguel Valdes, Emmanuel Rias (Bull) ; see Nova Bonita website at http://wiki.bonita.objectweb.org/xwiki/bin/view/Main/Nova
+
* Service (WebService, SCA) call support : SCOrWare project, especially Open Wide
+
* Custom Action support : Bryan Hunt, from the EMFT MWE Eclipse project, working on the requirements described at https://bugs.eclipse.org/bugs/show_bug.cgi?id=225892
+
* Imixs specific Action features support : Ralph Soika, of Imixs.org ; see information about the current IX Workflow Modeler at http://www.imixs.org/websites/imixs-org.nsf/chapter/3000.0030.
+
* JWT typed custom properties and tab : JWT Project, especially Florian Lautenbacher ; see description at https://bugs.eclipse.org/bugs/show_bug.cgi?id=225704
+
 
+
=== List of requirements ===
+
 
+
==== BPMN2JWT transformation ====
+
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). Marc : more generally, transformations to and from other models have the same kind of requirements.
+
 
+
Examples :
+
* storing the "looping" boolean of BPMN Looping Tasks
+
* storing STP BPMN Editor annotations, including those that may originate from other tools like STP-IM
+
 
+
==== Bonita v4 XPDL "hook" support ====
+
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. This extension should be editable in a custom-built UI view. This extension's information should be translated to Bonita XPDL in the right format (using XPDL ExtendedAttributes mainly).
+
 
+
Example : an Action may have Hooks. A Hook comprises the following information :
+
* the Action-originated event (ready, start, beforeEnd, end, cancel, pause, resume...) it is hooked on. Note that a hook may be hooked on many events, which is the same that saying that there may be several identical hooks hooked on different events, since hooks are stateless.
+
* the Java Hook class it calls when triggered. This class must implement the corresponding interface (NodeHookI, which has one method for each event).
+
 
+
Other examples :
+
* action performer assignment
+
 
+
==== Service (WebService, SCA) call support ====
+
Requires to store and manage information pertaining to these specific Actions / Application or Action / Application extensions.
+
 
+
WebServiceApplication has the following information :
+
* WSDL definition and deployment information. A single service URL that also provides the WSDL by appending "?wsdl" to it is enough. Alternatively could be explicitely provided the WSDL, the service, the portTyp, the location in optional "overriding" properties.
+
* operation
+
* NB. there exists such a concept in the nowadays JWT metamodel, but it inherits from the Java specific Application whose "javaClass" and "jarArchive" are meaningless here
+
* NB. this may be implemented in any given way at runtime, including on top of middleware technologies such as SCA. In this case, additional information required by the runtime implementation must be provided in a specific extension.
+
 
+
ScaServiceApplication has the following information :
+
* SCA service name
+
* SCA service Java interface. Ideally this should be guessed at runtime.
+
* SCA service method
+
* NB. the runtime engine must be integrated in an SCA architecture, typically by being configured to load at startup the appropriate SCA composite files. Note that the alternative of specifying in JWT a specific SCA composite file to instanciate at runtime is not a good SOA practice since it explodes the engine node's SCA architecture ; however it is interesting in a technical point of view, for example to implement calls made by other applications. like WebService calls.
+
 
+
Extension example : A runtime implementation of WebServiceApplication on top of SCA calls requires the following extended information (in addition to those of WebServiceApplication) :
+
* SCA binding type. For a WebServiceApplication, must be "ws".
+
* SCA service Java interface. Ideally this should be guessed at runtime.
+
* other information required by the chosen runtime middleware
+
* NB. these information allow to generate an SCA composite defining a java equivalent of the target web service, which may therefore be called.*
+
* NB. these information could be provided in an extension to a given WebServiceApplication instance, or to an extension to Activity (i.e. process) that configures its runtime platform.
+
 
+
==== MWE Custom Action support ====
+
This is the equivalent of EMFT MWE's Bryan Hunt's WorkflowComponent concept. 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 ; this is similar to jBoss and Bull's PVM generic process engine, and somehow to Windows Workflow Foundation.
+
 
+
Such an extension is actually a JWT Action's implementation. This implies there can only be one such extension per ActivityNode, though nothing says they themselves can't be extended somehow. In its concept, it is similar to a custom extension of JWT Application that is inlined (embedded) within an Action.
+
 
+
Example : log Action
+
 
+
Example : POJO Action requires the following information :
+
* POJO class
+
* POJO method
+
 
+
==== Imixs.org specific Action features support ====
+
Imixs.org features depend on numerous Action-level properties that should be stored and accessible in JWT metamodel, and editable typically through an additional property tab(s).
+
 
+
Such an extension is actually an additional, activable feature that is available on any JWT Action, that provides new functionality not related to the Action's actual implementation (i.e. what it does). For instance, it could as well apply to an Action that calls a web service, as to an Action that asks information to the user as event to a Join node.
+
 
+
Example : "IX Mail Module" which needs informations to generate a email during a transition, as seen here http://www.imixs.org/websites/imixs-org.nsf/vResourcesNameLookup/WorkflowModeler.CreateProcess/$FILE/img-0006.gif
+
 
+
==== JWT typed custom properties and tab ====
+
See Florian Lautenbacher's requirements at https://bugs.eclipse.org/bugs/show_bug.cgi?id=225704 .
+
 
+
See Christian Saad's contribution proposition in the mailing list. It uses a single static Property type and an additional external metamodel to control the behaviour of the typed properties (when and where to create them, version etc.).
+
 
+
== 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
+
 
+
=== 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). 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 attachment). 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.
+
 
+
=== 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
+
* 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)
+
 
+
=== 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 ?
+
 
+
== JWT metamodel extension - working samples (added 20080527) ==
+
 
+
=== Required changes in JWT WE ===
+
These samples showcase 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 also requires some magic in WEEditor.createModel().
+
 
+
Extract from proposed JWT Metamodel :
+
<source lang="xml">
+
<?xml version="1.0" encoding="UTF-8"?>
+
<ecore:EPackage xmi:version="2.0"
+
    xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+
    xmlns:ecore="http://www.eclipse.org/emf/2002/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 http://www.eclipse.org/emf/2002/Ecore#//EObject" containment="true"/>
+
      ...
+
    </eClassifiers>
+
    ...
+
  </eSubpackages>
+
  ...
+
</ecore:EPackage>
+
</source>
+
 
+
Configuring EMF .workflow file loading in WEEditor.createModel() :
+
<source lang="xml">
+
                  mainModelResource = getEmfEditingDomain().getResourceSet().createResource(resourceUri);
+
                  XMIResourceImpl r = (XMIResourceImpl) mainModelResource;
+
          r.setEncoding("UTF-8");
+
          // load options
+
          r.getDefaultLoadOptions().put(XMLResource.OPTION_EXTENDED_META_DATA, Boolean.TRUE);
+
          r.getDefaultLoadOptions().put(XMLResource.OPTION_USE_LEXICAL_HANDLER, Boolean.TRUE);
+
          r.getDefaultLoadOptions().put(XMLResource.OPTION_USE_ENCODED_ATTRIBUTE_STYLE, Boolean.TRUE);
+
          XMLOptions xmlOptions = new XMLOptionsImpl();
+
          xmlOptions.setProcessAnyXML(false); // REQUIRED for XSD ; else won't find ecore classes defined in metamodel extensions ; however doesn't work with old agilpros
+
          xmlOptions.setProcessSchemaLocations(true); // not required, works also with false ?!
+
          r.getDefaultLoadOptions().put(XMLResource.OPTION_XML_OPTIONS, xmlOptions);
+
          // save options (or in doSave())
+
          r.getDefaultSaveOptions().put(XMLResource.OPTION_EXTENDED_META_DATA, Boolean.TRUE);
+
          //r.getDefaultSaveOptions().put(XMLResource.OPTION_LINE_WIDTH, new Integer(80));
+
          r.getDefaultSaveOptions().put(XMLResource.OPTION_USE_ENCODED_ATTRIBUTE_STYLE, Boolean.TRUE);
+
          r.getDefaultSaveOptions().put(XMLResource.OPTION_SCHEMA_LOCATION, Boolean.TRUE); // REQUIRED else no xsi:schemaLocation after save !
+
          //r.getDefaultSaveOptions().put(XMLResource.OPTION_SCHEMA_LOCATION_IMPLEMENTATION, Boolean.TRUE); // adds java:// schemaLocation for static ecore
+
mainModelResource = getEmfEditingDomain().getResourceSet().getResource(
+
resourceUri, true);
+
// read version from the model object in the resource
+
converter.readModelVersionFromFile(getModel(), resourceUri);
+
 
+
// if old version model, reread it now that the version is known
+
if (getModel() instanceof AnyType) {
+
loadOldVersionModel(resourceUri);
+
}
+
</source>
+
 
+
=== LogAspect sample ===
+
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 :
+
<source lang="xml">
+
<?xml version="1.0" encoding="UTF-8"?>
+
<ecore:EPackage xmi:version="2.0"
+
    xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+
    xmlns:ecore="http://www.eclipse.org/emf/2002/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 http://www.eclipse.org/emf/2002/Ecore#//EString"/>
+
      <eStructuralFeatures xsi:type="ecore:EAttribute" name="logProtocol" lowerBound="1"
+
          eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"
+
          defaultValueLiteral="syslog"/>
+
    </eClassifiers>
+
</ecore:EPackage>
+
</source>
+
 
+
Workflow sample (inspired by a jwt2bpmn unit test workflow) activity_log1.workflow :
+
<source lang="xml">
+
<?xml version="1.0" encoding="UTF-8"?>
+
<core:Model xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
+
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+
xmlns:core="org.eclipse.jwt/core"
+
xmlns:organisations="org.eclipse.jwt/organisations"
+
xmlns:processes="org.eclipse.jwt/processes"
+
xmlns:log="org.eclipse.jwt.log"
+
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">
+
      <aspects xsi:type="log:LogAspect" messageFormat="WARNING %" logProtocol="beep"/>
+
      <Location x="140" y="153"/>
+
      <Size width="71" height="31"/>
+
    </nodes>
+
    <nodes xsi:type="processes:InitialNode" out="//@elements.0/@edges.0">
+
      <Location x="41" y="158"/>
+
    </nodes>
+
    <nodes xsi:type="processes:FinalNode" in="//@elements.0/@edges.1">
+
      <Location x="294" y="157"/>
+
    </nodes>
+
    <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"/>
+
    </references>
+
    <referenceEdges reference="//@elements.0/@references.0" action="//@elements.0/@nodes.0"/>
+
  </elements>
+
  <elements xsi:type="organisations:Role" name="role" icon=""/>
+
</core:Model>
+
</source>
+
 
+
 
+
=== InvokeWebServiceAspect sample ===
+
Adding this aspect to an action (or its application) specifies a runtime invocation of the given web service.
+
 
+
Note that there will be two different ways to invoke a service : either explicitly calling a web service using this aspect, or calling a generic service and also specifying its binding (web service, rmi, xml / rest...) by using another aspect InvokeServiceAspect and runtime infrastructure provided by the friend SCOrWare project.
+
 
+
Metamodel extension definition WEMetaModel_ws.workflow :
+
<source lang="xml">
+
<?xml version="1.0" encoding="UTF-8"?>
+
<ecore:EPackage xmi:version="2.0"
+
    xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+
    xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="wsModel"
+
    nsURI="org.eclipse.jwt.ws" nsPrefix=""
+
    xmlns:core="org.eclipse.jwt/core"
+
    xsi:schemaLocation="org.eclipse.jwt/core java://org.eclipse.jwt.we.model.core.CorePackage">
+
  <eClassifiers xsi:type="ecore:EClass" name="InvokeWebService" instanceClassName="org.eclipse.jwt.we.model.core.impl.AspectImpl"
+
      eSuperTypes="java://org.eclipse.jwt.we.model.core.CorePackage#//core/ApplicationAspectTemplate">
+
    <eStructuralFeatures xsi:type="ecore:EAttribute" name="bindingType" lowerBound="1"
+
        eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
+
    <eStructuralFeatures xsi:type="ecore:EAttribute" name="wsdl" lowerBound="1" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
+
    <eStructuralFeatures xsi:type="ecore:EAttribute" name="url" lowerBound="1" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
+
    <eStructuralFeatures xsi:type="ecore:EAttribute" name="operation" lowerBound="1"
+
        eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
+
  </eClassifiers>
+
</ecore:EPackage>
+
</source>
+
 
+
Extract from workflow activity sample :
+
<source lang="xml">
+
<elements xsi:type="processes:Activity" name="Diagram1">
+
    <nodes xsi:type="processes:Action" name="WS Action" in="//@elements.0/@edges.0" out="//@elements.0/@edges.1" performedBy="//@elements.1" referenceEdges="//@elements.0/@referenceEdges.0">
+
      <aspects xsi:type="ws:InvokeWebService" bindingType="ws" wsdl="" url="http://localhost:8080/EchoService" operation="echo"/>
+
      ...
+
    </nodes>
+
...
+
</elements>
+
</source>
+
 
+
Some screenshots :
+
[[Image:Jwt_emfextension_ws.png]]
+
 
+
=== UserMappingAspect sample ===
+
This sample showcases a more complex aspect.
+
 
+
UserMappingAspect's purpose is to allow to provide to an action (or its application) more specific user mappings than those defined globally at workflow level. It is useful when all applications executed by a workflow are not using the same user directory as the workflow engine ; in this case, applications that require specific credentials will use this aspect to provide them.
+
 
+
The UserMappingAspect contains several UserMappings, each specifying how a given runtime user (i.e. a user known within the workflow engine) is mapped to different credentials when talking to the application, which has to exploit this data on its own.
+
 
+
Metamodel extension definition WEMetaModel_usermapping.workflow (added 20080624) :
+
<source lang="xml">
+
<?xml version="1.0" encoding="UTF-8"?>
+
<ecore:EPackage xmi:version="2.0"
+
    xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+
    xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="usermappingModel"
+
    nsURI="org.eclipse.jwt.usermapping" nsPrefix="">
+
  <eClassifiers xsi:type="ecore:EClass" name="UserMappingAspect" instanceClassName="org.eclipse.jwt.we.model.core.impl.AspectImpl"
+
      eSuperTypes="WEMetaModel.ecore#//core/ApplicationAspectTemplate">
+
    <eStructuralFeatures xsi:type="ecore:EReference" name="userMappings" upperBound="-1"
+
        eType="#//UserMapping" containment="true"/>
+
    <eStructuralFeatures xsi:type="ecore:EAttribute" name="enabled" lowerBound="1"
+
        eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EBoolean" defaultValueLiteral="true"/>
+
  </eClassifiers>
+
  <eClassifiers xsi:type="ecore:EClass" name="UserMapping">
+
    <eStructuralFeatures xsi:type="ecore:EAttribute" name="username" lowerBound="1"
+
        eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
+
    <eStructuralFeatures xsi:type="ecore:EAttribute" name="password" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
+
    <eStructuralFeatures xsi:type="ecore:EAttribute" name="mappedUserName" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
+
  </eClassifiers>
+
</ecore:EPackage>
+
</source>
+
 
+
Extract from workflow activity sample (added 20080624) :
+
<source lang="xml">
+
<elements xsi:type="processes:Activity" name="Diagram1">
+
    <nodes xsi:type="processes:Action" name="User Mapping Action" in="//@elements.0/@edges.0" out="//@elements.0/@edges.1" performedBy="//@elements.1" referenceEdges="//@elements.0/@referenceEdges.0">
+
      <aspects xsi:type="usermapping:UserMappingAspect" enabled="true">
+
        <usermapping:userMappings xsi:type="usermapping:UserMapping" username="guest" password="" mappedUserName="anonymous"/>
+
        <usermapping:userMappings xsi:type="usermapping:UserMapping" username="admin" password="admin"/>
+
      </aspects>
+
      ...
+
    </nodes>
+
...
+
</elements>
+
</source>
+
 
+
Some screenshots (added 20080624) :
+
[[Image:Jwt_emfextension_usermapping.png]]
+
 
+
== 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, 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 ===
+
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-release-builder plugin
+
  
=== Metamodel extensions and JWT WE - finding and loading models and ecores ===
+
==== JWT 0.5 Metamodel and various others ====
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.
+
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]].
  
Requirements for finding and providing extension definition files
+
== Extending the JWT Metamodel ==
* 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.
+
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.
* 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 :
+
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 :
* files in an autodiscovery directory
+
* '''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.
* zipped files in a workflow bundle (zipped .workflow + extension definition files)
+
* '''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.
* 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 ===
+
=== 1. "classical" EMF extension ===
Another issue is versioning (csaad)
+
* 1. define the EMF model
* 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.
+
* 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
* Note that Model is already versioned.
+
* 3. create a new FactoryRegistry and override the Palette (or create new Palette)
* 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.
+
* 4. in Palette just add new model item ex. activityGroup.add(createCreationToolEntry(ModelPackage.Literals.TRANSPORT_OBJECT))
  
== Metamodel extensions and JWT Transformations ==
+
(courtesy of Kim Nguyen and a lot of others)
TODO
+
  
== Metamodel extensions and JWT Runtimes ==
+
=== 2. JWT Metamodel EMF Aspects Extension ===
TODO
+
  
 +
==== 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]]
  
still TODO upload code 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

Contents

[edit] 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.


[edit] 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.

[edit] 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.

[edit] 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.

[edit] 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.

[edit] 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.

[edit] 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.

[edit] Metamodel comparisons

[edit] 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.

[edit] 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.

[edit] 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.

[edit] 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.

[edit] 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)

[edit] 2. JWT Metamodel EMF Aspects Extension

[edit] Using JWT Metamodel Aspects Extension

JWT_Metamodel_Extension documents how to use store custom information in (workflow) models using Conf, Profiles and Aspects :

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