Performance Analysis and Design of a Mobile Web Services on Cloud Servers

(1)

International Journal of Emerging Technology and Advanced Engineering

Website: www.ijetae.com (ISSN 2250-2459,ISO 9001:2008 Certified Journal, Volume 5, Issue 9, September 2015)

104

Performance Analysis and Design of a Mobile Web Services on

Cloud Servers

Rushi Raval

1

, Dr. Atul Gonsai

2

1

Research Scholar, 2Associate Professor, Department of Computer Sci., Saurashtra University, Rajkot, India

Abstract— Web services (WS) are used to inter connect

between mobile clients and internet. WS can be built using either Standard SOAP based WS or RESTful based WS Architecture. Researcher focuses on develop both WS with different parameters. We use SOAP + nuSOAP; RESTful applying with JSON based Web Services respectively in both of the WS. The WS are used by entirely different WS app model to communicate data context using different cloud servers. We have piloted different experimentations on both and tested on Apache (WAMP) Server, Windows Phones, as well as on Cloud servers such as Google App Engine (GAE) and Heroku. Result of research indications that the RESTful based WS is better in performance than SOAP based WS.

Keywords— Web-Services; SOAP; REST; Mobile Cloud

Computing; Windows Phone; CSV; JSON; GAE; Heroku;

I. INTRODUCTION

Web Service (WS) is a function written as computer program and developed with use of differ technologies such as, XML, JSON, REST based API placed on some local or cloud-server which can retrieved using difference standards / methods such as, HTTP, GET, PUT, POST, HEAD in another application such as a client-server architecture manner. As WSs are platform-neutral and normally data context as text-based this can design [1], run

and access on various platforms with different

technologies.

With this paper, researcher explores a comparatively new methodology for RESTful API to communicate and transfer data context from ―r-restful-client‖ as an app model to ―r-restful-ws‖ another app model using cloud servers such as, GAE and Heroku. The SOAP (Simple Object Access Protocol), XML (eXtensible Mark-up Language) and Java-Script Object Notation (JSON) are the standards which are used to interrelate with each-other over cloud computing. These types of services are very in-expensive and dynamic as well. The WSs can be applied in many different differ architecture styles and formulate as per mobile clients aspect. For e.g., RESTful is light-in-weight as related to SOAP standards and is mostly based on URL, various IT companies have used RESTful WS for their architecture such as, Amazon-(AWS), e-Bay, Yahoo pipes and Flickr.

The main focus of this paper is to Design & Analysis the Performance of a RESTful based WS app model for apps combination on cloud-server. This paper is proposed to integrate ―r-restful-client‖ / ―r-soap-client‖ apps on cloud based environment to another ―r-restful-ws‖ app on different cloud-platform / Webserver by consuming SOAP based and RESTful based WS. The coding for this determination is done in PHP language, the open-source language and best fit to IT standards as well.

II. CONTEXTUAL OF WEB SERVICES

Now-a-days, various IT enterprises and Business industries are being implemented cloud-services as their part of the organizations, since cloud computing offers several services to above kind of organisations such as, IaaS, MaaS, SaaS, DaaS and PaaS. Similarly cloud platforms offers free as well as paid model, Also cloud servers provide host Web API, Web services, and other applications model, if any. IT enterprises and business adventures do no need to think or worry about issues such as, installation of licensed software’s and / or establishment of hardware infrastructures as well.

In cloud computing environment, REST based WS are replacing SOAP WSs in communications with mobile client over cloud-server and the Internet. The term, REST views for Representational-State Transfer, RESTful mainly means each and every individual URIs (uniform resource identifiers) can be a design of some entity / object. Mobile client will get the data contexts of that entity by a HTTP (hypertext transfer protocol)-GET, User may also usage a PUT, HEAD, DELETE or POST to modification the entity, mostly live use of the services using a POST / GET method to interrelate. Hence RESTful WS can be a different manner to produce and consume WSs, whose leading benefits are such as, light-weight as for mobile client communication, high performance, easy to create web-services (no requirements of extra SDKs / Toolkits / DLLs).

(2)

International Journal of Emerging Technology and Advanced Engineering

