A Framework for Provisioning RESTful Services on Mobile Devices

Charl van der Westhuizen1 and Marijke Coetzee2

Academy of Computer Science and Software Engineering University of Johannesburg1, 2, P. O. Box 524, Auckland Park 2006

and SAP P&I BIT Mobile Empowerment Pretoria1

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

Abstract—Web services that are accessible on mobile devices such as smart phones and tablets are a reality in today’s age. Web services hosted on mobile devices consume valuable device resources such as battery power, connectivity to network, and Global Positioning Systems (GPS) availability. In this context, a mobile client consumes web services provisioned by mobile devices, acting as service providers. The purpose of the research is to identify a framework that can possibly improve the efficiency, quality of services and discovery of provisioning web services on mobile devices. The framework considers battery life, message time and size, processing required, availability, reliability, scalability and the discovery of these Web accessible services. By using the framework that enables context-aware services, the efficiency and quality of services can be improved. Discovery of these services are improved by utilizing a hybrid model of both Mobile P2P and JmDNS.

Keywords—REST; RESTful services; Mobile hosts; Mobile service providers; Android RESTful services; Context manager; Provisioning framework.

I. INTRODUCTION

In 2009 there were 4.7 billion mobile subscribers worldwide. This increased to 6 billion at the end of 2011. It is predicted that the number of mobile subscribers will reach 6.9 billion at the end of 2013 and 8 billion in 2016 [1]. With the number of mobile devices and mobile device capabilities increasing, it makes sense to provide services that are traditionally only available on desktop and wired environments available on mobile devices [2].

The World Wide Web Consortium (2004) [3] states that there are two major classes of web services namely SOAP (Simple Object Access Protocol) and REST (Representational State Transfer) compliant web services. A SOAP compliant web service is a software system designed to support interoperable machine-to-machine interaction over a network with an interface described in a machine-processable format. Such a service interacts using SOAP messages to invoke service operations. A RESTful service is accessed over HTTP (Hypertext Transfer Protocol), using the REST architectural style of development [3]. RESTful services manipulate representations of Web resources using a uniform set of stateless operations with the aim to enhance simplicity by limiting the operations that can be performed.

Even though there is a shift to the adoption of REST by mainstream service providers such as Yahoo [4], Google [5], and Facebook [6], not much research has been done to date on the provisioning of REST services on mobile devices [7]. It has also been proven that RESTful services outperform SOAP-based web services in mobile network environments [8].

Generally, RESTful services are hosted on servers. The use of mobile devices as hosts has limitations and this makes the provision of RESTful services limited in scope. To understand the provisioning of REST services in the context of mobile device usage, consider the following scenario where an employee’s mobile device is used as a provider of services, and the manager of the employee uses either a mobile device or personal computer as the requestor or client of the services.

In a corporate environment, a manager would like to send out an update of a project to different employees working on the project. These employees may be in different places on business trips. The Android [9] device of an employee should be able to receive updates in real time, without having to poll it from the server, thus the update should be pushed to the phone. Furthermore, the manager might also want to know the current location of the employee. In this case, as the employee may forget to update and upload his location for the manager, an automated request is sent to the employee's Android mobile device to access the phones’ location. There is direct machine to machine communication taking place between two devices, with no human involvement. This is achieved by the hosting of services on the mobile device to allow automated and access to the resources on the device. A key challenge for the hosting of RESTful services of mobile hosts is the lack of software development frameworks.

The objective of this research is to create a framework for the provisioning of such RESTful services on Android mobile devices. This framework needs to include a suitable discovery mechanism that satisfies the stated requirements. Next REST is introduced. Thereafter, the requirements of RESTful services on Android device are discussed. Section IVdiscusses the current state-of-the-art research, followed by the framework for provisioning REST service on mobile devices.Thereafter the implementation of the prototype is discussed.

SAP P & I BIT Mobile Empowerment Pretoria.National Research Foundation.

II. REST REST is an abstraction style aimed at distributed

