Context-Aware RESTful Services on Mobile Devices

Charl van der Westhuizen1, 2

and Marijke Coetzee1

Academy of Computer Science and Software Engineering

University of Johannesburg1, P. O. Box 524, Auckland Park 2006

and SAP P&I BIT Mobile Empowerment2

charl.van.der.westhuizen@sap.com1; marijkec@uj.ac.za

2

Abstract—Web accessible services on mobile devices such as smart

phones and tablets are a reality in today’s age. Services hosted on

mobile devices consume valuable device resources such as battery

power, network connectivity, and Global Positioning Systems (GPS)

availability. For this research, clients consume web accessible

services, provisioned from mobile devices acting as service

providers. A challenge for constrained mobile devices is how the

efficiency and discovery of web accessible services on mobile

devices can be improved. To address this, a framework is presented

that considers context information focusing on lightweight services

and their discovery.

Keywords—Mobile service providers; Android RESTful

services; Context manager; Provisioning framework.

I. INTRODUCTION

Today, mainstream service providers such as Yahoo [1] and Google [2] are exposing more and more of their services via REST over the Internet. Exposing REST services from traditional server environments is common, but to date not much research has been done on the provisioning of RESTful services on mobile devices [3]. The use of mobile devices as hosts has limitations, making the provision of RESTful services limited in scope.

As the use of REST services on mobile devices is not common, consider the following scenario. In a corporate environment, employees may be in different places on business trips. A manager would like to push updates on projects to the e.g. Android [4] mobile devices of employees in real time, without the device polling it from the server. Furthermore, the manager can get the current location of the employee by sending an automated request to the employee's mobile device to access the phones’ location. In each case, direct machine to machine communication takes place between two mobile devices, with no human involvement. To ensure user satisfaction, issues to consider when requests are fulfilled are whether the mobile device has adequate resources such as battery life and network connectivity. A key challenge is therefore the lack of software development frameworks.

The objective of this research is to create a framework for the provisioning of context-aware RESTful services. In the next section, REST is introduced and its deployment on mobile devices is explored. Thereafter context-aware mobile device systems, requirements of RESTful services on Android device and context-aware mobile device systems are discussed. Section VI discusses the current state-of-the-art research, followed by the framework for provisioning REST service on mobile devices.

II. REST

RESTful services are designed using the REST architectural style that focuses on a system's resources, considering how resource states are addressed and transferred over a Web protocol, by a wide range of clients written in different languages [5]. REST is not limited to a single protocol for communication, but normally uses HTTP, because of its popularity on the Web. In principle, using a REST service instead of commonly used SOAP web service, should result in a performance improvements and smaller message sizes [6].

The REST architectural style is ideal for exposing resource on a mobile device for many different reasons. Standard HTTP is simple to use when creating API’s (Application Programming Interfaces) and developing clients; different message formats such as JSON (JavaScript Object Notation) and XML (Extensible Markup Language) [7] can be used; REST has good performance and scales well [8]. There are drawbacks to consider such as no standard discovery mechanism, which is worsens even more if the services is hosted on a mobile device, connected to mobile operator networks that use NAT (Network Address Translation) [9].

To understand how context-awareness can support RESTful services hosted on mobile devices, the next section describes context-aware mobile device systems.

III. CONTEXT-AWARE MOBILE DEVICE SYSTEMS

A general definition of context-aware computer systems is “Context is any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and application themselves.” [10]. Löwe et al. [11] defined the core of context as any information available to be used to characterize the situation of the user. Abowd et al. [10] describes context-aware application as using context to provide improved services or information to the user.

Löwe et al (2012) [11] defined five categories of context-aware application based on the research of Schilit et al. (1994) [12] and Pascoe, J (1998) [13]. For this research, two of these categories identified are discussed.

• Contextual information applications rate and match information by context. The context-aware content in supplied by the context-aware application itself. For example, the history of application usage and the current context are analysed to create new context [11].

