STP/IM Component/IM Builder

SOA developers build different models for the SOA platform they are 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 their integrity. In this way, it becomes necessary to have an unique, centralized instance of the Intermediate Model.

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 into a single IM Core Instance.

Third Phase: Model Update

In order to keep concept integrity, changes in the core IM instance must be tracked back to all the user models that could be affected conceptually. For example, Joe models a business process in BPMN and lets the IM builder to create a core IM instance which will allow him to create automatically other models he's interested in, such as an SCA composite application. When he changes a Component name in this model which is conceptually linked to a certain step in his business process, he would like to have this name to be updated automatically in his BPMN model.

Implementing the Builder

The first phase can be implemented whether using ATL or EMF-generated APIs. Phases 2 and 3 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. However, the ideal form to have this IM core instance is persisting it as any other file resource, which will allow the user to run other model-to-model transformations to obtain other models containing the already created concepts.

Special Considerations

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.

Testing the Builder

A set of unit tests for the IM Builder has been proposed to validate and verify the features needed for the IM builder.

Extending the Builder

At the moment, the IM builder works with the existing inwards declarative transformations. Inwards means that the transformation is from some type of model towards the IM i.e. the IM is the target model type and the plugins realizing them are named according to the form org.eclipse.stp.im.in.*. The existing ones so far are BPMN2IM and SCA2IM.

These extend the org.eclipse.stp.im.transformations extension point, defined in the org.eclipse.stp.im.builder plug-in, as any other transformation plug-in intended to work with the IM should extend as well. For example, the transformation plug-in org.eclipse.stp.im.in.sca.declarative provides the following extension:

   <extension
         point="org.eclipse.stp.im.builder.transformations">
      <transformation
            fileExtension="composite"
            id="org.eclipse.stp.im.in.sca.declarative.transformation1"
            transformationClass="org.eclipse.stp.im.in.sca.declarative.Sca2ImTransformation"
            modelCheckerClass="org.eclipse.stp.im.in.sca.declarative.ScaIdModelChecker"
            updateCommandClass="org.eclipse.stp.im.in.sca.declarative.ScaUpdateCommand">
      </transformation>
   </extension>

The extension point only demands one item, extension. It requires the following attributes:

• id
• fileExtension
• transformationClass
• modelCheckerClass
• updateCommandClass