hypermedia systems, which defines a set of architectural principles [10]. RESTful services are designed by 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 [10]. REST is not limited to a single protocol for communication, but normally uses HTTP, because of its popularity on the Web. REST concentrates on a shared agreement of data types and reveals only what is required in a given interface. The data elements of REST are: [10]

Representation of resource, e.g. an html web page, location.html. Resources and their identifiers, e.g. the provider’s location and the corresponding URI (Uniform Resource Identifier),http://www.example.com/location. Representation metadata, e.g. data describing the representation, “Content-Type: application/json”.Resource metadata, e.g. data describing the resource, “Vary: *”.Control data, e.g. data overriding default behavior of connecting elements, “Cache-Control: max-age=3600”.

REST is used to expose resources through the Web using URIs (Uniform Resource Identifier) such as web pages [11]. For example, location of the employee’s mobile device is represented as a web page. The manager can access this resource by requesting a URI that is similar to: [11]http://www.employee.com/location.

The “location” part of the URI is the URN (Uniform Resource Name). This URN is the resource that is requested. The service hosted on the Android mobile device responds by sending the representation of the resource back to requester, e.g. employeeLocation.html. The resource representation places the requester in a different state (transfers state), the architectural style is called REST. In principle using a REST service instead of the widely used SOAP web service, should result in a big performance improvement and smaller message sizes [10].

The REST architectural style is ideal for exposing resource on a mobile device for many different reasons. Standard HTTP is simple to use for creating API’s (Application Programming Interfaces) and for developing clients. REST permits different data interchange formats for example JSON (JavaScript Object Notation) [12] and XML (Extensible Markup Language) [13], whereas other architectural styles are limited to only one format, e.g. SOAP messages are only formatted in XML by definition. REST has good performance and scales well [14].

There is no standard interface such as WSDL (Web Services Description Language) and UDDI (Universal Description Discovery and Integration) registries for RESTful services to enable discovery of services. Unlike SOAP web

services, there is no broker to introduce RESTful services to clients. A service client needs to have the URL of the specific RESTful services to consume the service. Provisioning RESTful services from a mobile device worsens the issue of discovery even more. Mobile devices are normally connected to mobile operator networks which use NAT (Network Address Translation) [15]. Thus the URL of the service may change at any time and the provider is inaccessible from outside the mobile operator network.

III. REQUIREMENTS FOR RESTFUL SERVICES ON ANDROID

To define a framework for RESTful services on Android devices, a set of requirements are defined by the author:

Efficient and lightweight service provisioning. Quality of service (QoS). Discoverability of services.

These are discussed in the following sections.

A. Efficient and lightweight service provisioningEfficient and lightweight service provisioning refers to

providing RESTful service in such a manner that it does not exhaust the limited valuable resources available on a mobile device. Mobile devices have constraints that need to be overcome to provision web accessible services successfully [16]. Constraints of mobile devices include [17]: limited battery life, processing power, data usage charges, and network issues.

The main issues of providing and maintaining web accessible services in an efficient and lightweight manner are [16] [17] [18]:

Reducing the energy consumption of the mobile device when providing web accessible services. Compressing the data interchange messages to the as small as possible. Using a lightweight compression formatting for service descriptions. Effortless parsing of interchanged data messages.

To increase the efficiency of data interchange and satisfy the requirements of applications to interchange data, data interchange formats were developed [18]. To overcome the verboseness of XML, the more compact JSON interchange format is chosen. JSON uses fewer resources and performs better than XML when providing REST services [14]. For the same reason JSON formatting should also be used for service descriptions.

Effortless parsing of interchanged data will reduce the processing time needed, thus reducing the energy consumption. JSON messages are estimated to parse data up to hundred times faster than XML messages [18].

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 provider 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, QoS challenges still exist, which are discussed next.

B. Quality of Service QoS is a general concept that includes properties such as

performance, reputation, reliability and security, availability and scalability [19]. The properties mentioned above are not all included in the scope of this research. The research focuses on three interlinked properties, known as [20]: availability, reliability, and scalability.

