# Automatically Injecting Robustness Statements into Distributed Applications
## 3 Proposed Approach for Improving Remote Calls
### Remote Call Identification  
To identify remote calls within Java source files, the code is parsed and analyzed using the JavaParser library. This library constructs an Abstract Syntax Tree (AST) [37], a hierarchical structure that represents the code, with the root node representing the entire file and all other elements as child nodes. This approach provides a comprehensive overview of the source code's structure.  
To facilitate code inspection, the VoidVisitorAdapter class from JavaParser was employed, which enables the definition of a custom Visitor class designed to search for specific properties within the source code. The visit() method implemented in the Visitor class accepts two parameters: the type of object being examined (e.g., interface declaration, method declaration) and a container for storing the retrieved data.  
The remote call identification phase comprises three steps: (i) extracting all classes implementing an extension of the Remote interface; (ii) analyzing the variable declarations and finding all instances of the types identified in the previous step; (iii) examining method calls to identify all invocations that correspond to remote calls. The Remote interface acts as a marker for interfaces whose methods can be invoked from a different JVM. Any object identified as remote must directly or indirectly implement this interface. Consequently, only methods declared within a remote interface (i.e., one that extends java.rmi.Remote) can be invoked remotely.  
For the first step that identifies classes implementing at least one remote interface, a Javaparser visitor VoidVisitorAdapter<HashSet<ClassOrInterfaceDeclaration> is used. This visitor traverses the source code AST, and retrieves the list of implemented interfaces by invoking the getImplementedTypes() method on the AST nodes. Subsequently, all interfaces extending Remote are filtered and added to the HashSet.  
Figure 1: Overview of the three main phases of the proposed approach: in the first phase, the source code is parsed to locate remote calls (Section 3.2). Next, the identified calls are analyzed to ensure data consistency, and the code is transformed to support parallel execution and fault tolerance (Section 3.3). The final phase involves updating the application’s dependencies (Section 3.4).  
In the second step, a visitor VoidVisitorAdapter<HashSet<VariableDeclaration>> traverses the AST and inspects all variable declaration statements. If the declared type is found within the HashSet from the previous step, the corresponding instance is tracked by adding it to the visitor's HashSet.  
In the final step, all method invocations on tracked instances are assessed by evaluating the MethodCallExpr expressions associated with such instances. For each identified MethodCallExpr, a series of operations are performed to determine the type associated with the method call. This aims at tracing the call's origin and identifying the invoked method. If the invocation corresponds to a method of a remote interface, it is then classified as a remote method call. Once identified, it serves as the input for the data dependency analysis and code transformation phase, as described in the following Section 3.3.