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.
Difference between revisions of "STP/IM Component/STP Internal Model Discussion"
| Line 19: | Line 19: | ||
== Consistent Representation in STP== | == Consistent Representation in STP== | ||
It is desirable that there be a consistent representation of the main artefacts created or used in Eclipse STP. A Service for instance should be available to architects and developers using either editor / technology. In particular, a service appearing in the logical architecture designed with SCA should be rendered "accessible" in the JBI editor or indeed in the BPMN or BPEL editors. It should be "same service" that is used everywhere across STP. We should aim to have minimum redundancy in the design process. | It is desirable that there be a consistent representation of the main artefacts created or used in Eclipse STP. A Service for instance should be available to architects and developers using either editor / technology. In particular, a service appearing in the logical architecture designed with SCA should be rendered "accessible" in the JBI editor or indeed in the BPMN or BPEL editors. It should be "same service" that is used everywhere across STP. We should aim to have minimum redundancy in the design process. | ||
| + | |||
| + | There are several approaches that can be used to ensure inter-model consistency. They are outlined in the following sub-sections. | ||
=== Model Transformation === | === Model Transformation === | ||
| + | Each STP user designs / develops using their favourite editor. Transformation capabilities are offered for conversions between models as soon as a new editor is used. Several common concepts in SCA and JBI for instance can be mapped as illustrated in the figure below. | ||
| + | [[Image:sca-jbi-example.png]] | ||
| + | |||
| + | The smiley faces represent service clients. | ||
| + | TODO: more detailed explanations. | ||
| + | |||
| + | === Common Service Repository === | ||
| + | This would imply that all services, regardless of the editor they were first created with, are available throughout Eclipse STP via a repository explorer. All editors must therefore make sure they "add" the new service to the repository. A possible disadvantage of this solution is the service interactions (e.g. orchestrations) could be lost. ['''Oisin, do you want to add more info here?'''] | ||
| + | |||
| + | === Common STP Model === | ||
| + | This would be a hybrid approach in which a common meta-model is used to hold the information that is more or less common across editors / technologies. Transformations from all individual editor models must be performed to obtain this "intermediate" representation. This approach is also similar to the service-repository approach, however it allows the addition of more information to be stored. | ||
| + | |||
| + | The figure below is a simplification of this intermediate model, showing service orchestrations as well. | ||
| + | [[Image:intermediate.png]] | ||
| + | |||
| + | == Comments == | ||
| + | I would go for the third option. --[[User:Adrian.mos.inria.fr|Adrian.mos.inria.fr]] 11:10, 21 June 2007 (EDT) | ||
Revision as of 11:10, 21 June 2007
This page aims to serve as a starting point for a discussion on the internal representation of artefacts in Eclipse STP. It is envisaged that several editors will be used separately or in coordination in order to create SOA entities and architectures. Examples of such editors include
- SCA Editor
- JBI Editor
- BPMN editor
- BPEL editor
Each editor uses its own internal (meta-)model corresponding to its underlying foundation (SCA, JBI etc).
Contents
Internal Models (e.g. SCA and JBI)
This subsection presents a very simplified and limited subset of the (meta-)models for SCA and JBI.
TODO: a few words describing the SCA model.
TODO: a few words describing the JBI model.
Consistent Representation in STP
It is desirable that there be a consistent representation of the main artefacts created or used in Eclipse STP. A Service for instance should be available to architects and developers using either editor / technology. In particular, a service appearing in the logical architecture designed with SCA should be rendered "accessible" in the JBI editor or indeed in the BPMN or BPEL editors. It should be "same service" that is used everywhere across STP. We should aim to have minimum redundancy in the design process.
There are several approaches that can be used to ensure inter-model consistency. They are outlined in the following sub-sections.
Model Transformation
Each STP user designs / develops using their favourite editor. Transformation capabilities are offered for conversions between models as soon as a new editor is used. Several common concepts in SCA and JBI for instance can be mapped as illustrated in the figure below.
The smiley faces represent service clients. TODO: more detailed explanations.
Common Service Repository
This would imply that all services, regardless of the editor they were first created with, are available throughout Eclipse STP via a repository explorer. All editors must therefore make sure they "add" the new service to the repository. A possible disadvantage of this solution is the service interactions (e.g. orchestrations) could be lost. [Oisin, do you want to add more info here?]
Common STP Model
This would be a hybrid approach in which a common meta-model is used to hold the information that is more or less common across editors / technologies. Transformations from all individual editor models must be performed to obtain this "intermediate" representation. This approach is also similar to the service-repository approach, however it allows the addition of more information to be stored.
The figure below is a simplification of this intermediate model, showing service orchestrations as well. File:Intermediate.png
Comments
I would go for the third option. --Adrian.mos.inria.fr 11:10, 21 June 2007 (EDT)