Availability of REST services refers to the services on the Android device always being available to the client. The manager wants to push an update about the project to the employee as soon as it is ready by consuming a RESTful service. The employee (provider) should be able to processes the request and respond to the manager in a timely manner [19]. Incompatible networks of the client and provider or limited network connectivity could affect availability.

The reliability of a service refers to the ratio of successful responses [20]. A common reliability issue is when a response is successfully sent, but interrupted during transmission. This may be caused by poor network quality. The response sent previously, by the employee, may not reach the manager due to a network issue.

Scalability is the ability to provide constant QoS regardless of the number of users [20] [21]. Many managers should be able to simultaneously request services on an employee’s device, without a decrease in QoS. Android devices can scale vertically by inserting a bigger memory card into the device. Unfortunately this requires user interaction. Offloading services to cloud environments could be a possible solution [2].

Providing good QoS when provisioning RESTful services on Android devices is challenging for the following reasons:

Android devices need to be connected to a network for the RESTful services to be available. Mobile devices connect to mobile operator networks, which could influence the reliability. For example mobile devices can go out of reach of the mobile operators’ network, thus not accurately responding to clients’ requests.Users interact with Android devices, therefore RESTful services should not exhaust valuable resources.

The QoS can be improved, by providing context-awareservices specific to the consumer’s needs. Context-aware RESTful services can adapt to the environment, to overcome the challenges identified.

C. Discovery Discovery is the process of finding RESTful services that

satisfy the client’s desired computational requirements [22]. Discovery mechanisms need to provide a way in which the REST services descriptions can be stored [23]. Discovery

mechanisms introduce the client and provider of the REST services to each other. Constraints, compared to SOAP, for discovery mechanisms include [23]:

REST resource representations contain services descriptions. SOAP uses WSDL to describe the services. With REST, clients need the URL to access the service. Consuming RESTful services are similar to accessing web pages. SOAP clients use the registry to locate services. Unlike SOAP, no central registry for RESTful service descriptions exists. This implies difficulties with regards to service discovery.

RESTful service provisioning on mobile devices adds more constraints to the discovery mechanisms [2]. This includes dynamic mapping of resources, scalability and network independence. Android devices can dynamically bind to any network node at any time, consequently changing network address. Therefore the resource mapping of traditional discovery mechanisms would not be accurate anymore, but still map to the old network address of the resource [2].

Centralised approaches for discovery mechanisms deployed on mobile devices would not be feasible, due to resource constraints and hardware limitations, previously discussed. A centralised discovery mechanism deployed in a wired environment, would be bound to a specific network. This limits mobility. To find RESTful services, clients and providers need to be connected to the Internet or the same network as the centralised server.

Discovery mechanisms should function across multiple networks without the support of mobile network operators. Thus making development of RESTful services on mobile devices independent of network operators, e.g. developers should be able to independently deploy RESTful services. The following section will discusses state-of-the art research in terms of the requirements defined in section II.

IV. STATE-OF-THE-ART RESEARCH

This section investigates the state-of-the-art research onthe provisioning of web accessible services on mobile devices. Related research approaches are discussed next with regards to requirements previously identified.

A. The Berger et al approach Berger, S. et al., (2003) [24] were successful in

provisioning web accessible SOAP services on mobile devices. By developing a custom web server, their approach is suitable for a closed environment with a local network access point, such as Bluetooth [25] or Wi-Fi [26]. The local access point supplies the provider with a local UDDI registry address. The provider uses SOAP messages to send WSDL descriptions to the UDDI registry. WSIL (Web Services Inspection Language) files are stored on the mobile device, which advertise services and points to WSDL descriptions. This approach lacks efficiency with regards to lightweight

service provisioning. SOAP messages and XML formatting imply poor scalability, since SOAP messages are difficult to cache [14]. Availability and reliability are negatively affected since this approach depends on a single network exclusively.

B. Web service handler with Mobile P2P Srirama et al., [27] developed a lightweight SOAP-based

