# An Approach for Deployment of Service-Oriented Simulation Run-Time Resources
## 3 Motivation  
Figure 2 provides a more vivid illustration of the importance of considering the joint deployment of SRR, although there is currently little research on this topic. The figure includes training bases (TBs), edge servers (ESs), BSs, and a scheduling center located in the cloud. Software resources on ESs include MS instances and constructive members, depicted by colored circles and aircraft, respectively. To facilitate distinction, a jagged symbol is used to represent the middleware service instead of using a circle.  
Taking Figure 2a as an example, only the deployment of servers is considered without considering data dependencies between services. In this case, three ESs are deployed on BS 1, 2, and 4, with purple, green, and middleware services deployed on them, respectively. A live user submits a service request for path planning. Since all ESs do not have the corresponding instance, the task can only be completed in the cloud, where all types of services are deployed. This will remarkably increase network latency. Additionally, a live user sends a message \"Hello\" to a constructive white aircraft, resulting in two data transmissions. However, if the white aircraft and middleware are deployed together, the second data transmission can be avoided.  
The situation shown in Figure 2b optimizes the deployment of services and simulation members. The yellow service request submitted by a live user is dispatched to ES 1, avoiding huge communication costs generated by execution in the cloud. Additionally, some constructive members are deployed together with middleware, reducing user interaction costs to a certain extent. However, BS 3 and BS 5 are far away from TB A and B. Intuitively, it would be a better choice to deploy the two servers at BS 1 and 2.  
Figure 2c illustrates the joint deployment of SRR, including ESs, micro-services, and constructive members, considering data dependencies between micro-services. A live user submits a request for path planning, including two tasks, \(t_{1}\) and \(t_{2}\). Task \(t_{1}\) is scheduled to server 1, and then the output is sent to server 2 for processing the second task \(t_{2}\). It should be noted that the yellow MS instances are deployed on both server 1 and server 2. The reason \(t_{1}\) is scheduled to server 1 rather than server 2 is that the instance on server 2 has other two tasks to process and therefore has a long waiting time.  
Figure 2: Deployment schemes for different objects: (**a**) Edge server deployment; (**b**) SRSR deployment; (**c**) Joint SRR deployment.  
Another significant difference between Figure 2a-c is that Figure 2c considers micro-services, using a more complex service representation approach, DAG, whereas Figure 2a,b consider monolithic services. This is mainly caused by the granularity difference between the services that the simulation system can support and the services required by users. The performance of the micro-services architecture depicted in Figure 2c is more flexible, so it is currently the mainstream architecture for developing large systems, such as simulation systems, in both the present and future [33]. Therefore, it is important, reasonable, and practical to study simulation resource deployment based on MS architecture.