105

REST based WSs [2] are web apps built upon the REST architectural style. They representation resources as data and operational functionality over web URLs, REST based WS characteristically map the four key HTTP methods called as ―CRUD‖ Operations such (create, retrieve, update, and Delete), below table demonstrations a representing of HTTP methods to these ―C.R.U.D.‖ operation [8].

Table 1:

Http Methods and Operational Action [8] HTTP Methods C R U D Operation

GET Retrieve a Resource

POST Create a Resource

PUT Update a resource

DELETE Delete a Resource

However, REST based WSs remains to be producing conversation concerning it’s differ way of operations, and also various different differ offers are suggested for communicate with mobile-client to cloud-servers, it delivers plenty appliances to establishments of services such as, Information based request-response services, Mobile-client to Cloud-server, Standard client-server services, and AI based services, etc.

III. PROBLEM DEFINITION

Accessing present WSs from a smart-phone based mobile client is different way compared to the standard WSs developments, as of following facets environment. A review done by Earl et al. [3] estimated how well the current mobile clients including Android, i-Phone, and Windows Phone, support the in sight of cellular network based research. According to the review, all of these mobile platforms have certain limitations. There are some challenges in accessing the Internet based Services from the existing smartphone-clients such as, connection-loss problem, direct implantation at mobile clients, limited resource problem.

In this paper, the requisite is to integrate the ―r-soap-client‖ and ―r-restful-―r-soap-client‖, on cloud servers such as, GAE and Heroku with another ―r-restful-ws‖ WS app model. The objective of this app model is to participate / consume WS app model with cloud-servers with usage of REST and or SOAP based WSs as a middle ware to send data context and providing PaaS (Platform as a Service) as on demand by the mobile users.

Though, there is no need to establish any extra virtual connection by the mobile clients on cloud server. The mobile clients (here, consider as students) use app model such as, ―r-restful-client‖ as he / she is able to consume services such as, view latest information about the stream, register themselves for future aspects, etc. This WS app model integrates these services on the mobile clients’ side as on principle systems.

IV. OBJECTIVE AND PROPOSED ARCHITECTURE FOR WS

APPMODEL

The objective of this paper is to do Performance analysis and Design of a SOAP and REST based Mobile Web service (MWS), hence design ―r-restful-ws‖ WS app model with added mash up feature and for mobile client design ―r-soap-client‖ and ―r-restful-client‖ WS app models. To achieve objective, researchers have designed above-said WS app models with SOAP based as well as REST based WSs and also use CSV and JSON format for storing data, communicate with WSs uses JSON format as light in weight and support for thin clients such as smart-phone, mobile devices as well.

Researcher has select MVC (form as Model-View-Controller) architecture style to design WSs app models, following is the MVC modules shown with their functions.

Model

―r-restful-ws‖ WS objects are the defined as a model as each entity is related to particular objects, such as Class, News / Updates, Registration, Result. ―r-restful-ws‖ WS app model has also UI to interact with data context which is retrieved from mobile clients (user as students) and also added mash up features such as add, update and delete News / Updates and results for stream wise, and administrator can also send an e-mail to particular streams’ students.

View

―r-restful-client‖ and ―r-soap-client‖ is used to represent the front-end to mobile clients. To create WS app models’ UI for front-end using HTML, CSS, JavaScript (JS), and for server side communication using a PHP.

Controller

These are the methods / classes that are used to signify the appropriate actions when mobile users interrelate with ―r-restful-client‖ and or ―r-soap-client‖ WS app model.

(3)

International Journal of Emerging Technology and Advanced Engineering

106

V. IMPLEMENTATION OF WSSAPPMODEL

The goal of this paper is to design WSs app model for Mobile-users, for authenticate the mobile users UI; Researcher included the design with a present Windows-phone app as native app model and also design for web-work app model to support other mobile clients as well, for mobile users (college students), called ―r-restful-client‖. The app is re-applied with the mobile client design on Windows Phones. By use of this app, student (as a user) can check their class, college, course information, check the latest news information course wise as well as check their results from various departments and also able to getting news of their dept. via email only for those students who are registered. Figure 1 is some screenshots of the r-restful-client on Windows.