mobile host with Personal Java for mobile devices. This approach utilises a Web services handler that points to the appropriate web service. This Web service handler is deployed on top of a HTTP web server. Incoming and outgoing HTTP requests are tunneled to and from the handler. The handler reads the HTTP message and de-serializes the SOAP requests.

This approach is more efficient and lightweight than other SOAP Web service approaches, since it uses kSOAP [28], a compressed version of SOAP. However, XML formatting is still used for data interchange messages and service descriptions. kSOAP has the same drawbacks as SOAP, regarding scalability and caching [14]. Avalibility and reliability is addressed by the discovery mechanism of this approach.

Details of the discovery mechanism were omitted by Srirama et al., [27] but later provided by Srirama et al., [29]. Mobile P2P (peer-to-peer) is a discovery mechanism based on P2P discovery mechanisms. Mobile P2P uses a P2P protocol specification called JXTA (Juxtapose) [30]. JXTA is an open source and freely available P2P protocol developed by Sun Microsystems in 2001 [30]. Mobile P2P is a decentralised dicovery mechanism solution. In this approach, resources are distributed among different nodes. Thus, if any node fails the discovery mechanism still continues to work. JXTA defines two main different types of peers / nodes, namely edge peers and super peers. Edge peers send XML formatted advertisements of services to super peers. Super peers store advertisements similarly to UDDI service registries [30].

C. Mobile Host with ZeroConf Paniagua, [2] implements a RESTful mobile provider on

Android, namely Mobile Host. Mobile Host utilises the Open Services Gateway initiative (OSGi) framework, which manages application life cycles [2]. Mobile Hosts implements a REST handler to manage RESTful service interaction, by managing HTTP requests received from clients. The handler passes the request to a Request Resolver, which gets an instance of the required service [2].

This approach implements RESTful services, which improves efficiency. Additionally it is more lightweight since it supports JSON formatting [18]. Mobile Host provides good QoS as a result of using RESTful services and HTTP [14].

JmDNS, a DNS (Domain Name Server), is used by Paniagua, [2] to advertise web accessible services within a network. JmDNS is an Android implementation of ZeroConf, 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 [2]. The next section summarises the approaches discussed.

D. Summary of state-of-the-art approaches Due to the inefficiency of SOAP services, it is not an ideal

solution for provisioning web accessible services from mobile devices. SOAP services lack good QoS, compared to RESTful services in terms of scalability [14]. The dynamic nature of mobile devices implies that a centralised approach, such as UDDI, may not be the best solution [27]. Also, a centralised approach implies that service descriptions be updated constantly.

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 DIFFERENT WEB ACCESSIBLE SERVICE PROVISIONING APPROACHES.

Efficient and lightweight

service provisioning

Quality of Service (QoS)

Discovery

The Berger et al

approach

Poor:SOAP XML formattedmessages.

Poor:Clients should account for unavailability.

Poor:Centralized local UDDI registry.

Web service handler

Average:Communicated with kSOAP messages.

Average:Uses P2P networks. HTTP that scales easily.

Average:Uses XML formatted JXTA advertisements.

Mobile Host

Good:REST architecture with JSON messages.

Good:Multiple JmDNSs on a network.Multicast requestsmessages.

Average:JmDNS have information of local services in the network.

Table I indicates that Mobile Host best satisfies therequirement of efficiency and lightweight service provisioning. The other two approaches use inefficient and heavier SOAP web services. In addition the other approaches use an inefficient data interchange format, namely XML. JSON messages used by Mobile Host ensured that messages are compressed and the REST architectural style guarantees less processing.

Mobile Host [2] with ZeroConf [31] ensures that QoS requirements are satisfied by using RESTful services that scale well. The availability and reliability are increased, by utilising multiple networks. Furthermore ZeroConf, a decentralised system deployed on mobile devices, increases the availability, reliability and scalability [32].

