Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "JWT Metamodel Extension Specifications/Requirements"

Line 7: Line 7:
 
* JWT typed custom properties and tab : JWT Project, especially Florian Lautenbacher ; see description at https://bugs.eclipse.org/bugs/show_bug.cgi?id=225704
 
* 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 ===
+
= 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.
 
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.
  
Line 16: Line 17:
 
* storing STP BPMN Editor annotations, including those that may originate from other tools like STP-IM
 
* storing STP BPMN Editor annotations, including those that may originate from other tools like STP-IM
  
=== Bonita v4 XPDL "hook" support ===
+
== 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).
 
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).
  
Line 26: Line 27:
 
* action performer assignment
 
* action performer assignment
  
=== Service (WebService, SCA) call support ===
+
== Service (WebService, SCA) call support ==
 
Requires to store and manage information pertaining to these specific Actions / Application or Action / Application extensions.
 
Requires to store and manage information pertaining to these specific Actions / Application or Action / Application extensions.
  
Line 48: Line 49:
 
* 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.
 
* 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 ===
+
== 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.
 
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.
  
Line 59: Line 60:
 
* POJO method
 
* POJO method
  
=== Imixs.org specific Action features support ===
+
== 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).
 
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).
  
Line 66: Line 67:
 
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
 
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 ===
+
== JWT typed custom properties and tab ==
 
See Florian Lautenbacher's requirements at https://bugs.eclipse.org/bugs/show_bug.cgi?id=225704 .
 
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.).
 
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.).

Revision as of 15:40, 5 January 2009

Sources and contributors


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

Back to the top