SAP P&I BIT Mobile Empowerment

National Research Foundation

The 8th International Conference for Internet Technology and Secured Transactions (ICITST-2013)

978-1-908320-20/9/$25.00©2013 IEEE 350

• A context-triggered action applications eliminate input provided by the user. For example, the application enables a mobile device Wi-Fi [14] connection if the user is at home or the application loads information that the user is most interested in based on the users behaviour, e.g. a context-aware news application [11].

The efficiency of the service delivered by the RESTful service provider on a mobile device can thus be improved by utilising these categories of context-awareness. Next, the requirements for context-aware RESTful services on Android devices are discussed.

IV. REQUIREMENTS FOR A CONTEXT-AWARE RESTFUL

SERVICE FRAMEWORK

The framework for context-aware RESTful services on

Android devices need to meet two requirements, identified by

the authors, namely efficient and lightweight service

provisioning and discoverability of services. These

requirements are now discussed in more detail.

A. Efficient and lightweight service provisioning

Efficient and lightweight service provisioning refers to the provision of RESTful services that do not exhaust the limited valuable resources available on a mobile device, as these devices have constraints that need to be overcome [15]. Constraints of mobile devices include [16] limited battery life, processing power, data usage charges, and network issues. By using context, efficient and lightweight services can be better provisioned. This can be done by compressing data interchange messages, and reducing the energy consumption of the mobile device when providing web accessible services [15] [16]. To overcome the verboseness of XML, the more compact JSON interchange format is chosen as it uses fewer resources and performs better [8].

The context of the mobile devices refers to the environment of the mobile device, such as connectivity, battery level, location and time of day. A context-aware RESTful service can use the mobile device context, to improve the services exposed to clients. For example, by monitoring the battery power, the provider may decide to limit the services offered. Even though a lightweight service can be defined, service discovery challenges still exist, which are discussed next.

B. Discovery

Even if an efficient, lightweight RESTful service can be provided, it is of no use if it cannot be discovered. Discovery finds RESTful services that satisfy clients’ desired computational requirements [17]. RESTful service provisioning on mobile devices presents new challenges to discovery mechanisms [18] such as dynamic mapping of resources and network independence. Mobile devices dynamically bind to network nodes, consequently changing network address. Therefore the resource mapping of traditional discovery mechanisms are not accurate [18]. Centralised approaches for discovery mechanisms deployed on mobile devices are not be feasible, due to resource constraints and hardware limitations. Furthermore, clients and

RESTful service providers need to be connected to the Internet or the same network as a centralised server.

Discovery mechanisms introduce the client and provider of the RESTful services to each other, using discovery descriptions that need to be stored somewhere. Compared to SOAP using a comprehensive WSDL description for discovery, RESTful services are only described by simple resource representations. For REST, clients use a URI to access the service, consuming the service similarly to accessing a web page. Using SOAP, clients use registries to locate services, but no such central registries for RESTful service descriptions exists, making discovery of RESTful services difficult.

In this regard, context can be used to improve discovery mechanisms. A context-aware discovery mechanism can use context information to decide which method of discovery is suitable at a specific point of time in the environment. For example, a discovery mechanism can act as a DNS (Domain Name Server), when connected to a less mobile network connection, such as Wi-Fi, whereas the discovery mechanism could resort to a P2P (peer-to-Peer) base discovery method, when connected to a 3G network.

In order to gain an understanding of current research in context-awareness for mobile device systems, requirements stemming from this environment are discussed in the following section.

V. REQUIREMENTS FOR RESTFUL CONTEXT-AWARE

MOBILE DEVICE SYSTEMS

Over the years, many context-aware system models, frameworks and middleware for mobile systems have been introduced and researched. Three requirements, identified by an evaluation of this research, that is deemed to be specific to the RESTful service applications have been identified by the authors as follows:

• Account for resource constraints of mobile devices: Context-aware RESTful services should utilise resources to support smart decisions to reduce the overall resource consumption, to not exhaust the limited valuable resources available on a mobile device. Context-aware services should overcome constraints of mobile devices, namely limited battery life, processing power, data usage charges and network issues.

• Integrate with existing applications and frameworks: Implementing context-aware RESTful services should not constrain the developer to use only certain predefined technologies. For example, the developer may be constrained to implement the entire application/service in a custom scripting language.

• Allow multiple services to access the same context / resources at the same time: Multiple services and applications should be able to consume the context provided by the context-aware mobile device system at the same instance. The context-aware RESTful services should thus not "lock" the context from other services. The mobile device should provide the same QoS to other applications and services deployed without delay. For example,

The 8th International Conference for Internet Technology and Secured Transactions (ICITST-2013)

978-1-908320-20/9/$25.00©2013 IEEE 351

navigation services needs to use location context without delay.

Technologies and research that satisfy the requirements identified can form the basis of the framework. The following section discusses state-of-the-art research in terms of the requirements for context-aware RESTful mobile device systems and services.

VI. STATE-OF-THE-ART RESEARCH

In order to provide a foundation for the development of the framework, this section investigates state-of-the-art research to identify technologies that satisfy the requirements that were identified. This section considers current work on web services provisioning on mobile devices, and context-aware mobile device systems.

A. Web services provisioning on mobile devices

Web services were first provisioned on mobile hosts using SOAP, and later REST, as highlighted by the next two solutions. The main issue addressed by this change was to make the service lightweight. Furthermore, the dynamic nature of mobile devices require desentralised approaches to discovery, implying that solutions using registries defined by UDDI, are not optimal [19] to implement.

1) Web service handler with Mobile P2P Srirama et al [19] developed a lightweight SOAP-based

mobile host with Personal Java for mobile devices. The approach is more efficient and lightweight than other SOAP Web service approaches, since kSOAP [20], a compressed version of SOAP, was used. XML formatting was still used for data interchange messages and service descriptions, resulting in the same drawbacks as SOAP regarding scalabliltiy and caching [8].

For discovery, a move was made to Mobile P2P (peer-to-peer), a discovery mechanism based on P2P discovery mechanisms [21]. Mobile P2P uses a P2P protocol specification called JXTA (Juxtapose) [22] an open source and freely available P2P protocol [22]. Mobile P2P is a decentralised discovery mechanism solution [21] where resources are distributed among different nodes. Thus, if any node fails the discovery mechanism still continues to work.

2) Mobile Host with ZeroConf Paniagua [19] implemented a RESTful mobile provider on

Android, namely Mobile Host. Mobile Host utilises the Open Services Gateway initiative (OSGi) framework using a REST handler to manage RESTful service interaction with clients 19]. Mobile Host is more efficient and lightweight as a result of using RESTful services and HTTP [13].

For discovery, JmDNS, a DNS (Domain Name Server), is used to advertise web accessible services within a network. JmDNS is an Android implementation of ZeroConf [23], which is built into Android 4.1 OS. A local domain name is assigned by JmDNS to a mobile device within the network. Services are advertised in JmDNS and clients can query JmDNS to find the services they require [19].

3) Summary of state-of-the-art approaches Table I summarises the different approaches to provision

web accessible services on mobile devices. The table evaluates the approaches based on the requirements identified in section III, on three different levels: poor, average, and good.

TABLE I. EVALUATION OF APPROACHES.

Efficient and

lightweight service

provisioning

Discovery

1. Web

service

handler

Average - communicates with

kSOAP messages.

Average - uses XML formatted JXTA advertisements.

2. Mobile

Host

Good - REST

architecture with JSON

messages.

Average - JmDNS have

information of local services in

the network.

