Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
STP/IM Component/STP Intermediate Metamodel
Contents
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. Most of the elements of the IM are currently loosely 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 development spaces. It does not aim to offer a complete conceptual reasoning platform for SOA, its purpose is rather to capture as much common SOA design information from different editors as possible. 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 - IM.
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 Endpoints. 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 to indicate that this is an area for potential future extensions. 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: 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 abstract 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 only 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 concerned with creating stand-alone services (as opposed to assemblies and compositions).
- ServiceBinding: corresponds to a binding through which services can be exposed (e.g. HTTP, JMS or SMTP).
- Process: corresponds to a business process. A process contains steps (instances of Step) and transitions (instances of Transition) for defining how the execution should advance from one step to another. A process can also be seen as a service and this is reflected in the inheritance relationship between Process and Service.
- Step: a step is a unit of execution in a particular process. Steps are associated to services and bindings as the step's functionality can be achieved by a business service using a particular binding. Depending on the needs of particular editors, steps can be associated to services but not to bindings, if for instance an executable target is not yet envisaged. Naturally, if a process is to be used in generation of JBI artefacts for instance, bindings must be set for the steps to indicate the appropriate JBI components to be targeted. The fact that steps are not associated directly to endpoints, but rather to services and bindings, provides for much greater flexibility in choosing the right level of detail that the IM instance will express at a particular point in time. Steps are linked using transitions and they contain references to the transitions in which they take part.
- Transition: associates a source step to a target step and can potentially attach a rule to make the transition conditional (in the case of the inheriting TransitionUnderCondition class). For observation purposes, transitions can contain ObservableAttribute instances whose values can be monitored.
- ObservableAttribute: a holder for monitoring information pertaining to process transitions; to be used by process monitoring tools.
Q & A
TO DO: This section lists some commonly asked questions and answers about the STP-IM.
Some recent questions and answers regarding process steps, bindings and endpoints are available in the stp-dev archives: