Mobile Cloud Middlewares

Some of the solutions for various difficulties of mobile cloud computing can be resolved by the placing of a middleware solution between the mobile de-vice and the cloud itself. This acts as a proxy; requests and responses to and from cloud infrastructure pass through the middleware where some additional work can take place, or features can be provided. This subsection will examine some middleware solutions for mobile cloud computing. Many middlewares use web services corresponding to service oriented architecture to complete work, whereas others do not. Here, examples of both categories are presented.

2.3.4.1 Middleware Solutions with Service Oriented Architecture (SOA)

Web services are a standard method to provide data and communication facil-ities to clients in the area of service oriented architecture (SOA). Web applica-tions or local applicaapplica-tions can connect to web services using HTTP, by sending requests to endpoints, which are simply URL endpoints for sending requests to the service and receiving responses. Clients can pass information and param-eters to the service to customise the request for the information or service they need. The response typically contains result information that the application can process in some way and display to the user within the application.

Typically, there are two kinds of web service, a SOAP (Simple Object Access Protocol) service, or a RESTful (Representational State Transfer) service. SOAP services receive SOAP messages from the client in the body of a HTTP request, which consists of a SOAP body, contained within a SOAP envelope. A SOAP response is sent back to the client in the body of the HTTP response. SOAP messages are in XML format.

RESTful services also work by sending and receiving HTTP requests and re-sponses, however REST identifies a service by the URL endpoint, and the spe-cific HTTP method of the request such as GET or PUT. GET messages are nor-mally used with RESTful services which request information from the server, and PUT messages are used to pass information to the server. Parameters can be passed in both the URL of the endpoint, and within the body of the HTTP message, using either XML, or more commonly, JSON markup. JSON has been seen as more "lightweight" than XML, as it does not contain opening and clos-ing tags for each piece of information. This is an important consideration, not just to minimise the size of the data being transferred for the sake of the net-work traffic and associated delays, but in the mobile context, where the user is often charged per kilobyte of information sent and received. In work by Jason H. Christensen [18], it is proposed that RESTful architectures are a practical means to deliver applications and services to mobile devices, when consider-ing data exchange requirements and constraints.

As web services are such a common standard for communication of infor-mation and requests, cloud providers provide public web services to clients to communicate with their respective services [6]. However, these services are currently not interoperable. Developers have to use a specific API for each cloud services provider, which are generally not compatible with other providers. Moreover, the services are not developed with the mobile context in mind, and may contain unnecessary overhead, or the data may be in a for-mat that is expensive to parse. In recognition that the current state of cloud computing access is not completely adequate for consumption of services from mobile devices, the need to have some form of middleware-based proxy, situ-ated in the cloud between the mobile device and cloud services, is recognised in the literature.

Wang and Deters [144] developed an SOA Mashup middleware to be deployed on cloud infrastructure that is capable of invoking RESTful and SOAP-based services. As the XML based SOAP messages are larger in size than RESTful services that communicate JSON, they are more costly for a mobile device to parse. The middleware takes web service requests from the mobile device, in a RESTful style, using JSON. If the service being invoked is SOAP based, the middleware transforms the request into a SOAP message, and invokes the web service on behalf of the device. The result is then stored in the middleware until the device is ready to receive it, a form of results caching. The SOAP response message from the web service is converted into JSON for sending

Figure 2.5: A Sample Middleware Model. A middleware is deployed in the cloud, which performs work on behalf of the mobile device. This usually takes the form of the middleware invoking SOA web services to complete work for the user in a asynchronous, non-blocking fashion, freeing the device to per-form other work. Results are then adapted back to a mobile friendly per-format before being returned to the device.

back to the mobile device. The approach is sound but suffers from the common problem that when adding a proxy between the device and the service, a layer of indirection is introduced. As such, the results were slower than invoking the services directly from the mobile device, however this would be expected.

The caching aspects are extremely valuable in the mobile context in the case of disconnections, as is the optimised JSON message size, which will reduce the data processing time and cost. Arguably those benefits would outweigh the disadvantages, as low cost and disconnection support are important to the user experience. However the implementation is not currently practical for the user context, as it requires the mobile device user to provide the URL of the WSDL file describing the service, and to indicate if it is a SOAP or RESTful web service [143]. Non-technical mobile device users will not know what WSDL files are, nor the difference between SOAP and REST. A form of discovery service would be useful here, to take this complexity away from the user. As such the approach lacks deployability to end users in its current state.

Flores et al [39] developed a mobile cloud middleware that is aimed at re-solving the problem of cloud provider interoperability. The middleware takes

requests from mobile applications on the device, and will decide which cloud service needs to be invoked. An adapter is used to pass the call to the cloud service. Like Wand and Deter’s work, the results can be cached and deliv-ered to the mobile at a later stage in the case of a disconnection. Some sample applications were developed to illustrate the concept, which were designed specifically to use services from different cloud providers. Results were sim-ilar to Wang and Deter’s work in that the indirection of using a middleware proxy were slower than invoking the services directly, yet as the middleware works asynchronously, the device was free to work on other tasks while the middleware carried out it’s workload, freeing the device in the way the au-thors wanted to achieve. The details on how applications on the mobile device should be written to use the middleware were not clear. For example, how the application should signal what cloud service it requires. There must be some generic API for the middleware, because if this was not the case, then it does not provide a solution the interoperability problem it aims to solve.