Efficient and lightweight service provisioning is satisfactorily address by the research on Mobile Host, but it is clear that there is no approach that completely satisfies the requirements relating to discovery, namely a decentralised approach deployed on mobile devices and network independence. Web service handler with mobile P2P uses a decentralized approach, but uses XML formatted messages for JXTA advertisements [22]. Mobile Host with ZeroConf is a decentralised solution, but only works if clients and providers are connected to the same network and not over the Internet.

B. Context-aware mobile systems

Two context aware mobile device systems, in the form of middleware, are now discussed.

1) LoCCAM LoCCAM [23] is a mobile device centric approach of

context management. Context acquisition components utilises mobile device sensors, such as GPS, gyroscope and barometer. Components are implemented as OSGi (Open Services Gateway initiative) bundles and deployed on Android devices. All context data gathered by the acquisition components are published on a coordination mechanism. The solution extends the android.app.Service [23], thus exposing it to other applications to be used. The self-adaptation and life cycle manager allows context acquisition component implementations to be removed before the deployment to the LoCCAM service, for cases where e.g. the specific Android devices does not have a GPS sensor [23].

The coordination mechanism ensures that resources are managed in manner to reduce system load. The self-adaptation and life cycle manager ensures that resource consumption is kept to a minimum, as only resources that are required are utilised. LoCCAM is easily integrated into existing Android applications with the Android.app.Service provided. Multiple services and applications use the context provided by the coordination mechanism at the same time. As the Android.app.Service class is supports multi-threading.

2) Mobicon Context-aware applications and personal sensor networks

are facilitated by a middleware framework, called MobiCon [24]. MobiCon provides API’s to applications that requires sensor data. MobiCon provides a runtime for context-aware

The 8th International Conference for Internet Technology and Secured Transactions (ICITST-2013)

978-1-908320-20/9/$25.00©2013 IEEE 352

applications, thus multiple applications requiring context can run on MobiCon simultaneously. MobiCon offers a custom interface for users acquiring context data. The sensor broker acquires context data from the sensor manger and send it to the context processor [24].

Mobicon takes into account the resource constraints of mobile device by using a smart scheduler. A developer is constraint to implement applications using Mobicon platform. Context is gathered form different sources and is made available to multiple applications.

3) Summary of state-of-the-art approaches Table II summarises the approaches by answering is the

three requirements are answered or not.

TABLE II. EVALUATION OF CONTEXT-AWARE MOBILE DEVICE SYSTEMS.

Account for

resource

constraints of

mobile

devices

Easily integrate

with existing

applications and

frameworks

Allow multiple

services to access

the same context /

resources at the

same time

1. LoCCAM Yes, it utilises

a loosely coupled

sensor

approach.

Yes, other Android

applications make use of the

Android.app.Service

Yes,

Android.app.Service supports multi-

threading

2. Mobicon Yes, resource

consumption

is reduced by

smart

scheduling.

No, applications are

developed

specifically to run on

the Mobicon

platform.

Yes, it gathers the

context and provides

it multiple

applications.

The framework is presented next based on the elements

identified in this research to overcome the challenges of mobile devices and to satisfy the requirements for context-aware RESTful mobile services.

VII. FRAMEWORK FOR PROVISIONING CONTEXT-AWARE

RESTFUL SERVICES ON ANDROID DEVICES

The framework architecture and context manager component is now discussed, followed by an evaluation against the identified requirements.

A. Architecture

In Figure 1 on the next page, it can be seen that a number of mobile devices communicate with each other across two different networks. These networks exchange context-aware RESTful services advertisements through mobile P2P to ensure that no direct connections between devices in the networks are required. Some of the devices are context-aware RESTful service providers, who can also be RESTful service consumers at the same time. Devices in both networks have embedded JmDNS servers, where at least one device in both networks establishes a mobile P2P connection over the internet.

