Skip to main content
Jump to: navigation, search

JWT Metamodel Extension Specifications/Requirements

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 : WebServiceApplicationScaImpl

As an 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 specific Action features support 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$FILE/img-0006.gif

JWT typed custom properties and tab

See Florian Lautenbacher's requirements at .

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