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.
Difference between revisions of "JWT Metamodel"
| Line 32: | Line 32: | ||
=== List of requirements === | === 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. | ||
Revision as of 10:30, 18 May 2008
Contents
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 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