The architecture of RESTful service providers is illustrated in Figure 1 by the left block. The framework utilises a HTTP handler component that consists of a HTTP listener and cache. The HTTP listener listens for requests from consumers that are forwarded to the REST handler. The REST handler interprets the requests and maps it to the context-aware RESTful services. The RESTful services utilises the context manager,

which acquires the Android device context, such as location and network connection. The RESTful service forwards the results of the service to the HTTP handler, which responds to the consumers.

B. Context Manager

The context manager shown in Figure 1 applies information provided by the the RESTful service provider for two purposes namely: application of contextual information and context-triggered actions.

To ensure efficient and lightweight service provisioning, the application uses historical data as context input. For example, the application can offload some of its services and processing tasks to a cloud infrastructure during the time of day, week or month the demand for its services are high by analysing historical data to determine peek times. The context manager takes the environment of the mobile device into account, to deliver better services or improve performance. For example, if the device battery is low on power or not connected to a network or it is after working hours the context manager can then turn off the device’s GPS, disconnect from resource heavy networks, like Bluetooth [25] to reduce energy consumption.

The discovery mechanism utilises the context manager to decide the type of discovery method to use. The context manager instructs the discovery mechanism to either use the JmDNS based discovery method or Mobile P2P discovery method, based on the network connection and location of the node in the network.

Next, the framework is discussed in terms of the requirements identified.

C. Requirements

1) Context-aware RESTful services on Android The framework utilises the REST architectural style and

the context manager using interchange messages formatted in JSON, sent over HTTP to ensures good compression of messages [26]. HTTP reduces overhead, increases simplicity and reduce processing time, thus increasing efficiency. The framework utilises a REST handler, to abstract and simplify development of RESTful services. The context manager reduces the resource load by making smart decisions on services delivered.

The discovery mechanism in the framework is decentralised. Each Android device is also a JmDNS server, which improves discovery of the context-aware RESTful services. Combining JmDNS, which is network dependent, with Mobile P2P which is network independent [22], with XML JXTA advertisements [23] supports a discovery mechanism that is network independent and efficient. This framework addresses the disadvantage of Mobile P2P networks by limiting its use within a single network. The higher performing JmDNS is used locally and Mobile P2P is only used as a last resort when communication is required across different networks. This defers the performance disadvantage of Mobile P2P to a higher network level, such as WAN (Wide Area Network).

The 8th International Conference for Internet Technology and Secured Transactions (ICITST-2013)

978-1-908320-20/9/$25.00©2013 IEEE 353

Figure 1. Architecture for provisioning RESTful services.

2) RESTful context-aware mobile device systems The context manger accounts for the resource constraints

of mobile devices, by utilising a sleep – wake approach. Thus sensors only become active if context are required at that instant. The context manager is configurable to allow developers or services consumers to specify the minimum time delay between sensor updates.

The context-manager extends the Android.app.Service class. By extending a native Android class ensures easy integration with existing applications and new Android applications. The extended Android.app.Service class is exported in the Android Manifest. By exporting the services, other applications and services can make use of the context manager at the same instance.

In the following section prototype implementation details are discussed.

VIII. IMPLEMENTATION

A context-aware RESTful service provider, shown in Figure 2, was developed for Android devices. A PAW Server [27], which hosts PHP (Hypertext Preprocessor) [28] web pages was used as server implementation. PAW server is used to deploy web pages stored on a mobile device itself and PHP web pages expose RESTful services. The PAW server is responsible for receiving HTTP requests, managing the connection between the clients and the provider, and mapping different REST services to URI’s. RESTful services exposed the available resources of the device.

Interaction between clients and a RESTful service provider is now descibed. In Figure 2, the context manager sends a request for a resource to an employee’s mobile device. A PAW server is deployed on an Android mobile device with a HTTP listener, which listens to the requests of a tunnel the requests to a URI mapper. The URI mapper redirects the request to a context-aware RESTful service. The RESTful service processes the request, by making use of a JSON parser. The context-aware RESTful service retrieves the resource by making use of the context manager.