Main Screen (user as student)

Registration Screen (user as student)

Figure 1: Mobile client UI of “r-restful-client “on Windows Phone

The structure of mobile client app model can be circulated into three layers such as, User-Interface (UI), controller method and cache-manager. The U I layer has implementations like, windows native UI, and android

rooted-browser UI. Figure 3, 4 and 5 show how they look

like on the mobile user devices. Figure 2 demonstrations the design of all the implementations. The controller method shows a dynamic role amongst the middle ware, U I and cache-manager. The controller method calls the UI and gets the records from the ―r-restful-client‖ or cache-manager as local storage. If sometime internet is not available, the controller method permits cached records to the U I components. Then after, it presents the REST based WS app model to retrieve data from the middle-ware.

The cache-manager at that point retains the current acknowledged records on a local storage file system (device memory consider as local storage).

Figure 2:Implementation on Native UI

News Screen (user as

students)

Streams Screen (user as students)

Result list (user as students) Result Screen (user as

students)

(4)

International Journal of Emerging Technology and Advanced Engineering

107

Registration Screen (user as students)

News Screen (user as

students)

Result list (user as students) Result Screen (user as

students)

Figure 4: Demonstrations of Android based Web-Work App Model

To give mash-up concept to the WS app model, researcher have also created ―r-restful-ws‖ WS app model for the administrative purpose, with use of the ―r-restful-ws‖, administrator can able to accomplish the following task:

 Administrator has to login to access the mash up

content.

 Administrator can see the list of registered students and also able to download that list from mobile clients as well as from web browser.

 Administrator can add, edit, and delete the News /

Updates regarding to the college courses.

 Administrator can also authorize to send an email to the students via stream wise who are registered via the client‖ Windows Native app and ―r-restful-client‖ Android Web app.

 Administrator can add, edit, and delete the Results

according to the stream wise.

List of students screen (user as Administrator)

News Screen (user as Administrator)

Email to students (user as Administrator)

Results Screen (user as Administrator)

Figure 5: Screen displays of “r-restful-ws” WS app model with mash-up features

Mobile clients are aimed from differ perspective; researcher has presentation this design as in following figure 6, Where mobile clients are using any kind of mobile device likewise, Windows-Phone, Android-Phone, and laptop devices, moreover, they are coupled through the middle ware which is hosted on to the cloud server and there request-response are generated in JSON format:

(5)

International Journal of Emerging Technology and Advanced Engineering

108

VI. PERFORMANCE ANALYSIS AND TESTING OF WSS APP

MODEL

We implement SOAP & REST based WSs and deployed them on the Apache (WAMP) web server, GAE, and Heroku. Apache WAMP server runs on DELL I 5110x compatible Laptop with 2.30 GHz Intel® Core™ i3-2350M processor with 4-GB RAM, where Windows 7 Ultimates with SP1 as OS operates, and for mobile phone apps (mobile client) implemented using MS Silverlight for Windows Phone Toolkit (MSS-WPT), Windows Phone 7.0 and runs on Windows Phone OS 7.1 Emulator. GAE and Heroku service was taken on free quota basis to deploy and test our WS app model.

Using REST WS App Model for Native UI:

To build REST WS for mobile client, Researcher has used VS-2010 IDE. REST based web services are designed using REST API with C# as native language and Windows Phone SDK 7.0 version.

Using REST WS App Model for Web-work UI:

To build REST WS, Researcher has used Notepad++ (Freeware) IDE. REST based web services are designed using REST API with PHP server-side language.

For consuming REST based WS in Android mobile platform and any other mobile clients such as, laptop, Researcher has also developed REST WS with Web-Work UI support. This WS app model created and hosted from a cloud platform that fetches data to and forth from cloud web services. For storing data context, Researcher has used JSON and CSV format, for data communication and request-response used JSON format. Furthermore, it uses REST web services that is sending and receiving data to and forth using http request. It uses POST request for submitting students’ details, to get notified by mail information / data displayed to mobile-user is actually, JSON data, which has been decoded using PHP script.