There is no approach that completely satisfied the requirements relating to discovery, which includes a decentralised approach deployed on mobile devices and is network independent. Berger, S. et al., [24] approach makes use of a centralized solution deployed in a wired or static environment. Web service handler with mobile P2P uses a decentralized approach, but uses XML formatted messages for JXTA advertisements [30]. 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. A framework that addresses these constraints is discussed in the following section.

Figure 1. Architecture for provisioning RESTful services.

V. FRAMEWORK FOR PROVISIONING RESTFULSERVICES ON MOBILE DEVICES

The framework provides an approach to provision RESTful services on mobile devices. The frameworks consist of various different components, depicted in Figure 1, which is discussed in this section with reference to the requirements identified.

A. Architecture Figure 1 illustrates how a number of mobile devices

communicating with each other in two different networks. The two networks exchange context-aware RESTful services advertisements through mobile P2P. Direct connections between devices in the networks are not required. Some of the devices are context-aware RESTful service (RS) providers and can also be RS consumers. All devices in both networks have embedded JmDNS servers. At least one device in both networks establishes a mobile P2P connection over the internet. The architecture of RS providers is illustrated in Figure 1 by the left block.

The framework utilises HTTP handler. The HTTP handler consists of a HTTP listener and cache. The HTTP listener listens for requests from consumers. These requests are then 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. The RESTful services forward the results of the services to the HTTP handler, which will respond to the consumers.

B. Efficient and lightweight service provisioning The framework utilises the REST architectural style.

Interchange messages are formatted in JSON and sent over HTTP. JSON ensures good compression of messages [12]. HTTP is used to reduce overhead, increase simplicity and reduce processing time. The framework utilises a REST handler, to abstract and simplify development of RESTful services.

C. Quality of Service (QoS) The RESTful architectural style increases scalability, by

caching HTTP requests. Interchange messages should be multicast to a number of devices, this improves availability. Messages are more likely to reach the appropriate recipient in a timely manner, increasing reliability. The use of HTTP and a decentralized approach increases scalability.

A context manager shown in Figure 1 is utilised by the framework. It takes the environment of the mobile device into account, in order to deliver better services or improve performance as discussed earlier. 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 GPS, disconnect from resource heavy networks, like Bluetooth to reduce energy consumption. Services can also be migrated to a public cloud if the load on the system is high.

D. Discovery The discovery mechanism in the framework is

decentralised. JmDNS is network dependent, whereas Mobile P2P networks are network independent [29], but uses XML JXTA advertisements [30]. Combining the two approaches may be the solution for a discovery mechanism that is network independent and efficient. JmDNS can be used to find and

advertise RESTful services within a single network. JmDNS is ideal for advertising service descriptions contained in the representation of the resource itself. Mobile P2P networks are ideal for cross network implementation. It can be used to create a network of JmDNS servers across multiple networks. 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 implementation of the prototype is discussed next.

VI. IMPLEMENTATION

A brief description of the prototype implementation of REST services for this research, and challenges faced is now described. New generation of commercial light-weight servers have been developed, to fit with the resource constraints of mobile devices, such PAW Server for Android [33] available on the Google Play [34] store. PAW server is used to deploy web pages stored on a mobile device itself. These web pages can be accessed by client software such as web browsers.

A RESTful service (RS) provider was developed for Android devices. The implementation included a PAW Server [33], which hosted PHP (Hypertext Preprocessor) [35] web pages. The PHP web pages exposed RESTful services. The PAW server is responsible for receiving HTTP requests and managing the connection between the clients and the provider. The PAW server also mapped the different REST services to URI’s. RESTful services exposed the available resources of the device.

A common challenge with the implementation is to provide good quality of service (QoS) to many clients, without performance reduction of other device features. It is necessary to reduce the load on resources to continuously provide RESTful services. The prototype overcomes the efficiency and QoS challenges by utilizing a context manager that toggles the GPS on or off, based on context. For example, if the battery level is less that 50%, the context manager would disable the GPS and use the device network location. The RESTful service can only acquire resources / context through the context manager.

