Introduction
Mobile clients are likely to upsurge progressively from current users. As cellular network infrastructures incessantly improve, their data broadcast develops gradually affordable and available, and thus they are becoming prevalent traditions to access the Internet Based Services, mainly the Web Services that are also available in the cloud computing. Today, mobile clients’ uses devices like Android, iPhone, and Black-berry, have encompassed applications that consume the web services from popular websites, such as YouTube, eBay and Msn. The share of android in smart phone market is 46%, iPhone is 35% and blackberry is 10% [1].
Though, there are difficulties in connecting smart phones to present Internet based Services. Initially, the Internet Based Services need to deliver optimization for mobile clients. For e.g. the size of the Web Services messages desires to be reduced to fit the bandwidth of mobile clients. Moreover, smart phones have to acclimate to different kinds of Web Services, for e.g. SOAP and RESTful Services. Figure1 shows a smart phone retrieving Web Services. This paper considers how Cloud Computing [2] can help mobile clients connect to existing Web Services.
Problem definition
Accessing Web Services from a smart phone based mobile client is different compared to the standard web services developments, because of these aspects environment. A review done by Earl et al. [3] estimated how well the current mobile clients including Android, Symbian, iPhone, and Windows Mobile, support the perception of cellular network based research. According to the review, all of these mobile platforms have certain limitations.
• The communication between user and service is established through wireless network.
• Mobile clients have limited resources like Low processing power, small screen size etc.
• Present Web Services in the Cloud doesn’t support mobile clients.
Internet web services [19]
There are several challenges in accessing the Internet based Services from the existing smartphone clients. The following two are the focus of this paper.
- Connection loss Problem: Meanwhile the smart phone based devices are not stable and due to the mobility of the smart phones and the wire-less network setup, smart phones can be momentarily removed from the previous connected network and later may join available network.
-
Latency/ Bandwidth Problem: Cellular networks have a very limited bandwidth and are often billed based on the amount of data transferred. Though, even a simple SOAP message often contains a large chunk of X M L data, which consumes a lots of bandwidth and the broadcast can cause major network dormancy. In addition, the SOAP message contains mostly X M L tags that are not all necessary for mobile clients.
-
Limited resources problem: mobile clients are normally “thin clients” [4] with a less processing power. They also have limited computational power and screen size/resolution. These deficiencies are only due to mobility [5].
Architecture for mobile client devices
Middle ware Architecture [6] is primarily used in Distributed Computing system (DCS). DCS [7] “consist of multiple processors that don’t share primary memory, however messages sending over the network”; Mobile users are distributed computers that connect to the middle-ware. In Emmerich paper [8], he stated four requirements scenario for general middle ware.
Heterogeneity: Components in a distributed system can be implemented with different languages and deployed on different-different platforms. Therefore, the design needs to study a heterogeneous location.
Network communication: Masses who need to communicate with each-other involves some transport layers (T C P and U D P) and arranging, a method of transforming data structure to transferable format.
Reliability: Requests maybe lost during the network transmission. The middle ware needs to deploy error detection and correction mechanisms to enhance reliability.
Scalability: Distributed systems deal with client interactions and also interact between distributed components. Changes in the allocation of components could affect the system architecture, which refers as transparency in the reference model of open distributed processing
Co-ordination: Since distributed systems have multiple points of control, different components need to coordinate and collaborate through synchronization.
Middle ware Architecture is often used to extend functions for thin clients, like mobile devices. Uribarren et al. [9] proposed a middle ware for adaptation in mobile environments. The proposed middle-ware hides the complexity of deploying ubiquitous Apps. Applications are automatically moved between different platforms.
When designing distributed systems, scalability, should be the major concern issue. Rajive et al. [10] did research on investigating scalable middle ware to support mobile Internet applications.
The future middle ware solution for mobile clients mostly focuses on application and content adaptation. Heterogeneity, Network communication, reliability, and co-ordination are four fundamental requirements for general middleware as well as middle ware for mobile device [11]. Scalability can be achieved with distributed middle ware. Context can help middleware to adapt to the heterogeneous environment. However, the goal of the paper is to use middle ware to improve the interaction between mobile clients and internet services as well as use Cloud platforms to improve the scalability and reliability of the middle ware.
RESTful web service
RESTful [12] is a software application architecture modeled after the way data is accessed, modified and represented on the web. In the REST architecture, data and functionality are considered as resources, and these resources are retrieved with use of Uniform Resource Identifiers (URIs), typically links on the web. The resources are acted upon by using a set of modest, well defined processes. The REST architecture is fundamentally client-server based architecture, and is designed to using as a state less communication protocol, usually HTTP. In the R E S T architecture, users and servers interchange representations of resources with use of an identical protocol and interface.
These principles encourage REST applications to be simple, lightweight, and have high performance.
RESTful web services [12] are web applications built upon the REST architecture. They expose resources (data and functionality) through web URIs, and use the four main HTTP methods to C.R.U.D. which are known as create, retrieve, update, and delete resources. RESTful WS typically map the four main HTTP methods to the so called C.R.U.D. operations: create, retrieve, update, and Del, below table shows a representing of HTTP methods to these C.R.U.D. operation.
Proposed architecture for middle ware
The middle ware that is proposed will act like as proxy that is hosted on the Cloud platforms which provide mobile clients access to Cloud services. The middle ware architecture will improves interaction between mobile clients and Cloud Services, for e.g., adaptation, optimization and caching. The middle ware also provides extended functions to mobile clients. In general, the architecture enhances the dependability, functionality, and compatibility of the interaction between mobile clients and Cloud Web Services.
In order to overwhelm the difficulties stated in the previous sections, the Cloud Computing architecture provides the following features to enhance the interaction between mobile clients and Web Services.
No Loss of connection: Client and middle ware caching -Copies of service results are stored on both mobile clients and the middle ware. While the mobile clients are not able to connect to the middle ware, the client-side cache is used. When the middle ware to server connection is not available, the middle ware returns its cached data to the mobile clients.
Bandwidth/Latency: Protocol transformation – Protocol transformation reduces the latency as well as bandwidth of the client to service interaction. The middle ware transforms Simple Object Access Protocol (SOAP) to a much light- weight format JSON through Restful Internet Web Services. Transferring SOAP to light-weight protocols, like Restful, reduces processing time as well as the size of the messages [13].
Optimization of Result: Result optimization reduces the size of the service results, thus reduces the bandwidth used to interact with internet based services. The middle ware converts the format of service results from X M L to JSON and removes unnecessary data from the original service result. Less data transmitting also reduces network latency.
Implementation of restful web service
The goal of the middleware cloud architecture is to provide a proxy for mobile clients connecting to Cloud services. Figure 2 shows an overview of the middleware cloud and its key features. The architecture consists of three parts, the mobile-clients, the cloud services and the middle ware. Since Cloud services are usually controlled by service providers, the middle ware performs all the necessary adaptation to the mobile clients.
Middle ware Architecture
The middle ware is responsible for consuming the Cloud Services whether they are SOAP or REST services like JSON and delivers the service result to the mobile clients. On the smart phone, mobile clients can define Web Services and later execute the pre-defined Web Services. The middle ware provide REST interface for the mobile clients. Fig. 4 indicates how to consume/execute a pre-defined Web Services. Note that the execution starts with a HTTP GET request whose URL path contains the resource identifier to the web. When Web Services are executed through the middle ware, the following steps are involved in the middle ware.
- The mobile clients send a HTTP GET request with an identifier of a Web Services to the middle ware.
- The middle ware deals with interactions to the Web Services (and generates SOAP client if necessary).
- The middleware extracts (JSON or X M L parsing) the required service results from the original service result and form a new service results in JSON format.
- The middleware stores a replica of result with the service_ID in the database and returns the enhanced result to the mobile client.
Mobile client implementation on middle ware in mobile clients
In order to implemented the proposed smartphone based architecture with client side native libraries. Smartphones has an embedded browser which includes JavaScript libraries that implement several common functionalities of the client side browser, for example, access a file system and location service.
To verify the smart phone based client design, we have develop the design with an idea of generate a list of you tube channel as shown in Figure 3.1. The application is getting response with use of JSON parsing and a restful WS with the mobile client design on smart phone. Using the application, the mobile clients can access the Web Services of the portal which is hosted on Google cloud through the smart phones.
The mobile client application can be divided into three layers; Controller, User interface (UI), and Cache Manager. The UI layer has two enactments, embedded browser UI and native UI. Figure show how they look like on the device. Figure also shows the architecture of both applications. The controller is the key manager among the UI, middleware, and cache manager. The controller creates the U I and gets data from the RESTful client or cache-manager. If that time network connections are not accessible, the controller passes cached data to the UI components.
Furthermore, we have developed one more mobile/website app design with an idea of admission procedure of college and day-to-day generate a list of students with the full information which was given by the students/parents, this information was accessed by an admin, and admin can also download that data in JSON format as well as in CSV format from their mobile or computer system as shown in Figure 3.2, 3.3. The application is getting response with use of PHP, JSON parsing with the mobile client design on smart phone. By use of this app, the students/parents can access the Web Services of the portal which is hosted on Google cloud server through the use of smart phones.
This mobile client app can be divided into three layers; Google App Engine [20], User interface (UI), and Google Cloud Server. The UI layer has embedded browser UI. Figure show how they look like on the device. The GAE and GCS are the key coordinators among the UI, middle-ware. The GAE manage the user requests and gets data from the mobile client and storage is on Google Cloud Server (GCS). If network connections are not obtainable, the control passes cached data to the U.I. components.
Otherwise, it invokes the REST ful client to get data from the middleware. The cache manager then saves recent received data on a local file system. With the native UI, the client interacts with the middleware asynchronously. When the native UI requires data, it passes a callback to the controller and continues to receive UI events as shown in Figure 4.
The controller starts a new thread to interact with the middle ware. When the data arrives, the U.I. gets updated through the notification. With this model, the native UI can be updated as soon as the data changes. The android app needs to wait for the facts and figures to reach, because the native library can’t receive a Java Script notification. The android app also cannot be updated automatically when the data changes.
The entire middle ware application is hosted on a Google Application Engine GAE uses the Services oriented architecture. The middle ware architecture is implemented as an android application. The application uses the RESTful Internet Service interfaces to mobile clients, since RESTful web services are more suitable for mobile devices [14], Because the middle ware uses RESTful and JSON API of core Android libraries.
The middle ware also uses a popular JSON client library which provides functions of composing custom HTTP requests, sending and receiving HTTP requests and responses. The middle ware architecture expects the Web Services to return JSON responses, so that results can be extracted using the android build-in library. User defined tasks, service actions, parameters and results are Java objects which map to database entities using the android API.
The middle ware still has a RESTful interface to mobile clients, but the Google Application Engine (GAE) platform itself is a Web application server which can only handle server requests. The middle ware constructs and sends HTTP requests through the URL fetch service which implements the android RESTful framework interface.
To enhance the communication between mobile users and Web Services
- Evaluate the cross-platform capability of the mobile clients design.
- Implement the mobile client in different models.
- Consume RESTful WS through the middleware.
- Transfers SOAP WS to RESTful Services to be consumed by mobile clients.
- Reduce bandwidth consumption of mobile clients.
- Push updates to mobile clients in real-time.
Using the Cloud platform as a way to improve consistency and scalability of the middle ware
- The middleware can be implemented on “CloudSim” and Google Application Engine “GAE”.
- Cloud platform improves the scalability and consistency of the middle ware.
- Performance evaluation of web services
The middleware is implemented one as a standard android application and other one as a standard PHP with Python application. For first application the middleware uses the Android 2.2 or above version, so it can be run on most of the android devices.
And for another application PHP5.4.13 standard and Python 27, API version 1, so it can be deployed in Google server containers. The middleware also uses the file handling requests to interact with the Google App Engine and also with Google server. In the following experiments, the middleware is deployed in two platforms, Webserver with Apache Platform (Local), and Google Application Engine (GAE), since Application Engine uses Google’s internal structure, its h/w specification is unidentified.
Because some experiments require simulating a large number of mobile clients and calculating the response times, a real mobile device is not capable of doing such task. A performance testing tool called “LoadUIWeb” [16] is used as a load generator. The emulator for the cloud is CloudSim [13]. LoadUIWeb is responsible for generating and sending HTTP requests to the middleware in a specified rate. LoadUIWeb calculates the mean of response times every 5 seconds based on its log file scenario. The load generator runs on the standard server for the College Portal. The mobile client is applied on Android. The Android device’s using Android Version 4.2. The build-in Apache HTTP client is used to send HTTP request. Together are connected to the Internet through wireless 802.11g standard. The client uses the I/O libraries from PHP and in build Browser Support.
Consuming College admission Web Services through the Middleware
This experiment compares the overhead associated with different WS interactions. College Admission Portal provides REST ful WS interfaces for their student admission service. Their RESTful WS return result in either JSON or CSV format. The tested WS is returned the result in following manner.
Page Load Time
![Comparison for 1 User [16]](http://www.computerscijournal.org/wp-content/uploads/2014/10/Vol07_No3_Enha_Atul_Fig5.1-150x150.jpg) |
Fig 5.1: Performance testing for JSON, CSV Loading Time and Scenario Completion Time Comparison for 1 User [16]
Click here to View Figure
|
In above scenario, we have set some parameters like as User count: 1, Workstation: Virtual, Browser: Google Chrome, Connection speed: Maximum, Load: Steady Load, Max page load time: 5 second.
For next scenario, we have set some parameters like as User count: 20, Workstation: Master, Browser: Google Chrome, Connection speed: Maximum, Load: Steady Load, Continuous Load: Enable and set to 10 seconds.
Page Load Time
![Fig 5.2: Performance testing for JSON, CSV Loading Time and Scenario Completion Time Comparison for 20 User [16]](http://www.computerscijournal.org/wp-content/uploads/2014/10/Vol07_No3_Enha_Atul_Fig5.2-150x150.jpg) |
Fig5.2: Performance testing for JSON, CSV Loading Time and Scenario Completion Time Comparison for 20 User [16]
Click here to View Figure
|
The middle ware is run on the standard server. The “UID”, “Full Name”, and “E-mail” segments of JSON and CSV result were taken for the tests for the WS.
The size of the JSON result is about 129 KB and the size of the CSV result is about 190 KB. The load generator sends HTTP request at the rate of 1 request per 5 second so the middle ware does not overload.
Validate JSON and CSV Data
We have also tested generated data which is in JSON and CSV format whether they generate valid data or not, for that we are using online tool “JSONLint” provided by arc90 Lab [17].
Enhancing Interaction between the Client and Middle ware over Cloud
- Consume “r-gkck-msc” RESTful Web Services directly with JSON result and CSV result.
- Consume “r-gkck-msc” RESTful Web Services through the middleware with JSON result. The middleware forwards the whole result. (No parsing involved in this scenario)
- Consume “r-gkck-msc” RESTful Web Services through the middleware with CSV result.
- Consume “r-gkck-msc” RESTful Web Services through the middleware with JSON result. The middleware returns the optimized result in JSON format.
- Consume “r-gkck-msc” RESTful Web Services through the middleware with CSV result. The middleware returns the optimized result in CSV format.
Conclusions
As service clients, smart phones basically have unique properties like they are portable and small. They are personal devices with numerous sensors. However, these smart-phones have limitations, for e.g., minor bandwidth, loss connectivity and less processing power. On the other hand, the existing services are normally designed for immobile clients. For e.g. SOAP is a protocol which involves a lot of X M L parsing. To overcome the limitations, this paper presents the Middleware for the mobile based architecture for connecting mobile device to the existing Cloud Services.
The projected mobile-client design is mobile platform independent. The mobile client provides an interface for users to define services and consume them through the middle ware. It interrelates with the middle ware through RESTful WS interface. The mobile client has been applied as on Android platform. The smart phone based design involves native as well as browser based applications. For better compatibility aspects, the interface can be applied on implanted browser with use of HTML, CSS and JavaScript, while the actual client component is implemented in platform reliant on specific language, the server side scripts can run on the application server.
The middleware provides a medium for the smart phones to access the Cloud Services. The middle ware also provides result optimizations which extract the required data from the original service results.
References
- Charles Arthur “Nokia revenues slide 24% but Lumia sales rise offers hope”. The Guardian. (Retrieved 19 July 2013).
- M.A. Vouk, “Cloud computing: – Issues, research and implementations,” Information Technology Interfaces, 2008. I T I 2008. 30th International-Conference on, 2008, pp. 31–40.
- E. Oliver, “A survey of platforms for mobile-networks research,” SIGMOBILE Mobile Compute Comm. Revised, vol.12, 2008, pp. 56–63
CrossRef
- M. Al-kistany, Sumi, “Adaptive wireless thin client model for mobile -computing,” Wireless Comm. Mobile-Computing., vol. 9, 2010, pp. 47–59
- M. Satyanarnynnan, “Mobile-computing,” Computer, vol. 26, 1993, pp. 81-82.
CrossRef
- D.E. Bakken and M. API, Middle ware, 2001.
- H.E. Bal, J.G. Steiner, and A.S. Tanenbaum, “Programming languages for distributed computing systems (DCS),” A C M Compute Surveys., vol. 21, 1989, pp. 261–322.
- W. Emmerich, “Software engineering and middle-ware: a roadmap,” ICSE ’00: Proc. of the Conference on The Future of Software Engineering, New York, NY, USA: A C M, 2000, pp. 117–129.
- A. Uribarren, J. Parra, J.P. Uribe, M. Zamalloa, and K. Makibar, “Middle ware for Distributed Services and Mobile Applications,” Inter Sense ’06: Proceedings of the 1st International conference on Integrated internet ad-hoc and sensor-networks, New York, NY, USA: A C M, 2006.
- T. Phan, R. Guy, and R. Bagrodia, “A Scalable, Distributed Middle ware Service Architecture to Support Mobile Internet Applications,” WMI ’01: Proceedings of the 1st workshop on Wireless mobile internet, New York, NY, USA: A C M, 2001, pp. 27–33.
- P. Bellavista, A. Corradi, R. Montanari, and C. Stefanelli, “A mobile computing middle ware for location and context-aware internet data services,” A C M Trans. Internet Technology, vol. 6, 2006, pp. 356–380.
- Fielding R., “Architectural Styles and the Design of Network-based Software Architectures,” Ph. D. Dissertation, University of California, Irvine, California, USA, 2000.
- Feda AlShahwan, Evaluation of Distributed SOAP and RESTful Mobile Web-Services, International Journal on Advances in Networks and Services, Vol. 3 no 3 & 4, year 2010.
- R. Deters, “SOA’s Last Mile-Connecting Smartphones to the Service Cloud,” Cloud Computing, IEEE International Conference on, 2011, pp. 80-87.
- CloudSim: A Framework For Simulation And Modeling Of Cloud Computing Infrastructures And Services : http://www.cloudbus.org/cloudsim/
- Performance testing tool Web UI, JSON, CSV data, LoadUIWeb Tool downloaded from http://loaduiweb.org/
- Valid JSON data using online tool access from http://jsonlint.com/
- JSON data parser testing valid data using online tool access from http://jsonviewer.stack.hu/
- M. Singh, K. S. Dhindsa, “Enhancing Interaction between Smartphones and Web Services on Cloud for Improved Bandwidth and Latency”, IJCSMC, Vol.2, April: 2013, pp. 177-185.
- Google App Engine accessed via https://developers.google.com/appengine (2014)
This work is licensed under a Creative Commons Attribution 4.0 International License.
PDF Downloads:
1715
Open
Access -
![Figure 1: Mobile clients accessing the Internet web services [19]](http://www.computerscijournal.org/wp-content/uploads/2014/10/Vol07_No3_Enha_Atul_Fig1.jpg)
![Fig 5.3: Validate JSON data using “JSONLint” Tool [17]](http://www.computerscijournal.org/wp-content/uploads/2014/10/Vol07_No3_Enha_Atul_Fig5.3-150x150.jpg)
![Fig 5.4: JSON data parser testing valid data [18]](http://www.computerscijournal.org/wp-content/uploads/2014/10/Vol07_No3_Enha_Atul_Fig5.4-150x150.jpg)