Skip to main content
Jump to: navigation, search

STP/IM Component/STP Intermediate Metamodel

< STP‎ | IM Component
Revision as of 17:57, 7 September 2007 by (Talk | contribs) (Description)


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. Most of the elements of the IM are currently incompletely defined. This allows a lot of flexibility in using the metamodel. In subsequent versions, based on preliminary experience with using the IM, the elements will be refined, rendering the metamodel more prescriptive.

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


The following diagram presents the EMF elements for the 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 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.


  • StpIntermediateModel: 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: a container for processes defined with different editors in STP. There will be at most one instance of this element.
  • ServiceCollection: a container for services defined with different editors in STP. There will be at most one instance of this element.
  • ConfigurableElement: a utility element that is meant to provide configuration functionalities to elements that extend it. This is essentially a collection of properties that can be set and accessed in order to provide custom functionality and store configuration parameters. The following classes extend ConfigurableElement: Service, Step, Endpoint and ServiceBinding.
  • Property: stores a pair of "key" - "value" elements. An instance of Property is contained by instances of ConfigurableElement. In order to accommodate different needs for expressing properties, specific property elements have been provided as extensions of the basic Property class. They are MapProperty for multi-value properties, BasicProperty for simple string-value properties and Contract for storing contractual meta-data (such as policies).
  • Service: one of the main entities in the metamodel, it represents the high-level concept of a "business" service, i.e. an element that provides a functionality through an interface. Given that this is a high-level concept, a separate interface element is not necessary; each service must expose an interface and their separation in the IM would not bring any benefit as ultimately this is a detail that might be handled differently in each target specification (SCA, JBI, WS-* etc). A service is owned by an Owner instance and belongs to zero or more ServiceClassification instances. Services can depend on other services and this is expressed in the metamodel by the association to "self". A service can be provided through any number of bindings (represented by ServiceBinding instances) and can expose any number of endpoints (represented by instances of "Endpoint").
  • ControlService: an extension of Service that is used to provide functionality for controlling access to business services. Control services would not provide business functionality themselves but will help in composition of business services. Several control patterns inspired by the enterprise integration patterns are available as extensions to ControlService: SplitControl, RouterControl, JoinControl and IterationControl.
  • Owner: a holder for service owner identification. One owner can own multiple services while a service can be own by one one owner.
  • ServiceClassification: a holder for information about service categories. Multiple services can be in the same category and a service can be in multiple categories.
  • Endpoint: the representation of a service enpoint. A service can have multiple endpoints. Each endpoint can be associated with a binding (instance of ServiceBinding). Although the explicit representation of service endpoints in the IM is not always necessary (as they can be inferred from pairing services with bindings in particular contexts), this can prove very useful in cases where metadata such as policies need to be explicitly associated to endpoints. In addition this provides a natural representation for editors that are concern with creating stand-alone services (as opposed to assemblies and compositions).


Copyright © Eclipse Foundation, Inc. All Rights Reserved.