Figure 2: REST services provisioned on an Android device.

The 8th International Conference for Internet Technology and Secured Transactions (ICITST-2013)

978-1-908320-20/9/$25.00©2013 IEEE 354

The context manager determines the type of sensor to activate and sends the data back. For example, a RESTful service requests the location of the device; the context manager sends the GPS or network location back to the RESTful service, based on the current battery level. Acquiring the GPS location, uses more resources, but is more accurate. A representation of the resource is then created by the JSON parser. The representation is then redirected back to the client, through the HTTP listener.

IX. CONCLUSION

The contribution of this framework to current research is the Context Manager, which increases performance and reduces resource consumption. A new hybrid,decentralised discovery mechanism is identified for a possible solution for the discovery of RESTful service provided on mobile devices. The discovery mechanism utilises both Mobile P2P and JmDNS as a possible solution. The shortcoming of the current framework is the exclusion of technical implementation details required for implementation. The discovery mechanism provided only solves the current discovery issue to a certain degree, by delaying the performance bottleneck of mobile P2P.

ACKNOWLEDGMENT

The support of SAP P&I BIT Mobile Empowerment and the National Research Foundation (NRF) under grant numbers 81515 and 81201 toward this research is hereby acknowledged. Opinions expressed and conclusions arrived at are those of the authors and not necessarily to be attributed to the companies mentioned in this acknowledgement.

REFERENCES

[1] Yahoo, “Yahoo,” 13 11 2013. [Online]. Available:

http://www.yahoo.com. [Accessed 13 11 2013].

[2] Google, “Google,” 13 11 2013. [Online]. Available:

https://www.google.com. [Accessed 13 11 2013].

[3] A. E. F. R. D. &. R. R. Taherkordi, “RESTful Service Development

for Resource-Constrained Environments,” in REST: From Research to

Practice, New York, Springer, 2011, pp. 221-236.

[4] Android, “Android,” 31 10 2013. [Online]. Available:

http://www.android.com/ . [Accessed 13 11 2013].

[5] R. Fielding, “Representational State Transfer (REST),” in In

Architectural Styles and the Design of Network-based Software

Architectures, Doctoral Dissertation, Irvine: University of California,

2000, pp. 76 - 106.

[6] World Wide Web Consortium, “Extensible Markup Language

(XML),” 2003. [Online]. Available: http://www.w3.org/XML/.

[Accessed 08 05 2013].

[7] Levkowetz, H.;Vaarala, S.; The Internet Society; Network Working

Group, “Mobile IP Traversal of Network Address Translation (NAT)

Devices,” 2003. [Online]. Available:

http://www.ietf.org/rfc/rfc3519.txt. [Accessed 18 05 2013].

[8] G. D. Abowd, A. K. Dey, P. J. Brown, N. Davies, M. Smith and P.

Steggles, “Towards a Better Understanding of Context and Context-

Awareness,” in Handheld and Ubiquitous Computing, Berlin

Heidelberg, Springer , 1999, pp. 304-307.

[9] J. Pascoe, “Adding generic contextual capabilities to wearable

computers,” in Second International Symposium on Wearable

Computers. Digest of Papers, Pittsburgh, PA, USA, 1998.

[10] Wi-Fi Alliance, “wi-fi.org,” 13 Nov 2013. [Online]. Available:

http://www.wi-fi.org/. [Accessed 13 Nov 2013].

[11] D. Guinard, V. Trifa, S. Karnouskos, P. Spiess and D. Savio,

“Interacting with the SOA-Based Internet of Things: Discovery,

Query, Selection, and On-Demand Provisioning of Web Services,”

Services Computing, IEEE Transactions on, vol. 3, no. 3, pp. 223 -

235, 2010.

[12] C. Paniagua, “Discovery and Push Notification Mechanisms for

mobile Cloud Services (Master Thesis),” in University Of Tartu,