The Android mobile operating system (OS) is used in this research because of its full Java integrated development environment (IDE). Android's development framework allows for a single application to be deployed on many different mobile devices. It is the world’s most popular mobile platform [15]. Interaction between clients and a RESTful service provider is illustrated next.

Figure 2: REST services provisioned on an Android device.

In Figure 2 the manager sends a request for a resource to an employee’s mobile device. Communication between the client and provider is over HTTP. It has different commands, namely GET, PUT, POST, and DELETE. The interchange messages can be formatted in different styles. PAW server is deployed on an Android mobile device. PAW server has a HTTP listener, which would listen to the requests of a tunnel the requests to a URI mapper. The URI mapper will then redirect the request to a RESTful service. The RESTful service processes the request, by making use of a JSON parser. The RESTful service then retrieves the resource. 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. Next, the requirements for RESTful services on Android devices are discussed.

VII. CONCLUSION

The contribution of this framework to current research is the Context Manager, which would increase the QoS for clients as well increase performance and reduce resource consumption of resources on the provider’s device. A new hybrid decentralised discovery mechanism has been 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. Future work can include performance analysis of the RESTful services implemented using the proposed framework in real world scenarios. 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] dotMobi (2013). Global mobile statistics 2013 Part A: Mobile

subscribers; handset market share; mobile operators. Available from: http://mobithinking.com/mobile-marketing-tools/latest-mobile-stats/a#subscribers (Accessed 19 March 2013).

[2] Paniagua, C. (2012). Discovery and Push Notification Mechanisms for mobile Cloud Services (Master Thesis). UNIVERSITY OF TARTU, FACULTY OF MATHEMATICS AND COMPUTER SCIENCE, Institute of Computer Science.

[3] World Wide Web Consortium (2004). Reconciling Web Services and REST Services. Available from: http://www.w3.org/2005/Talks/1115-hh-k-ecows/#%281%29 (Accessed 2012 March 28).

[4] Yahoo (2013). Yahoo. Available at: http://www.yahoo.com (Accessed 18 May 2013).

[5] Google (2013). Google. Available at: https://www.google.com (Accessed 18 May 2013).

[6] Facebook (2013). Facebook. Available at: https://www.facebook.com (Accessed 18 May 2013).

[7] Taherkordi, A., Eliassen, F., Romero, D. & Rouvoy, R. (2011). RESTful Service Development for Resource-Constrained Environments. In E. Wilde & C. Pautasso, eds. REST: From Research to Practice. New York: Springer. pp.221-36.

[8] Hamad, H., Saad, M. & Abed, R. (2010). Performance Evaluation of RESTful Web Services for Mobile Devices. International Arab Journal of e-Technology, 1(3), pp.72-78.

[9] Android (2013). Android. Available at: http://www.android.com/ (Accessed 08 May 2013).

[10] Fielding, R.T. (2000). Representational State Transfer (REST). In Architectural Styles and the Design of Network-based Software Architectures, Doctoral Dissertation. Irvine: University of California. pp.76 - 106.

[11] Zhao, H. & Doshi, P. (2009). Towards Automated RESTful Web Service Composition. In IEEE International Conference on Web Services, ICWS. Los Angeles, CA, 2009. IEEE Xplore.

[12] JSON (2013). Introducing JSON. Available at: http://www.json.org (Accessed August 20 2012).

[13] World Wide Web Consortium (2003). Extensible Markup Language (XML). Available at: http://www.w3.org/XML/ (Accessed 08 May 2013).

[14] Pautasso, C., Zimmermann, O. & Leymann, F. (2008). Restful web services vs. "big"' web services: making the right architectural decision. In 17th international conference on World Wide Web. New York, USA, 2008. ACM.

[15] Levkowetz, H. & Vaarala, S. (2003). Mobile IP Traversal of Network Address Translation (NAT) Devices. The Internet Society; Network Working Group Available from: http://www.ietf.org/rfc/rfc3519.txt (Accessed 18 May 2013).