For consuming SOAP based WS with Web-Work UI support, researcher has also developed SOAP WS app model, r-soap-client it uses SOAP web services with nuSOAP API that calls SOAP registered method by calling soap client object's call method that accepts argument as an array. This WS app model use JSON as request response, data display to the mobile clients.

Following segment defines the two implementations on cloud server as middle ware that can be deployed on GAE [5] and HEROKU [6] as well. Table-2 lists their key properties.

Table 2:

Comparison for GAE and Heroku Cloud Platform Attributes GAE [5] HEROKU [6]

Service Platform Fully Automated PAAS Key technology SOA

(Service-oriented Architecture)

SOA

Service model Web application, WS container Web application, WS container Service access interface Command line, GUI (Google App Engine Launcher) Command line (Heroku Toolkit) Auto-scale option Free, Billing option available Web DYNO, Billing option available Other supportive services Data store, Email, URL Fetch, App Logs, Large Data, BlobStore Git repository, GitHub, Email, Database, Application Logs Programming language support Python, PHP, Java, Go Ruby, PHP, Java, Node.js, Scala, Clojure, Python, Go Base Charge model Resource, Google API Resource, Add-ons Tradeoffs Direct deploy

with Google App Engine

Must deploy with Git

Consuming REST based and SOAP based WSs over the middle ware [7], in this test case compares the above associated with designed r-restful-client and r-soap-client WS app model interactions as a client. r-restful-ws provide both SOAP and RESTful WS interfaces for educational service. The ―r-restful-ws‖ WS return result in either JSON or CSV format for registered students’ data and for other operations such as Results, News/Updates return result in JSON format. The tested WS is as following:

(6)

International Journal of Emerging Technology and Advanced Engineering

109

 About us, this returns information about the app.

 Stream as ―BCA, BBA, or MSC‖, which returns a list

of contents match with the keywords.

 Register a student data, which stores at ―r-restful-ws‖

WS and returns a responsive message at client side.

 News/Updates as ―BCA, BBA, or MSC‖, which

returns a list of updates/news related to match with the keywords.

 Results as ―MSC, BCA, or BBA‖, which returns a list

of results taken by the relevant stream to match with the keywords.

For Administrative perspective:

 Check Registration data and also able to download

those students data who have registered via Native App or Web App either in JSON or in CSV format.

 Add, Update, and Delete News/Updates.

 Email the latest News/Updates to the students

respective to particular stream.

 Add, Update, and Delete Results.

The maximum page load time is 6000 (MS) and the maximum time to first byte is 3000 (MS). The middleware is runs on the local web server, GAE and Heroku.

The size of the JSON result for students’ data is about 5.05 KB and the size of the CSV result is about 2.71 KB.

The load originator directs HTTP request based on defined virtual user profiles which are as following:

Table 3:

LoadWebUI test case 1 Configuration for r-restful-client_local [4] User Virtual user group

User count 1

Scenario Scenario1_ r-restful-client_local Workstation Master Browser Chrome Start Delay 0 MS Connection Speed Maximum speed Correct Host field Enabled

Load profile Steady load Quality of

Service

Maximum Page Load Time 5000 (MS) Maximum Time to First Byte 2000 (MS)

Table 4

LoadWebUI test case 2 Configuration for r-restful-client_local User Virtual user group

User count 10

Scenario Scenario1_ r-restful-client_local Workstation Master Browser Chrome Start Delay 0 MS Connection Speed Maximum speed Correct Host field Enabled

Load profile Steady load Quality of

Service

Maximum Page Load Time 5000 (MS) Maximum Time to First Byte 2000 (MS)

The following experiments are conducted:

a)Consume r-restful-ws_local RESTful WS directly

with local web server with JSON result.

b)Consume r-restful-ws either RESTful WS or SOAP

WS based on r-restful-client or r-soap-client request through the GAE middleware with JSON result.

c)Consume r-restful-ws_heroku either RESTful WS or

SOAP WS based on r-restful-client_heroku or r-soap-client_heroku request through the Heroku middleware with JSON result.

d)Consume r-restful-client_local RESTful WS through

the middleware with JSON result.

e)Consume r-restful-client RESTful WS through GAE

