Eman Hossny

The AAG module aims to provide a solution for cloud application portability problem. One approach to solve application portability problem over PaaS model is to write applications using a generic API
and implement an adapter for each specific PaaS platform. These adapters aim to translate generic API calls into specific PaaS calls. The main problem in these adapters is that they have been implemented manually. Whenever a specific PaaS API has been updated, its adapter requires refactoring or re-implementation (i.e., API synchronization problem).

So, the main objective of the AAG module is to automatically generate a generic API adapters' code. The semantic annotations of a generic API and a set of specific APIs are defined in a pre-built ontology. These semantic annotations have been used in the process of automatic code generation.

The full algorithm of the AAG module inculdes the following methods:

1. Generic Methods List 
2. Automatic Code Generation
3. Generate Code for Detection Path

1. Generic Methods List

This method provides a list of generic methods that are defined in the pre-built ontology. This generic methods list is retrieved by executing a SPARQL query on the pre-built ontology. This SPARQL query provides all instances that are defined under the GenericAPI concept, as well as, the semantic annotations of the inputs and output of each instance. The returned instances would represent the generic methods which their source codes need to be generated.

2. Automatic Code Generation Method

The pseudocode of the automaticQueryGeneration method is illustrated in Algorithm 1. The main concept of automatically generating a new SPARQL query based on a given one is to divide the given query into two strings. For example, if the given query is the initial SPARQL query which is represented in Figure 2, then the two strings would have the following contents;

Part1 = ``select DISTINCT * where { ?meth1 scro:hasSemanticInput
scro:semanticParam[startPoint]. ?meth1 scro:hasProvider scro:providerName''

Part2= ``?meth1 scro: hasSemanticOutput scro:semanticOutput}''

The lastMethodName variable is extracted from part2 (e.g., “?meth1”). The integer number in the lastMethodName is parsed and stored in the count variable (e.g., count=1). This count represents the path depth of the given SPARQL query. Concatenate to part1 the value of the lastMethodName with the relation “hasSemanticOutput” and a value “?out”+count (e.g., “?out1”). To add a new specific method, the count is increased by one (e.g., count=2). Concatenate to part1 two relations for the new specific method

“?meth”+count (e.g., “?meth2”) as follows; (1) “hasSemanticInput” with value (“?out”+(count-1)) (e.g., “?out1”) and (2) “hasProvider” equals to the given specific PaaS provider name.

Update part2 to include the new specific method (e.g., “?meth2”) instead of the lastMethodName. The new query represents the concatenation of both part1 and part2. Finally, this newly generated query is returned from the automaticQueryGeneration method.

2. Generate Code for Detection Path

The pseudocode of the generateCode4DetectionPath method is clarified in Algorithm 2. As shown in this Algorithm, we are looping on the detectionPath and generating code for the calling statement of each specific method in the detectionPath. The generated code for each specific method has been appended to a buffer. Lastly, a code for the return statement of the generic method has been generated and appended to the buffer which is the output of the generateCode4DetectionPath method.