Skip to main content
Jump to: navigation, search

Difference between revisions of "JWT Metamodel"

Line 45: Line 45:
 
* allow JWT metamodel to be extended
 
* allow JWT metamodel to be extended
 
* 1. for JWT developers (ex. allow complex metadata, using static EMF for performances)
 
* 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 for ease of use, using simple concepts ex. a property map)
+
* 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
 
* 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
 
* 3. IN A SECOND TIME (more complex, several consequences, see further) provide ways to manage consistency of all typed extensions
 +
 +
=== Design ===
 +
 +
=== Technologies ===
 +
Here is a list of available technologies to extend the JWT metamodel :
 +
* 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.
 +
* dynamic EMF (loaded as instances of DynamicEObjectImpl). Ecore schema must be specified in schemaLocation and available there.
 +
* any XML following user-defined xsd schemas (loaded through XSDEcoreBuilder). XSD schema must be specified in schemaLocation and available there.
 +
* any XML (without xsd schema), read by EMF (loaded as instances of AnyTypeImpl)
 +
* any XML or other kind of text, read by EMF as string and parsed by custom XMLHandler or other custom parser

Revision as of 09:56, 19 May 2008

Introduction

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.


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

Design

Technologies

Here is a list of available technologies to extend the JWT metamodel :

  • 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.
  • dynamic EMF (loaded as instances of DynamicEObjectImpl). Ecore schema must be specified in schemaLocation and available there.
  • any XML following user-defined xsd schemas (loaded through XSDEcoreBuilder). XSD schema must be specified in schemaLocation and available there.
  • any XML (without xsd schema), read by EMF (loaded as instances of AnyTypeImpl)
  • any XML or other kind of text, read by EMF as string and parsed by custom XMLHandler or other custom parser

Back to the top