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.
STP/IM Component/Transformation Approaches/To SCA
< STP | IM Component
Revision as of 02:05, 12 June 2008 by Juanjosecg.gmail.com (Talk | contribs) (New page: 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...)
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).