STP/IM Component/STP Intermediate Metamodel

Introduction

The STP Intermediate Metamodel (STP-IM) aims to facilitate the sharing of information between different editors in Eclipse STP. A discussion on the motivation for this is available here. A simplified sample scenario involving the IM is also available.

The intermediate metamodel is meant as a "bridge" between editors and its elements have the role of conceptual transport between different deveopment spaces. It does not aim to to offer a complete conceptual reasoning platform for SOA, its purpose is rather to capture as much common SOA design information as possible from different editors. In particular it aims to bridge the workflow and process world (BPMN / BPEL) with the architecture specification world (SCA / JBI) and the service creation world (JAX-WS etc). Due to this "hybrid" nature of the metamodel, some of its concepts cannot map directly to the corresponding concepts in each of the design spaces it aims to unite. This is unavoidable and in fact desirable in order to attain a higher-level set of abstractions that can more easily map to different specifications.

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

STP Intermediate Metamodel

Presentation

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

Overview

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.

Description

StpIntermediateModel

This is the root element of the metamodel. Only one instance of this element will be created. This element will allow the traversal of other model elements and its direct children are ProcessCollection, ServiceCollection and ServiceBinding.

ProcessCollection

This is a container for processes defined with different editors in STP. There will be at most one instance of this element.

ServiceCollection

This is a container for services defined with different editors in STP. There will be at most one instance of this element.

Resources

• Model Archive (.ecore + diagram) File:Stp-model.zip
• STP Internal Model Discussion
• sample scenario involving the intermediate meta-model