Web Services on Mobile Devices

Many works have explored the use of web services on mobile devices, from the perspective that a mobile device can act as a server, providing services to clients. For example, a use-case for this approach would be that a mobile user can offer a live video stream from the camera on the mobile device, as a service, to interested friends, of concerts or sporting events. In the situation where a friend could not attend, they could view the event from the camera feed. An example of this is the mobile web service provisioning framework by Elgazzar et al [32]. In this work, the cloud is used for web service discov-ery, but the web services run on mobile devices, rather than in the cloud. The Location-Aware Service Provision and Discovery (LASPD) framework by Zhu et al [151] is focused on services hosted on servers, as well as on mobile de-vices, in the same way as the framework by Elgazzar et al, and implements locality based discovery and consumption of services for mobile devices

lo-cated nearby. A three-tier approach is used, with a top administrative tier, a second tier which contains servers providing services in a local area, and third tier which contains mobile devices offering services. Discovery can take place, and queries for services can express to find a service within a given distance of the caller. If a service is not present in one area, the super-peer, located in the top tier which governs an area, can send the request to other area peers.

Service descriptions are not described in this work.

Another solution is the VOLARE middleware [105], which monitors the mo-bile device context, so as to dynamically change service providers at runtime to maintain a certain Quality of Service (QoS) level. The implementation is not fully explained, and details regarding discovery of services, as well as ser-vice descriptions, are not provided. A video streaming application is provided for evaluation; as the network conditions/quality changes, the middleware switches the video provider to one offering a higher/lower quality video, to meet the required QoS level. The focus of this thesis work is on disconnected approaches, rather than applications that require real-time streaming, influ-enced by constant context updates.

Regardless of how compelling the use-cases may be for mobile devices as ser-vice providers, from a mobile cloud point of view, the goal of using a mobile device as a server to offer services runs opposite to what mobile cloud comput-ing aims to achieve: removcomput-ing work from the mobile device. As with a web service hosted in the cloud, the same expectation would be present of the mo-bile devices offering the services. Availability, reliability, and scalability, cannot be guaranteed on a mobile device. The mobile device would ideally need to stay powered on, and connected to a network at all times with a high quality signal, and would need to be able to provide its resources to many users. This expectation is not feasible for a mobile device.

In the work by Elgazzar et al, disconnection support is said to be provided by various means, such as service caching, service replication, or cloud based support. Cloud based service support is essentially the same as the model for the work in this thesis. Service caching is a technique where the service is moved from the service provider, to the service consumer, as a local copy of the service, or is moved to a third party "proxy", which can take over the role of service provider. The work does not give any implementation details on how this takes place, aside from stating WSDL modifications are required.

Consequently, the LASPD framework also supports proxies for calling mobile

services, due to valid concerns about mobile devices not being available at all times; consumers call mobile services, located in the third tier of the frame-work, through the proxy. Services in a cloud setting cannot be assumed to be "movable" to a mobile device, as the service may be implemented by a programming language that is incompatible with the local mobile platform.

Service replication is when the same service can run on different mobile de-vices. This is a more practical approach, and should be invisible to the service consumer. In the use-case example given at the start of this section, it would require more than one person to be present at the event to stream it with the camera.

The work on the Extended Mobile Host Complex Web service Framework (EMHCWF) by AlShahwan and Faisal [3] may shed some light on the pro-cesses behind moving mobile web services between devices, as mentioned by Elgazzar et al. This work also focuses on hosting web services on mobile de-vices, and takes particular focus on partitioning complex web services between devices. Similar to the way Verbelen et al [141] re-defined a Cloudlet for their work to be a collection of nearby mobile devices, the authors of this work re-define mobile cloud to be a collection of mobile devices; each of these devices is capable of running a partitioned, simplified web service, that makes up part of the larger complex web service. This partitioning is specified by a simple properties XML file, which specifies a business workflow, as to how the com-plex service can be broken up into simple services, and how these simple ser-vices feed data into each other. The break-up of the serser-vices must be defined by the developer in advance. The main goal of the partitioning in this work is not to provide availability in a situation where a mobile host offering a service has failed, but with overcoming the physical resource limitations in mobile devices, making it difficult for them to execute a complex service for many clients. In the work, an orchestrator delegates the broken down services to

"auxiliary mobile hosts", and also oversees the execution defined by the busi-ness workflow. The framework is deployed on a mobile device, rather than a cloud server. Service descriptions are not discussed, and neither is service discovery; the evaluation undertaken by means of a demonstration calls the known service directly.