the middleware with JSON result.

f) Consume r-restful-client_heroku REST based WS

over Heroku the middleware with JSON result.

g)Consume r-soap-client_local SOAP WS through the

(7)

International Journal of Emerging Technology and Advanced Engineering

110

h)Consume r-soap-client SOAP WS through the GAE

middleware with JSON as result.

i) Consume r-soap-client_heroku SOAP WS over the

Heroku middleware with JSON result.

Above experiments’ describe using with diagram are as following: a) b) c) d) e) f) g) h) i)

Figure 7: consume “r-restful-ws” WS test case

Table 5 and 6 shows the Maximum, Minimum, and average of the result time. Figure 8 and 9 shows a column graph comparing the result times of different test cases. There is overhead connected with the middle ware. Though, result optimization suggestively decreases the bandwidth aspect.

Table 5

Result-Time to first byte receive (MS) Sr.

no.

Test case name

Detail Info Min. (MS) Avg. (MS) Max. (MS) 1 r-restful-ws_local Consume ―r-restful-ws_local‖ RESTful WS directly with local web server

with JSON result. 13 30 111 2 r-restful-ws Consume ―r-restful-ws‖ either RESTful WS or SOAP WS based on ―r-restful-client‖ or ―r-soap-client‖ request through the GAE middleware with JSON result. 15 281 731 3 r-restful-ws_heroku Consume ―r- restful-ws_heroku‖ either REST WS or SOAP WS based on ―r- restful-client_heroku‖ or ―r-soap-client_heroku‖ request through the Heroku middleware with JSON result. 11 908 2.39 (S) = 2390

(8)

International Journal of Emerging Technology and Advanced Engineering

111

4 r-restful-client_local Consume ―r- restful-client_local‖ RESTful WS through the middleware with JSON result. 11 21.45 (S) = 2145 0 38.69 (S) = 38690 5 r-restful-client Consume ―r-restful-client‖ RESTful WS through GAE the middleware with JSON result. 13 1.22 (S) = 1220 13.83 (S) = 13830 6 r-restful-client_heroku Consume ―r- restful-client_heroku‖ RESTful WS over Heroku the middleware with JSON result. 13 408 1.39 (S) = 1390 7 r-soap-client_local Consume ―r- soap-client_local‖ SOAP WS through the middleware with JSON result. 13 783 2.20 (S) = 2200 8 r-soap-client Consume ―r-soap-client‖ SOAP WS through the GAE middleware with JSON result. 14 7.76 (S) = 7760 2.56 (S) = 2560 9 r-soap-client_heroku Consume ―r- soap-client_heroku‖ SOAP WS through the Heroku middleware with JSON result. 15 404 595 0 5 10 15 20 Lo ca l We b H e ro ku Different Platforms R e su lt T im e ( M S) r-restful-client_local r-soap-client_local r-restful-ws_local r-restful-client r-soap-client r-restful-ws

Figure 8: Column graph for Result time to first byte receive (MS) Table 6:

Result-Time to Page Load Time (MS) Sr.

no.

Test case name

Detail Info Min. (MS) Avg. (MS) Max. (MS) 1 r-restful-ws_local Consume ―r- restful-ws_local‖ REST WS directly with local web server with JSON result. 15 645 3.60 (S) = 3600 2 r-restful-ws Consume ―r-restful-ws‖ either RESTful WS or SOAP WS based on restful-client‖ or ―r-soap-client‖ request through the GAE middleware with JSON result. 17 1.45 (S) = 1450 4.23 (S) = 4230

(9)

International Journal of Emerging Technology and Advanced Engineering

112

