Context Awareness with Mobile Web Services

For this work which relies on working with services deployed in cloud envi-ronments, an important consideration is how context data can be used with existing web service technologies; both in terms of service discovery, and ser-vice consumption/execution.

To begin exploring how context data can be used with web services, Truong and Dustdar [137] surveyed existing approaches to how context has been pre-viously used with web services in the literature. Several context frameworks were evaluated in terms of their compatibility with web services under differ-ent criteria. The criteria used is a superset of the criteria that was specified at the start of this section as being of interest to the work in this thesis, and is as follows:

• Type of Context Information Supported

Location, Activity, Network Status, Devise Profile, etc.

• Context Representation

Ontologies, Objects, UML, WSDL (an extended version), etc.

• Use of Sensors

Mode (automatic/manual), Sensing Technique (polling/request-based),

Sensor Interface (Web Service, specific API), Data Retrieval and Pushing (Query, Subscription, push-based).

• Context Storage

Storage Model (centralised/distributed), Storage Database (XML, rela-tional), Access Interface (web service, other approach), Request Specifi-cation (SQL, SPARQL).

• Context Distribution

Overlay Network Distribution, Direct Transport Distribution, Access Mechanism

• Context Reasoning

Support for Reasoning, Semantic Support

• Context Security and Privacy Techniques

Encryption, Authentication, Authorisation, Privacy Specification

• Adaption Techniques

Adaption Purpose, Adaption Specification, Adaption Layer

In the work, each project from a specific set of web service frameworks that supported the use of context was evaluated under each criteria listed above (mobility was not a factor in the study). None of the projects in the study met all of the criteria that was specified. The main issues discovered were the lack of support for distributed context management (most approaches relied on a centralised server), the use of XML as context representation (note that ontolo-gies can be represented as XML markup, but here it is meant that pure XML is used without ontologies), and security and privacy mechanisms being inade-quate. An example of one of the projects studied is a middleware system by Gu et al [47]. This middleware, known as Service-Oriented Context-Aware Mid-dleware (SOCAM) provides an architecture for building context aware sys-tems. As recommended by Strang and Linnhoff-Popien, they define a formal ontology for representing context data that can be used in a smart-home set-ting; the ontology is marked up using RDF, the Resource Description Frame-work, a W3C standard, normally used for modelling web-based resources in a descriptive manor with meta-data.

In regards to mobile cloud and context awareness, work by Han et al [49] uses

a client-server proxy approach to adapt the context of the mobile device, to the fetching of web service based resources, based on the state of the mobile network connection, in an implementation called AnyServer. The focus of the work is not a generic use of context for applications, as with other works. Ad-ditionally, a work by Hyun-Jung and Kim [57] provides a framework, which detects gaps in mobile context resulting from the changing state of the user, so that missing context, can be provided to services, which require context that may be continuously changing.

There are many sources of context. The use of the previously mentioned con-text history for inferring missing concon-text is presented in the work by Hong et al [52]. New context can be inferred from context history, so that if new context is missing, or if energy should be saved on the mobile device by not collecting new context, the context engine will not fail to provide context when required, with some level of confidence. In the work by Beach et al [10], the authors im-plement a framework for fusing context data from the mobile, its sensors, and social networking sources such as Facebook, to develop a full context profile of the user.

There are also existing mobile cloud applications and middleware systems which make use of context. One example of such a work is that of Abowd et al [1], called Cyberguide, which uses the location and location history of a user to replicate functionality and services offered by a real tour guide. The previ-ously discussed mobile cloud SOA mashup middleware by Wang and Deters [144] utilises context for providing web service mash-ups to users, along with experimental applications they developed for testing, which use collected con-text for their operation.

2.4.4 Discussion

Building context awareness into a mobile cloud solution is an essential factor in personalising the user experience, and for really utilising the sensing devices that mobile devices bring, compared with their desktop counterparts. Con-sider the Cloudlet, code offloading, application partitioning, and remote dis-play techniques for mobile cloud computing discussed earlier in this review.

These approaches are incompatible with context-awareness applications.

Taking the Cloudlet approaches [117] [141], and the remote display works [125]

[124], these are based on morphing desktop operating systems, into a form for

use on mobile devices. These approaches do not unique cater to the mobile device. Desktop operating systems are not designed to make use of on-board sensors that feature on mobile devices, and so they must be ruled out of a solu-tion involving context awareness (at least without further extended work and modification to the underlying software). Code offloading works and appli-cation partitioning solutions, have the benefit of uniquely catering to mobile users, because these projects work with native mobile applications, that are capable of using sensor data. However, this would mean that the parts of the application that are responsible for communicating to the sensors and re-trieving the data, could not be separated from the mobile device, and must be executed locally.

The use of middleware approaches deployed on the mobile device can be a useful solution that uniquely caters to mobile devices. Additionally, the use of context data with web services can also uniquely cater to mobile experi-ences. Services can receive raw context data from the mobile device collected from sensors. Yet, these are not straightforward solutions either. As seen from the literature, repeatedly collecting data from sensors, and processing that data into context is not a cheap operation, considering the resource con-straints present in mobile devices. Works such as the Hydrogen approach [51], where the entire middleware solution is deployed locally on the device, can cause strain on the physical resources such as the CPU, and repeated sensing and data collection drains the device battery. The Context Dictionary approach taken by Lowe et al [85], where the heavy computation is offloaded to a server, is the key idea to save resources, and of course, is fully compatible with the aim of mobile cloud computing.

Other aspects that must be considered in the solution, from a mobility per-spective, include device disconnection, which can prevent the server responsi-ble for collecting the sensor data from receiving fresh context from the mobile device. Again, the context history solution by Lowe et al [85], can be used to infer new context from historical context, if fresh context is not available. An-other reason why this is important is because even with the server responsible for the computationally heavy work, constant collection of context data, and sending it to this server, is not a cheap process.

In the next section, the use of web services for the mobile cloud computing paradigm is examined.