BRINGING CURRENT PROGRAMMING LANGUAGES TO CLOUD

Ravjot Singh
Computer Science
Guru Tegh Bahadur Institute Of Technology, New Delhi
ravjot28@gmail.com, +919540140052

Abstract - Shifting present Applications and Programming Languages to the

Cloud without any changes, will not be efficient and realistic as these
Applications and Languages were developed on the basis of Desktop
Environment. But in cloud, users have a dummy terminal with no hardware. So
it is impossible for dummy terminal to handle these applications and languages.
Remedy to this is to bring the libraries and classes to the cloud, which is
mandatory for the operation of the applications and languages. These libraries
and classes will be invoked on the client’s demand and build the code. For
executing the code or application an intermediate file is generated to simulate the
code or application on client’s demand. In addition database query and socket
programming is also supported to the client’s code while executing the code in
cloud using WebGL technology to maintain desktop environment.
Keywords – Multi-Language Support, RLCI (Remote Libraries and classes
Invocation), DQS (Database Query Service), SS (Socket Service), Simulated
Output.
Cloud Computing is at the doorsteps and is a revolution, to the, IT world and clients
or user linked to it. Computer users and developers are dependent on single or
multiple languages or applications to achieve their respective tasks. To shift them to
the Cloud, it can only be possible, if they get their application or language on cloud
with same environment that they get in desktops.
At present researchers and companies are aiming to re write the applications in web
languages like JavaScript, JSP, .Net etc., which is costly and at the same time prone to
the bugs which can be alarming at real time usage. Re writing applications in web
languages will cut down the features like security, GUI, efficiency etc., which were
present in Desktop environment.
So, this technical paper focuses in shifting the current languages and applications to
the cloud with minor changes and maintain the desktop environment, which will make
users and developers comfortable while shifting to cloud. Applications are the output
or result of a programming language, so shifting programming languages to the cloud
will solve the problem.
Complete problem is divided into two sectors: Compiling Code Sector and
Executing Code Sector. Compiling Code Sector deals with supporting the core
libraries and classes to the client’s code and compiles it to get an executable file,
which can be executed anywhere and anytime on cloud. Executing Code Sector deals
with simulating the client’s code and maintaining the desktop environment at the
same time.
 Compiling Code Sector contains three major modules: RLCI (Remote Libraries and
Classes Invocation), DQS (Database Query Service), and SS (Socket Service).
RLCI (Remote Libraries and Classes Invocation)

Client Server
Interface

LC-C LC-S/LC-S

RLCI-G (RLCI Guide)

Figure 1. Architecture of RLCI

The main objective of RLCI is to provide the core libraries and classes to the user’s
code, on user’s demand for building the code. In addition it also provides the support
of external APIs that the client uses to accomplish tasks in the client’s code.
Server is collection of servers corresponding to respective languages for supporting
core libraries and classes to client’s code. These servers can be globally common or
dedicated to specific cloud providers.
LC-C is the copy of the portable files, which supports the client’s code by providing
core libraries or classes according to the language used and also APIs to the code.
RLCI-G passes the request from client to server and response from server to client.
RLCI-G contains internal cache, which copies the portable files, which can be used in
future by the clients. LC-S is the dynamic conversion of the API’s files to the portable
files, which can be easily attached to the client’s code.

LC-C Code

Compile Built Code

Figure 2. Client Side Code Compilation

Code (Before Compilation) Built Code

Public class A{ <class> A

Public static void main(String as[]){ <.main>
System.out.println(“Hello”); <Java.lang>p(hello)</Java.lang>
 //Database Query <DQS>…</DQS>
//Socket Programming <SS>….</SS>
} </main>
} </class>

DQS (Database Query Service)

Database Query Service is triggered whenever DQS tag is encountered during
executing the code. During executing the code the Database query is extracted and
sent to DQS server, which accesses the user’s database file with authenticated access
and process according the type of database i.e. MySQL, MSAccess or DB2.

Client

DQS Messaging Center (Similar to MoM Server)

MSAccess Oracle DB2 MySQL

Figure 3. DQS Architecture

SS (Socket Service)
Similar to DQS but it is triggered whenever SS tag is encountered during execution of
the code. Here the socket statements are extracted and executed dynamically. The
connection between the clients are made using multi connection server, which sends
encrypted messages according to the socket command, to the clients. Each client is
given an identity and a secret key to get access to send messages or data streams to
the specific client.

Client 1 Post Box Post Box Client 2

Figure 4. SS Architecture

Post Box is the server, which are the intermediate servers to link a connection route to
the clients. Each client is assigned to a specific Post Area, which is based on the
geographical location of the users. If 2 clients belong to same Post area then RLCI-G
is used instead of Post Box servers to inter communicate between the clients.
Executing Code Area
Here the portable built executable code is parsed to the simulator using a bridge,
which maps the code to the simulator using an intermediate language for GUI purpose
only. The desktop environment is maintained using WebGL, which renders the GUI,
same as it was in desktop. Using RLCI language features are maintained and using
Executing Code Area Desktop GUI environment is maintained.

Built Code Bridge Simulator

Figure 5. Executing Code Area Architecture

Experiments
DQS and SS were tested in a private cloud to observe the delay for processing.
Bandwidth was 256 Kbps and for intermediate messaging server Gmail was used.
Laptop, netbook, iPod, Desktop, iPad and Nokia mobile phone were used for testing.
Programming Language: J2SE Database: MSAccess
Query: Insert Query Round Trip: 13 sec.
Programming Language: Objective C Database: MySQL
Query: Select Query Round Trip: 12.4 sec.
Programming Language: Objective C (iPod) Database: MSAccess
Query: Delete Query Round Trip: 11.7 sec.
Programming Language: J2ME Database: MSAccess
Query: Insert Query Round Trip: 12 sec.
Programming Language: Perl Database: MSAccess
Query: Select Query Round Trip: 12.5 sec.
Programming Language: J2EE Database: MSAccess
Query: Insert Query Round Trip: 12.1 sec.
Conclusion
This approach supports all languages and the developers can compile their codes
using this technology and can achieve built executable code, which can be directly
executed in cloud anytime. No re writing of the code is required and the bugs are
reduced as the core libraries and classes are included of the language. Clients feel
comfortable as the environment is familiar to them and no new language is
introduced. External APIs, Database Query and Socket are supported.