Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "STP/IM Component/STP Intermediate Metamodel"

(Description)
(Description)
Line 11: Line 11:
  
 
=== Description ===
 
=== 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'', Processes by ''ProcessCollection'' and ''Properties'' are defined by ''PropertyDefinitions'' contained in the ''PropertyDefinitionCollection''.
+
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 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 (including Contracts - Thanks to David Bosschaert for pointing out the need for contracts). The fact that Properties can be extended to different types is illustrated by the three property types already identified in the model (in grey). 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.
+
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.
 
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.

Revision as of 08:44, 6 September 2007

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