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

Performance Analysis and Design of a Mobile Web Services on Cloud Servers Rushi Raval 1, Dr. Atul Gonsai 2 1 Research Scholar, 2 Associate 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 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 inexpensive 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-inweight as related to SOAP standards and is mostly based on URL, various IT companies have used 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 s 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 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 webservices (no requirements of extra SDKs / Toolkits / DLLs). 104

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 GET POST PUT DELETE C R U D Operation Retrieve a Resource Create a Resource Update a resource 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-soapclient and r-restful-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 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 APP MODEL 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 rsoap-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 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. 105

V. IMPLEMENTATION OF WSS APP MODEL 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 Windowsphone app as native app model and also design for webwork app model to support other mobile clients as well, for mobile users (college, 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. 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 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 cachemanager 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. News Screen (user as Result list (user as Streams Screen (user as Result Screen (user as Figure 3: Demonstrations of Windows Phone Native UI App Model 106

Registration Screen (user as News Screen (user as List of students screen (user as Administrator) News Screen (user as Administrator) Result list (user as Result Screen (user as Email to students (user as Administrator) Results Screen (user as Administrator) 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-restfulws, 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 r-restful-client Windows Native app and r-restfulclient Android Web app. Administrator can add, edit, and delete the Results according to the stream wise. Figure 5: Screen displays of r-restful-ws WS app model with mashup 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 middle ware which is hosted on to the cloud server and there request-response are generated in JSON format: Figure 6: Presentation of design structure for mobile clients 107

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

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 and the maximum time to first byte is 3000. The 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 User count 1 Scenario Workstation Browser Start Delay Connection Speed Correct Host field Load profile Quality Service of Virtual user group Scenario1_ r-restful-client_local Master Chrome 0 MS Maximum speed Enabled Steady load Maximum Page Load Time 5000 Maximum Time to First Byte 2000 User Table 4 LoadWebUI test case 2 Configuration for r-restful-client_local User count 10 Scenario Workstation Browser Start Delay Connection Speed Correct Host field Load profile Quality Service of Virtual user group Scenario1_ r-restful-client_local Master Chrome 0 MS Maximum speed Enabled Steady load Maximum Page Load Time 5000 Maximum Time to First Byte 2000 The following experiments are conducted: a) Consume r-restful-ws_local directly with local web server b) Consume r-restful-ws either or SOAP WS based on r-restful-client or r-soap-client request GAE c) Consume r-restful-ws_heroku either or based on r-restful-client_heroku or r-soapclient_heroku request Heroku d) Consume r-restful-client_local through the e) Consume r-restful-client through GAE the f) Consume r-restful-client_heroku REST based WS over Heroku the g) Consume r-soap-client_local 109

h) Consume r-soap-client GAE as i) Consume r-soap-client_heroku over the Heroku Above experiments describe using with diagram are as following: i) Figure 7: consume r-restful-ws WS test case a) 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. b) Table 5 Result-Time to first byte receive Sr. no. Test case name Detail Info Min. Avg. Max. c) d) e) f) g) h) 1 r-restfulws_local Consume rrestful-ws_local directly with local web server 2 r-restful-ws Consume rrestful-ws either RESTful WS or SOAP WS based on rrestful-client or r-soap-client request through the GAE 3 r-restfulws_heroku Consume rrestfulws_heroku either REST WS or based on rrestfulclient_heroku or r-soapclient_heroku request through the Heroku 13 30 111 15 281 731 11 908 2.39 2390 110

Local Web Heroku Result Time International Journal of Emerging Technology and Advanced Engineering 4 r-restfulclient_local 5 r-restfulclient 6 r-restfulclient_heroku 7 r-soapclient_local Consume rrestfulclient_local Consume rrestful-client through GAE the Consume rrestfulclient_heroku over Heroku the Consume rsoapclient_local 8 r-soap-client Consume rsoap-client GAE 9 r-soapclient_heroku Consume rsoapclient_heroku Heroku 11 21.45 2145 0 13 1.22 1220 38.69 38690 13.83 13830 13 408 1.39 1390 13 783 2.20 2200 14 7.76 7760 2.56 2560 15 404 595 Sr. no. 20 15 10 5 0 Different Platforms r-restfulclient_local r-soap-client_local r-restful-ws_local r-restful-client r-soap-client Figure 8: Column graph for Result time to first byte receive Test case name 1 r-restfulws_local r-restful-ws Table 6: Result-Time to Page Load Time Detail Info restful- ws_local REST WS directly with local web server with either RESTful WS or SOAP WS based on 2 r-restful-ws Consume rrestful-ws r-restfulclient or rsoap-client request GAE Min. Avg. Max. 15 645 3.60 17 1.45 1450 3600 4.23 4230 111

3 r-restfulws_heroku 4 r-restfulclient_local 5 r-restfulclient either RESTful WS or SOAP WS based on restful- ws_heroku r-restfulclient_heroku or r-soapclient_heroku request Heroku restful- client_local Consume rrestful-client over GAE the 13 3.77 3770 13 30.44 30440 16 1.96 1960 16.28 16280 38.72 38720 25.57 25570 7 r-soapclient_local through Heroku the soap- client_local 9 r-soapclient_heroku 8 r-soap-client Consume rsoap-client GAE soap- client_heroku Heroku 15 1.40 1400 20 5.49 5490 26 1.68 1680 3.12 3120 15.32 15320 12.29 12290 6 r-restful- 18 3.18 23.05 client_heroku restful- client_heroku 3180 23050 112

Local Web Heroku Result Time International Journal of Emerging Technology and Advanced Engineering 30 25 20 15 10 5 0 Different Platforms r-soap-client_local r-restful-ws_local r-restful-client r-soap-client r-restful-ws r-restfulclient_local Figure 9: Column graph for Result time to Page Load Time r-restfulclient_heroku test cases 1 to 9 Local v/s. Middleware: Compare the 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. : As the test cases 7, 8, and 9 presented, 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 communication / message. The advantage of 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 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 format is return better performance for mobile users as well. REFERENCES [1] Al Shahwan F, and Moessner K., Providing s and Restful WS from Mobile Hosts. Internet and Web Applications and Services (ICIW), 2010, 5 th 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. 113