# Automatically Injecting Robustness Statements into Distributed Applications
## 1 Introduction  
Distributed applications are crucial in many commercial, scientific, medical, and engineering fields; however, their development presents many more challenges than centralized ones, mainly due to network delays, faults, potential attacks, performance, etc. [1]. Distributed applications often use a mechanism such as Java Remote Method Invocation (RMI), or similar ones in other programming languages, i.e., a blocking call, to simplify the code that calls a service on a remote server. In a distributed system, components spread across the network can be affected by communication delays, which deteriorates performance [2; 3]. Additionally, the potential inadequate management of exceptions and failures during client-server communication can severely compromise the resilience and robustness of distributed applications, creating critical failure points [4]. The blocking of remote method calls cannot handle delays or disruption on the distributed service on its own. Moreover, some solutions based on simple RMI expose further vulnerabilities [5; 6; 7]. Sure, advanced solutions have been suggested to better face possible communication delays and service unavailability, such as the design of pattern timeouts, circuit breakers, etc. [8]. Moreover, it could be that the developer knows that some service execution is long enough to require an asynchronous call; then, e.g., messaging solutions are used [9], or ad hoc integration is required due to its characteristics, e.g., with a blockchain [10]. Nevertheless, blocking calls and RMIs are widely used and recent studies show the usefulness of RMIs, e.g., in cloud systems like Amazon Web Services in other cloud computing environments, in enterprise solutions, in legacy systems, etc. [11; 12; 13]. As an example, in a cloud-based e-commerce platform, services like inventory management and payment processing use RMIs. Then, due to network delays, responses can be slow, causing performance issues and order confirmation delays. Moreover, poor exception handling may result in critical errors, affecting the way users can interact with the distributed system. Overall, the persistent use of blocking calls, like RMIs, underscores the need for improved resilience in distributed applications, as these calls struggle with the management of delays and failure scenarios, ultimately compromising system robustness. To address these limitations, this paper aims to provide an approach and a support tool that analyzes distributed applications to find the use of simple remote calls (such as RMIs) and substitute them with a more advanced fragment of code that, while handling the remote call, additionally takes into account delays, faults, service disruption, etc. Simple remote calls have been found by tracking all calls to methods that were in classes implementing the Java Remote interface. While the initial remote call is a blocking one, we introduce an asynchronous call to manage network delays and faults. This has the benefit of making the application parallel, hence making it better equipped to be reactive. Of course, the necessary code for synchronization and guarding will be inserted to have the correct execution of data dependent statements. Distributed systems can significantly take advantage of parallel execution to optimize their performance [14]. While libraries for supporting the development of distributed and parallel applications exist for many languages, including both Java and C++ [15; 16], they typically require developers to manually identify which remote calls should be parallel and use appropriate APIs to initialize, launch, and synchronize other execution threads. Our approach, instead, while avoiding blocking calls, generates parallel versions of the source code for such calls, freeing developers of such issues, while also providing them with the source code of the accurate transformation. Relevant related work has aimed to automatically parallelize executable code, achieving significant performance enhancements [17; 18; 19].