3 r-restful-ws_heroku Consume ―r- restful-ws_heroku‖ either RESTful WS or SOAP WS based on ―r-restful-client_heroku‖ or ―r-soap-client_heroku‖ request through the Heroku middleware with JSON result. 13 3.77 (S) = 3770 16.28 (S) = 16280 4 r-restful-client_local Consume ―r- restful-client_local‖ RESTful WS through the middleware with JSON result. 13 30.44 (S) = 30440 38.72 (S) = 38720 5 r-restful-client Consume ―r-restful-client‖ RESTful WS over GAE the middleware with JSON result. 16 1.96 (S) = 1960 25.57 (S) = 25570 6 r-restful-client_heroku Consume ―r- restful-client_heroku‖ RESTful WS 18 3.18 (S) = 3180 23.05 (S) = 23050 through Heroku the middleware with JSON result. 7 r-soap-client_local Consume ―r- soap-client_local‖ SOAP WS through the middleware with JSON result. 15 1.40 (S) = 1400 3.12 (S) = 3120 8 r-soap-client Consume ―r-soap-client‖ SOAP WS through the GAE middleware with JSON result. 20 5.49 (S) = 5490 15.32 (S) = 15320 9 r-soap-client_heroku Consume ―r- soap-client_heroku‖ SOAP WS through the Heroku middleware with JSON result. 26 1.68 (S) = 1680 12.29 (S) = 12290

(10)

International Journal of Emerging Technology and Advanced Engineering

113

0 5 10 15 20 25 30 Local Web H e rok u Different Platforms Re su lt T ime (MS ) r-restful-client_local r-soap-client_local r-restful-ws_local r-restful-client r-soap-client r-restful-ws r-restful-client_heroku

Figure 9: Column graph for Result time to Page Load Time (MS)  Local v/s. Middleware: Compare the test cases 1 to 9

for both views such as Result-time to first byte receive and Result-time to Page Load Time, whether the ―r-restful-ws_local‖ WS and ―r-restful-ws‖ services return JSON, the middle ware adding a some amount of overhead (on an average 1.05s to 3.70s) on the result time for different middle ware platform. As the middle ware, it does not do any kind of processing of the WS results; some amount of overhead is mostly initiated by network expectancy among the mobile clients and middle ware.

 REST WS v/s. SOAP WS: As the test cases 7, 8, and 9 presented, SOAP WS has high amount of result times than the rest of the test cases 4, 5, and 6 with RESTful WS. SOAP-WS is verbose technique, which means there are some more content requests to be transmitted. In adding, processing time pre requisite for the middle ware creating nuSOAP object from the SOAP WS communication / message. The advantage of SOAP WS is result access is easy, though RESTful WS is also produce result in an enhance manner.

VII. CONCLUSIONS

Primarily researcher has design a different kind of WS app model like before this, there is make request response direct using mobile client to host server model. Moreover, in this WS app model we have created middle ware for different cloud platform with difference WSs parameters. Furthermore, we have associated SOAP WS with RESTful WS and piloted test cases on different platforms such as, local host using Apache (WAMP) web server, and also deployed on cloud-servers such as, GAE and Heroku. As a result of test cases displayed that REST WSs app model is better in performance and also displayed that REST WS with JSON format is return better performance for mobile users as well.

REFERENCES

[1] Al Shahwan F, and Moessner K., Providing SOAP WSs and Restful WS from Mobile Hosts. Internet and Web Applications and Services (ICIW), 2010, 5th International Conference on, pp.174-179.

[2] Fielding R., ―Architectural Styles and the Design of Network-based Software Architectures," Ph. D. Thesis, University of California, Irvine - California, U S A, 2000.

[3] E. Oliver, ―A survey of platforms for mobile network s research,‖ SIG-MOBILE Mobile Compute Comm. Revised, vol.12, 2008, pp. 56–63

[4] Performance testing tool Web U I, JSON, CSV data, LoadUIWeb 2 Tool downloaded from http://loaduiweb.org/ (2015)

[5] Google App Engine accessed via

https://developers.google.com/appengine (2015) [6] Heroku accessed via https://herokuapp.com (2015)

[7] Dr. Atul M. Gonsai, and Mr. Rushi R. Raval, Enhance the Interaction between Mobile Users and Web Services using Cloud Computing, Oriental Journal of Computer Science & Technology, Vol: 7, No: 3, December 2014, pp. 416-424.

[8] Dr. Atul Gonsai, and Mr. Rushi Raval, Mobile Cloud Computing: A Tool for Future, International Journal of Computer Science & Engineering Technology, Vol: 4, No: 7, July 2013, pp. 1084-1090.