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

STP/IM Component/STP Intermediate Metamodel

< STP‎ | IM Component
Revision as of 08:44, 6 September 2007 by Adrian.mos.inria.fr (Talk | contribs) (Description)

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

Overview

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

Description

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 and Processes by ProcessCollection. There is an abstract element, called "ConfigurableElement" that defines how properties are used by any element of the model that can be configured. It is essentially a collection of "Property" instances that are pairs of keys and values. There are different types of properties as indicated by the inheritance relationship. Services have Bindings and "Enpoints". They can also exhibit interdependencies with other services (indicated by the association to -self). 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. More control elements can be added as needed in future versions of the metamodel. 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.

Resources

Back to the top