## 6 ArTIC-MS Use Case Specification
### Composition and Deployment of a Federated Simulation Application  
This section illustrates the use case in which the federation is composed by heterogeneous MSaaS infrastructure based on the RA. Specifically, the _service provider_ is responsible for creating M&S services (and also MSaaS applications exported as CSAR complex services, as discussed in Section 6) by using the ArTIC-MS platform (left part of the figure). Differently, _Simulation Developers_, which uses a non-TOSCA MSaaS implementation, needs to build a MSaaS simulation by orchestrating local M&S services with TOSCA-based M&S services provided by the service provider. The scenario is specified as follows:  
_Precondition: the Service Provider (SP) created a set of M&S services and MSaaS applications, which are available as CSAR packages in ArTIC-MS (see Figure 11--steps 1 to 4)._  
1. the _Simulation developer (SD)_ logs into the MSaaS platform and executes a query to identify the available M&S services. As the query makes use of the API interfaces provided by each partner's registry, the \(SD\) is able to discover local services along with the TOSCA-based services provided by the \(SP\) (see Figure 11, steps 5);
2. SD identifies the set of needed services (see Figure 11, step 6). In this respect, SD identifies \(N\) services, where \(N_{L}\) are available in the local infrastructure, \(N_{E}\) services are provided by remote partners via a URI endpoint and an interface specification (e.g., WSDL, etc.); finally, \(N_{R}\)s are available from SP's remote services repository as CSAR packages, being \(N=N_{L}+N_{E}+N_{R}\). In this respect, according to the business model assumed to be adopted by the SP, a subset of the \(N_{R}\) (i.e., \(N_{R-REM}\)) services might need to be deployed onto the SP infrastructure, while the remaining \(N_{R-LOC}\) can be retrieved and deployed onto the SI infrastructure, being \(N_{R}=N_{R-REM}+N_{R-LOC}\)
3. SD retrieves from the local repository the locally available \(N_{L}\) services;
4. In order to ask for the deployment and execution of the \(N_{R-REM}\) services that need to be directly managed by the SP's infrastructure, SD forwards a request to the ArTIC-MS _simulation management and execution control_ service (see Figure 11, step 7);
5. SD retrieves the CSAR descriptions of \(N_{R-LOC}\) M&S services from the ArTIC-MS service repository (see Figure 11, step 8);
6. SD translates the TOSCA template contained in the CSAR package to a vendor-specific template via the _Adaptation Service_ (see Figure 11, step 9);
7. SD uses the _composition service_ to create a template that describes the given MSaaS application, by composing the retrieved services (see Figure 11, step 10);
8. SD configures the required parameters of the various M&S services;
9. SD configures the composition to make it possible to invoke the operations provided by the endpoints of the remote M&S services;
10. SD develops and configures a _deployment description_ suitable for the underlying orchestration technology;
11. the _deployment description_ is given as input to the _deployment service_ in charge of executing the automated deployment of the simulation (see Figure 11, step 11);
12. The MSaaS application is finally ready to be used by the simulation end user (SU).
13. During the simulation execution, the appropriate interaction between the two cooperating MSaaS infrastructure is managed through the simulation management and execution control (SMEC) service (see Figure 11, step 12);