[16] Guinard, D.S.R.&.I.f.P.C.E.Z.Z.S. et al. (2010). Interacting with the SOA-Based Internet of Things: Discovery, Query, Selection, and On-Demand Provisioning of Web Services. IEEE Transactions on Services Computing, 3(3), pp.223 - 235.

[17] Kim, Y. & Lee, K. (2007). A Light-weight Framework for Hosting Web Services on Mobile Devices. In Fifth European Conference on Web Services, 2007. ECOWS '07., 2007. IEEE Xplore.

[18] Nurseitov, N., Paulson, M. & Reynol, R. (2009). Comparison of JSON and XML Data Interchange Formats: A Case Study. In Computer Applications in Industry and Engineering (CAINE)., 2009. ISCA.

[19] Zeng, L. et al. (2004). QoS-Aware Middleware for Web Services Composition. IEEE TRANSACTIONS ON SOFTWARE ENG, 30(5), pp.311 - 327.

[20] Ran, S. (2003). A model for web services discovery with QoS. ACM SIGecom Exchanges, 4(1), pp.1-10.

[21] Microsoft Corporation (2010). What Is Scalability? Available from: http://msdn.microsoft.com/en-us/library/aa578023.aspx (Accessed 18 March 2012).

[22] Xue, Q. & Ganz, A. (2003). Ad hoc QoS on-demand routing (AQOR) in mobile ad hoc networks. Journal of Parallel and Distributed Computing, (63), pp.154-65.

[23] Dustdar, S., Platzer, C. & Krƒamer, B. (2008). DISCOVERY. Information Systems Institute - Technical University of Vienna, Austria; Department of Mathematics and Computer Science - FernUniversitƒat in Hagen, Germany Available from: http://www.infosys.tuwien.ac.at/Staff/sd/papers/Discovery.pdf (Accessed 02 March 2013).

[24] Berger, S., McFaddin, S., Narayanaswami, C. & Raghunath, M.T. (2003). Web services on mobile devices-implementation and experience. In Fifth IEEE Workshop on Mobile Computing Systems and Applications. IBM Thomas J. Watson Res. Center, Hawthorne, NY, USA, 2003. IEEE Explore.

[25] Bluetooth special interest group (2013). Bluetooth. Available at: https://www.bluetooth.org/ (Accessed 18 May 2013).

[26] Wi-Fi Alliance (2013). wi-fi.org. Available at:http://www.wi-fi.org/ (Accessed 18 May 2013).

[27] Srirama, S., Jarke, M. & Prinz, W. (2006). Mobile Web Service Provisioning. In AICT-ICIW '06. International Conference on Internet and Web Applications and Services/Advanced International Conference on, 2006. IEEE Explore.

[28] kSOAP (2013). kSOAP. Available at: http://ksoap2.sourceforge.net/ (Accessed 09 May 2013).

[29] Srirama, S., Jarke, M. & Prinz, W. (2010). Mobile web service discovery in peer to peer networks. Available from: http://arxiv.org/ftp/arxiv/papers/1007/1007.3631.pdf (Accessed 16 January 2013).

[30] Sun Microsystems (2010). JXTA - The Language and Platform Independent Protocol for P2P Networking. Available at: http://jxta.kenai.com/ (Accessed 25 April 2013).

[31] Zero Configuration Networking (2013). Zero Configuration Networking (Zeroconf). Available at: http://www.zeroconf.org/ (Accessed 19 May 2013).

[32] Minar, N. (2002). Distributed Systems Topologies: Part 2. O’Reilly Media, Inc. Available from: http://www.openp2p.com/pub/a/p2p/2002/01/08/p2p_topologies_pt2.html (Accessed 19 May 2013).

[33] PAW Server for Android (2012). PAW Server for Android. Available at: http://paw-android.fun2code.de/ (Accessed 08 May 2013).

[34] Google Play (2013). Google Play. Available at: https://play.google.com/store (Accessed 08 May 2013).

[35] PHP (2013). PHP. Available at: http://php.net/ (Accessed 18 May 2013).