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

STP/IM Component/Transformation Approaches/To SCA

Currently there's only one approach realizing the model transformation from STP-IM to SCA, implemented in the org.eclipse.stp.im.out.sca plug-in, using the EMF-generated APIs from both STP-IM and SCA metamodels.

The general rules are as follows: For each process in the IM, create a composite service and the inner components containing the services taking part in the process (orchestrated by a component);

  • Create an orchestration component exposing the same service and connects the composite service to the orchestration service which has the same name as it is the SAME service).
  • For each of the services invoked by this process, create components with the respective services and connect the orchestration component to these services.
    • if the process step relates to a service, get it and create the appropriate artefacts if the process step does not CURRENTLY relate to a service, CREATE a mockup service to give the architect the option for creating one or not in an easy manner. This policy could easily change when we switch to declarative rules.
    • Create a SCA component with the service
    • Create a service reference in the orchestration component for this service and connect it to the newly created component service.
  • To finish up, the SCA composite must be persisted in the workspace (using an identical file name to the SCA one, with a changed extension).

Back to the top