## 3 Methodology
### Design of the Data Service Container
#### 3.1.3 Access and Invocation of Data Service  
After the data service is generated, the following questions need to be considered: How can users access and invoke the data service? How do data services perform? How does the container handle the exceptions during data service execution? To address these issues, remote access to data services, asynchronous execution, and runtime-monitoring methods are designed, as shown in Figure 4.  
(1) Remote accessing  
The sharing of data resources often involves multiple departments; for example, data centers usually have multiple subordinate units. So how to coordinate the data sharing between subordinate departments and leading departments as well as among subordinate departments is an urgent problem to be solved. The data service container designed in this paper supports deployment on multiple different service nodes, and data services in different nodes can be migrated to each other. For example, in the data container node A, there is a large-scale data service, but the related data-processing services are deployed in the container node B. In general, migrating data-processing methods is much more efficient than migrating data resources, so the data-processing service can be migrated from container node B to node A, so that users can invoke the data-processing service in container A to obtain the data they want. Figure 4: The process of data service invoking. Asynchronous execution  
Usually, the invocation of data services is a very time-consuming operation, whether the user directly requests the data resource service or invokes the data-processing service, it needs a certain execution time. Therefore, the invocation of a data service is implemented asynchronously. When the container receives the user's invocation request, the container process will prepare for the execution of the data service based on the user's input (e.g., input data files, input parameters, etc. ), such as initializing the working directory, specifying the output directory, and determining the parameter passing order. The container process then creates a separate execution process that acts as a data service. At this point, the container process can continue to process other invocation requests without blocking, thus increasing the concurrency of data service invocations. When the data service is completed, the executing process notifies the container process and passes the results of the data service execution to the container process, which then forwards the output to the user. Since the data service is run in an independent process, even if an exception occurs during the data service operation, it will not affect the container process, thus ensuring the stability of the data service container. In order to ensure the successful execution of data services, it is necessary to monitor the execution process of data services. The runtime monitoring of data services is the responsibility of the monitoring process. For the stability of the data service container, the monitoring process is also an independent process created by the container process, which is specifically responsible for the monitoring and exception handling of the execution process of the data service. After the data service is started, the monitoring process first checks the input of the data service, such as checking whether the input data organization meets the requirements and whether the input control parameter is an invalid value. The monitoring process then continues to monitor for exceptions during the execution of the data service, such as data I/O exceptions (such as errors in reading and writing data), timeout exceptions (such as long waits caused by processing large data sets), and runtime exceptions (such as manipulating the wrong memory address in the code).