2.3.4.2 Other Middleware Solutions

A later work by Flores et al [37] compares what are generally the two overall approaches to mobile cloud computing; delegation of data intensive tasks the cloud (what has been described so far in this thesis as approaches such as code offloading and application partitioning), and the offloading approach (what is described in this thesis as a service oriented approach). Continuing the dis-cussion in this paragraph, to be consistent with the terminology used in this thesis, what the authors of this work refer to as delegation, shall be described here as code offloading, and what the authors of this work refer to as code of-floading, will be described here as a service oriented approach. The authors compare examples of these two approaches for their advantages and disad-vantages. In terms of code offloading, the authors argue that no code offload approach has taken advantage of the features offered by the cloud platform (scalability, elasticity, parallelisation, etc.). They have developed the EMCO (Evidence-based mobile code offloading) platform to overcome this. EMCO collects context data for virtual machines in the cloud (such as CPU utilisation, memory capacity), and uses this information to determine exactly which VM in a cloud data centre that work should be offloaded to, similar to the M2C2 mobility management system [89]. Having said that, the authors generally are in favour of the service oriented approach. Supporting the code offloading

ap-proach is considered to be difficult because applications do not readily support it without modification, an issue already outlined in this review. In addition, very few applications seem to take advantage of the computational capability offered by the cloud, such as augmented reality and graphics processing appli-cations. Most applications on mobiles do not need a large amount of resources.

The service oriented approach is seen as easier to adapt existing applications to, and of course, a service oriented approach, supported by a middleware, can enable disconnected operation in the cloud, where work can be completed for a user while disconnected. As outlined before in this review, the same cannot be said for the offloading approaches.

Another SOA approach which recognises the value of disconnected operation is the work by De and De [23]. This work proposes using a tuple space model, to tackle the problem of decoupling mobile applications from mobile cloud services. The authors argue that traditional service models, such as REST, and data transfer formats, such as JSON, do not provide dynamic flexibility to mo-bile devices, in the sense that the momo-bile applications become coupled to these technologies and formats. By creating a tuple space both on a handset, and at a cellular base-station between the mobile device and the cloud, mobile applica-tion requests for services, and their responses, can be represented as anti-tuples (a search tuple) and tuples respectively. Tuples are unordered in nature, and because tuples are stored in the handset and/or base-station until the service (for the request)/device (for the result) becomes available, this method also supports mobile devices in disconnected situations. Tuples specify properties of a service being sought by an application, and for the services offered by a provider. No practical implementation details are provided as to how appli-cations specify service requests, or how service providers can describe their services as tuples, in which case, in the view of this thesis work, does not solve the problem the authors claim. The mobile device and service provider would still need to agree on some common naming standards for the properties of services that are searched for with anti-tuples. The work also does not address cellular handoff. However, it is one of the few approaches that does recognise the need for mobility with the mobile cloud; a device will not remain con-nected at all times. This further demonstrates the usefulness of a middleware in the cloud to perform work for the user.

A final example of a middleware solution is the Avatar middleware by Borcea et al [14]. The authors describe the Avatar middleware as a platform for mobile distributed computation. Similar to CloneCloud [19] and ThinkAir [70], a copy

of the mobile operating system exists in the cloud as a VM. This VM is known as an Avatar; each user has their own, and every mobile device of the user shares that Avatar. Mobile applications can run either entirely on the Avatar, or components can be split between the Avatar and the mobile device. In the nature of the author’s aim of truly distributed mobile computing, the Avatar’s of several users can collaborate on tasks (if each Avatar VM has a copy of the same application). The work also focuses on the Avatar API, which offers pro-grammers access to Avatar communication, Avatar data storage, and Avatar start/pause/resume/stop commands. Additionally, the cloud deployment ar-chitecture is discussed in detail, which focuses on issues such as scalability to billions of Avatars (for reasons such as low latency communication and energy efficiency), and data privacy. This approach is probably the most similar work to the project undertaken for this thesis, except that the Avatar is a VM, where the approach in this thesis work is an SOA-based approach, which overcomes many of the problems associated with mobile cloud computing enabled by means of VM-based solutions.

To summarise, the use of middlewares as a proxy for accessing SOA web ser-vices which invoke cloud serser-vices on behalf of mobile deser-vices is a sensible one if the solutions to the highlighted problems are solved, as demonstrated in the work by Wang and Deters, and Flores et al. The idea of caching results in the cloud in the case the mobile device becomes disconnected will be a crucial as-pect of improving the user experience on these devices, as will optimised ser-vices that are both low cost, and can utilise different serser-vices from difference providers with ease. SOA approaches can also enable context aware services and are capable of taking context information from the device, which is essen-tial to the aim of personalisation of mobile cloud applications. The use of a middleware solution will be slower than direct interaction, but this concern should be set aside, as the mobile device is not blocked and waiting for the middleware to complete work, it is free to disconnect and perform other work.

From the user experience perspective, middleware solutions are the only solu-tions that can solve the disconnection and mobility issues.