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/IM Builder"
(→STP-IM Building Model) |
|||
| Line 2: | Line 2: | ||
Also, there's also the requirement of making this whole process of having this unique instance updated at all times, reflecting changes in all models, but in a way that is transparent to user. The Eclipse platform offers the concept of builders, which allow to craft a build process and run it after certain events, such as clicking the build button or saving a file (if autobuild is on). | Also, there's also the requirement of making this whole process of having this unique instance updated at all times, reflecting changes in all models, but in a way that is transparent to user. The Eclipse platform offers the concept of builders, which allow to craft a build process and run it after certain events, such as clicking the build button or saving a file (if autobuild is on). | ||
| + | |||
| + | The builder will be developed in the org.eclipse.stp.im.builder plug-in. | ||
==STP-IM Building Model== | ==STP-IM Building Model== | ||
| Line 8: | Line 10: | ||
[[Image:STP-IM_Building_Model.png]] | [[Image:STP-IM_Building_Model.png]] | ||
| + | ===First Phase: Model-to-Model Transformations=== | ||
Whenever the build process is triggered for these models, an interim instance of the IM is created for each one, using [[STP/IM_Component/Transformations | model-to-model transformations]] with ATL. | Whenever the build process is triggered for these models, an interim instance of the IM is created for each one, using [[STP/IM_Component/Transformations | model-to-model transformations]] with ATL. | ||
| − | In the second phase, the interim IM instances are consolidated. | + | ===Second Phase: Model Consolidation=== |
| + | In the second phase, the interim IM instances are consolidated. This can be implemented in several ways. Below are some of the considered approaches. | ||
| − | + | * '''ATL'''. Write a consolidation transformation; it would take two models as input (the core instance and the interim instance), merge them and produce one as output (the updated core instance). However ATL is a tool for model transformations, and although it can do the job, it is not what it was conceived for. | |
| + | * '''EMF-generated java APIs'''. Load the existing core instance, update it with the concepts of the interim instance and save it. | ||
| + | * '''EMF Query'''. Use the UPDATE statement un keep an updated copy of the core instance. | ||
| + | * '''Teneo/CDO'''. Work the core instance as a model repository, possibly stored in a relational format. | ||
Revision as of 20:55, 1 July 2008
When a SOA developer starts building different models for the SOA platform he's trying to build, whether it is from the business or components architecture points of view. In order to keep the integrity of the modeled concepts, the developer transforms all his models into a single modeling notation; STP-IM. However, this approach will generate several IM instances, perhaps with repeating concepts and risking the integrity of the concepts. In this way, it becomes necessary to have an unique, centralized instance of the Intermediate Model.
Also, there's also the requirement of making this whole process of having this unique instance updated at all times, reflecting changes in all models, but in a way that is transparent to user. The Eclipse platform offers the concept of builders, which allow to craft a build process and run it after certain events, such as clicking the build button or saving a file (if autobuild is on).
The builder will be developed in the org.eclipse.stp.im.builder plug-in.
STP-IM Building Model
The following diagram depicts an example on how the proposed build process would work. A SOA developer is building a composite application supporting three different business processes; first, he models each one of them in a BPMN model, and then he develops an SCA model to design the application.
First Phase: Model-to-Model Transformations
Whenever the build process is triggered for these models, an interim instance of the IM is created for each one, using model-to-model transformations with ATL.
Second Phase: Model Consolidation
In the second phase, the interim IM instances are consolidated. This can be implemented in several ways. Below are some of the considered approaches.
- ATL. Write a consolidation transformation; it would take two models as input (the core instance and the interim instance), merge them and produce one as output (the updated core instance). However ATL is a tool for model transformations, and although it can do the job, it is not what it was conceived for.
- EMF-generated java APIs. Load the existing core instance, update it with the concepts of the interim instance and save it.
- EMF Query. Use the UPDATE statement un keep an updated copy of the core instance.
- Teneo/CDO. Work the core instance as a model repository, possibly stored in a relational format.