STP/IM Component/IM Builder
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, which uses the
org.eclipse.core.resources.builders extension point.
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 Compare / EMF Query. When one of the user models change, its corresponding IM interim instance is created again and it is consolidated to the core IM instance again. To update other user models that might be affected in the operation, this interim IM instance compared to its previous state from local history using EMF Compare; if any change is found it will be tracked back to all user models using the UPDATE statement, to keep them all updated.
- Teneo/CDO. Work the core instance as a model repository, possibly stored in a relational format.
Picking the right choice is not only dependant no how easy it is to implement or which one gives the most value to the user. Below are some key scenarios to consider.
- The user creates a new STP model from scratch (whether using BPMN, SCA or other model editors), and it's added to the core IM instance.
- The user creates a new STP model starting from the concepts already defined (e.g. processes, services, service bindings, etc.) checking out the core IM instance.
- The user modifies one of the existing STP models; adding, updating and deleting elements. These changes will be committed to the core IM instance.
- The user opens a model whose elements have been changed by another model, and therefore has to be updated to reflect the latest changes from the core IM instance.
As it can be seen, these concerns match the basic operations offered by file repositories such as CVS or SVN. The chosen solution should provide capabilities to address these concerns.