Skip to main content
Jump to: navigation, search

STP/IM Component/STP Intermediate Metamodel

< STP‎ | IM Component
Revision as of 12:10, 29 August 2007 by (Talk | contribs) (Introduction)


The Intermediate STP Metamodel will serve to facilitate the sharing of information between different editors in Eclipse STP. A detailed discussion on this subject is available here. A sample scenario involving this common metamodel is also available.

This page presents the metamodel and a brief description of the main elements. The .ecore file and the diagram file (standard EMF editor in Eclipse) are also available in the resources section.

Proposed Intermediate Metamodel


The following diagram presents the EMF elements for the proposed STP intermediate model. Stpmodel.gif


The core model elements are Service and Process, identified in red on the diagram. The whole model is contained under one root element (in magenta on the diagram). Services are contained by the ServiceCollection, Processes by ProcessCollection and Properties are defined by PropertyDefinitions contained in the PropertyDefinitionCollection. Services have Bindings and properties. Properties can be anything defined by the PropertyDefinition. They could be used as simple key-value pairs as well as to define more complex properties of a Service (perhaps also contracts? Thanks to David Bosschaert for pointing out the need for contracts). Services can also be used as control elements (ControlService) that correspond to several integration patterns. Several such control patterns are identified in grey on the diagram as they might not be used by all editors (such as SCA). They are however quite useful in the JBI world. Services are also associated with ServiceClasses in order to facilitate their classification.

Processes are defined as having steps, while each Step can be associated with a service to represent that its functionality is fulfilled by that particular service. Process steps are also associated with bindings because they need to use a specific binding of a service when executing a particular step (a service can have multiple bindings). Transitions define the succession of steps. A basic transition type, the TransitionUnderCondition (in grey on the diagram) illustrates that several kinds of transitions can be defined for controlling the succession of steps. Transitions also have ObservableAttributes to allow data collection and monitoring.


Back to the top