Faculty Of Mathematics And Computer Science, Institute of Computer

Science., 2012.

[13] kSOAP, “kSOAP,” 13 Nov 2013. [Online]. Available:

http://ksoap2.sourceforge.net/. [Accessed 13 Nov 2013].

[14] S. N. Srirama, M. Jarke and W. Prinz, “Mobile Web Service

Discovery in Peer to Peer Networks,” in 19th International

Conference on Advanced Information Systems Engineering

(CAiSE'07), Trondheim, Norway, 2007.

[15] Sun Microsystems, “JXTA - The Language and Platform Independent

Protocol for P2P Networking,” 25 Jan 2010. [Online]. Available:

http://jxta.kenai.com/. [Accessed 25 April 2013].

[16] Zero Configuration Networking, “Zero Configuration Networking

(Zeroconf),” 18 Oct 2013. [Online]. Available:

http://www.zeroconf.org/. [Accessed 30 Oct 2013].

[17] M. E. F. Maia, A. Fonteles, B. Neto, R. Gadelha, W. Viana and R. M.

C. Andrade, “LOCCAM - loosely coupled context acquisition

middleware,” in Proceedings of the 28th Annual ACM Symposium on

Applied Computing (SAC '13), New York, NY, USA, 2013 .

[18] Y. Lee, S. S. Iyengar, C. Min, Y. Ju, S. Kang, T. Park, J. Lee, Y. Rhee

and J. Song, “MobiCon: a mobile context-monitoring platform,”

Communications of the ACM, vol. 55, no. 3, pp. 54-65 , 2012.

[19] Bluetooth special interest group, “Bluetooth,” 13 Nov 2013. [Online].

Available: https://www.bluetooth.org/. [Accessed 13 Nov 2013].

[20] JSON, “Introducing JSON,” 09 Oct 2013. [Online]. Available:

http://www.json.org. [Accessed 30 Oct 2013].

[21] PAW Server for Android, “PAW Server for Android,” 17 Sept 2013 .

[Online]. Available: http://paw-android.fun2code.de/. [Accessed 30

Oct 2013 ].

[22] PHP, 14 Nov 2013. [Online]. Available: http://php.net/. [Accessed 14

Nov 2013].

[23] C. Pautasso, O. Zimmermann and F. Leymann, “Restful web services

vs. "big"' web services: making the right architectural decision,” in

17th international conference on World Wide Web, New York, USA,

2008.

[24] H. Hamad, M. Saad and R. Abed, “Performance Evaluation of

RESTful Web Services for Mobile Devices,” International Arab

Journal of e-Technology, vol. 1, no. 3, pp. 72-78, 2010.

[25] R. Löwe, P. Mandl and M. Weber, “Context Directory: A context-

aware service for mobile context-aware computing applications by the

example of Google Android,” in IEEE International Conference on

Pervasive Computing and Communications Workshops (PERCOM

Workshops), Lugano, 2012.

[26] B. Schilit, N. Adams and R. Want, “Context-Aware Computing

Applications,” in In First Workshop on Mobile Computing Systems

and Applications, Santa Cruz, California, USA, 1994.

[27] Y. Kim and K. Lee, “A Light-weight Framework for Hosting Web

Services on Mobile Devices,” in In Fifth European Conference on

Web Services, Halle, Germany, 2007.

[28] Q. Xue and A. Ganz, “Ad hoc QoS on-demand routing (AQOR) in

mobile ad hoc networks,” Journal of Parallel and Distributed

Computing, vol. 63, no. 2, pp. 154-65, 2003.

[29] S. Srirama, M. Jarke and W. Prinz, “Mobile Web Service

Provisioning,” in IEEE International Conference on Internet and Web

Applications and Services/Advanced, 2006.

The 8th International Conference for Internet Technology and Secured Transactions (ICITST-2013)

978-1-908320-20/9/$25.00©2013 IEEE 355