Reliable Consumption of Web Services in a Mobile-Cloud Ecosystem Using REST Richard K. Lomotey and Ralph Deters

University of Saskatchewan Department of Computer Science

Saskatoon, SK, Canada richard.lomotey@usask.ca, deters@cs.usask.ca

Abstract—The evolution of the mobile landscape coupled with the ubiquitous nature of the Internet and the cloud is facilitating the deployment of enterprise and personalized mobile applications. In this research, we proposed a proxy-enabled unification framework that integrates heterogeneous devices with multiple SaaS and IaaS cloud layers in order to support personalized and group file sharing. However, our proposed mobile-cloud ecosystem calls for open research questions which must be answered such as i) how do we synchronize the data across the consumer devices and the multi-IaaS backend?, ii) how do we authenticate the system users?, and iii) how do we push updates in a low-latency fashion?

This paper addresses the three questions by proposing the adoption of the REST Web Service as an efficient way to consume the data on the mobile devices. However, we have to deal with the “CAP Theorem” which states that we can only achieve at most two properties at a time out of the following three: data consistency, system/data availability, and partition tolerance. Since partition tolerance is a given in a distributed system, we opt for the availability option by allowing file storage on the consumer devices in both online and offline modes. Further, we propose data consistency within a session that enforces update propagation in a soft-real time. The architecture is evaluated based on latency and scalability using multi consumer devices and employed Dropbox and Amazon S3 as the IaaS cloud providers.

Keywords- Web Services; Proxy; Cloud Computing; REST; SOAP; CAP Theorem; Web Services; Mobile Devices; ACID; BASE; OAuth 2.0

I. INTRODUCTION The strong growth in the use of smartphones and tablets

has led to a new paradigm for building software applications. Mobile devices have not only become part of us at homes and offices but also shaping how businesses and transactions can be carried out. The use of these devices is gaining widespread usage in Enterprise Information Systems which are commercialized and non-commercialized.

Moreover, these devices provide connectivity to web resources via multi wireless communication interfaces such as Wi-Fi, Bluetooth, 3.5G/4G, NFC, and so on. They also support data in multimedia formats which is good for information sharing. However, these devices are limited in terms of resource capacity (storage and processing) and their mode of communication is over a constraint wireless bandwidth which leads to sporadic disconnection. With the

recent explosion of the cloud computing technology and facilities, it is becoming very clear that the mobile is gradually becoming the de facto client platform to consume the pool of data and information. Also, most of these cloud oriented services and data are deployed as Web Services which are network oriented applications [1]. Hence, to enhance the user experience, the aforementioned challenges of resources limitation and unstable wireless connection has been the focus of most studies.

However, there is even a bigger challenge that has been overlooked recently by researchers within the distributed mobile network which is the “CAP Theorem” [2-3], [34] phenomenon. In a highly distributed system where web services are scattered across multiple platforms, three system guarantees that are required are the: Consistency of the data, Availability of the system/data, and Partition tolerance to fault. However, the CAP theorem states that at most only two of the three can be guaranteed simultaneously. In distributed mobile systems where the mobile node is employed as the consumer platform of the web services, partition tolerance is a given due to the intermittent connectivity losses which means we are faced to choose between Availability and Consistency. This paper’s priority is to enforce high system and data availability based on our use case but that also means we have to design a data update model in order to achieve eventual consistency in a soft-real time.

In this paper, we keep these challenges in mind while proposing a mobile cloud computing framework called ALILI that supports file sharing among a group of users. The architecture aimed at ensuring data synchronization across the multi consumer devices of a user as well the multi-cloud platforms. Further, we put forward the adoption of OAuth 2.0 mechanism from social media cloud to facilitate the authentication process of the users. The design also employs the lightweight REST API from all the cloud providers in order to enforce efficient data access on the consumer devices. Finally, all the architectural components are linked together by a proxy layer which facilitates the aggregation and requests routing from the consumer devices.

The remaining sections of the paper are structured as follows. Section II describes the CAP Theorem and Section III explores the works that has been done within the mobile Web services domain. Section IV discusses the problems we are addressing and Section V proposes our use case architecture to solving the challenges. Section VI explains our data update management methodology and Section VII presents the implementation details and the evaluation of the

2013 IEEE Seventh International Symposium on Service-Oriented System Engineering

978-0-7695-4944-6/12 $26.00 © 2012 IEEE

DOI 10.1109/SOSE.2013.10

13

referenced implementation. The paper concludes in Section VIII with our contribution and future outlook.

II. THE CAP THEOREM Web services running in scalable systems are expected to

provide the following support: Consistency of the data/service, Availability of the system/data, and Partition-tolerance. However, Eric Brewer [2] in an invited talk in 2000, made a conjecture which states that no distributed system can guarantee all three requirements at the same time. Brewer again noted that two of the three requirements can be guaranteed simultaneously if one requirement can be traded-off [2-3]. This idea is conceptualized below in Fig. 1.

Figure 1. The possible options in the CAP theorem

Gilbert et al. [3] used a formal module based on read/write operations on dis-jointed nodes to prove Brewer’s conjecture into a theorem. The formalism shows that for every associative write, it is impractical to read the same data if the write has to be available on all the dis-jointed nodes at the same time. Simply put, when a data is updated on a particular node in a distributed environment, the update can be seen by all requesters if and only if we lock the system from showing the old state of the data.

Consistency is the requirement which guarantees that states stored in a distributed system are seen the same at every node by clients [6]. Gilbert et al. described consistency as “atomic” which means every system transaction is one and must be completed fully or not started at all. To ensure a consistent system, some developers and researchers have adopted the ACID (Atomicity, Consistency, Isolation, and Durability) technique [7] especially within the context of databases. Atomicity: Considering an operation in a distributed system, if a part fails then the entire transaction fails and the system must be rolled back to its original state. This means that each transaction is single and cannot be broken into parts. Consistency: This property ensures that anytime a request is issued to the database, the requester receives a valid and desirable data. According to Dan [7], “the database will be in a consistent state when the transaction begins and ends.” Isolation: A distributed system should be built in a way that transactions being processed should be hidden from other processes until it comes to completion [7]. Durability: After a successful transaction, the operation cannot be rolled back even if there are system failures [7].

Transactions even though atomic require a lot of sequence of operations. Distributed systems normally rely on two-phase commit (2PC) protocol, three-phase (3PC) commit protocol, and timestamps to provide the ACID capabilities. Dan [7] explains two-phase commit (2PC) as

follows - if all databases agree on an operation (i.e., precommit) to the coordinator, then the operation can continue with the coordinator in the second phase asking the operations to commit but if one reports failure, the entire system must be rolled back. Since most systems are horizontally scaled, it means partition-tolerance is ensured which means systems cannot be available according to the CAP theorem. Also, because of the use of database keys, distributed transactions are highly coupled [7]. It is also challenging to build long-lived transactions in ACID since there is locking and serialization. Instead some developers propose SAGAS [8] where long running transactions can be broken into smaller transactions but interlinked. Further, the challenge with ensuring consistency is the high cost of bandwidth consumption due to the communication overhead since all the participating nodes have to commit to an atomic transaction [9]. Again, since mobile devices are not guaranteed reliable connectivity, it is impractical and almost impossible to ensure locking especially when a mobile participant is not available to commit at a beginning of a transaction.

Availability ensures that when parts of the nodes in a distributed system become inaccessible as a result of failures, the other nodes should continue to operate and support every read and write operation [6], [9]. It is important that intended responses are received for each request [7]. Gilbert et al. [3] report that systems tend to fail during peak performance, therefore making availability very difficult to achieve when it is needed most [3]. Availability can be achieved if consistency is compromised when the BASE (Basically Available Soft-state Eventual-consistency) [7] technique is adopted. BASE is applied to minimize the level of coupling in ACID systems. Decoupling transactions is achieved by introducing persistent message queues. This process ignores two-phase commit and ensures latency. Further, eventual consistency is achieved if the system allows for a time lag between operations. According to Vogels [10], considering Nh hosts that store replicas, Nw successful writes to a replica, and Nr replicas that can be read from hosts, then Nh >= Nw + Nr ensures eventual consistency and partition tolerance within a distributed system. This means that outdated replicas can be seen on some hosts when a read operation is invoked. There are different types of eventual consistency models such as Causal consistency: This model assumes that if a replica is updated by a process X and duly notifies process Y about the update, then all read operations of Y should return the updated replica [10]. The difficulty in the implementation of this weak consistency model is how to identify which processes have causal relationships [11]. Read-your-writes consistency: This is a special case of causal consistency where after process X has updated a replica, durability is ensured where by the older version of the replica cannot be read again but only the updated version [10]. From the parameters used above to explain Vogel’s concept of replicas, if Nr + Nw > Nh, then read-your-writes consistency is guaranteed [12]. This consistency model directs read requests to only hosts that have updated replicas and all requests to hosts that are yet to update their replicas are not served [13]. Session consistency: Read-your-writes

14

consistency is implemented to work only within a context of a session [10]. This is very practical because every session is guaranteed read-your-write consistency but when a session fails, a new session has to be started with no guarantee of consistency from the previous session [10]. The reality is modern consumer cloud providers such as Dropbox and iCloud (explained later in the paper) all rely on the session consistency methodology.

Partition-tolerance is achieved when a distributed system is built to “allow arbitrarily loss of messages sent from one node to another” [3]. The current demand from web service consumers makes it impractical to keep all data at one source. This is because when the source fails, it means the entire system becomes unavailable. Partition-tolerance therefore allows for system states to be kept in different locations. This property is a given in a mobile distributed environment since mobility and offline access to data can only be achieved through partitioning.

Browne [14] noted that the CAP theorem is most applicable in scalable systems as transactional load increases. The best pair of guarantees normally preferred by users is Availability and Partition-tolerance while trading-off consistency because it is better to give some data rather than access denied in most workflows [14].

Though the CAP Theorem has been described in many studies in relation to databases, the phenomenon is present in Web Services and follows the same analysis. In the next section, we discuss the Web Services design paradigms.

III. WEB SERVICES

A. SOAP Almost all of today’s network based applications such as

email, notification services, online file and document sharing, social media, and so on are modeled as web services with standards such as SOAP, WSDL, UDDI, XSD, and REST to ensure data availability and access at real time [4], [5], [15]. Simple Object Access Protocol (SOAP) is explained by Pautasso et al. [4] as a Web specification that provides interoperability for heterogeneous Web services. This is achievable because SOAP messages can be exchanged over multiple communication protocols using HTTP and other transport protocols. Also, the use of HTTP for transporting SOAP messages has reduced the challenge for building services that can run on the Internet according to Cartwright [16]. Though the standard protocol used by SOAP is HTTP, it can use other protocols as well. Han et al. [17] argue that the advantages of SOAP are protocol transparency and independence.

However there have been some challenges associated with SOAP in modern architectural designs of web services. While some perceived it as a complex way of design, others saw that the simple way of turning legacy applications into web services can be misused [4], [18]. Further, SOAP uses the POST method for all operations and this leads to caching challenges especially when the protocol becomes too heavy in a wireless network. As a way to improve on bandwidth utilization and the use of clear semantics for system operations, some studies have proposed the REST design.

B. REST 1) The REST Architecture

REpresentational State Transfer (REST) is another alternative to SOAP [4]. Roy Fielding [19] who is identified with the formulation of the uniform resource identifier (URI) generic syntax coined the term REST as an architectural principles that use the Web as a platform for distributed computing [4]. The REST design has certain architectural principles.

Everything is a resource: All the identifiable entities must be considered as a resource and should be assigned an ID [1].

Identification of resources through URI: The entities should be given a URI to aid interactions within the system and allow resources to be searched for globally [1], [4].

Uniform interface: Resources can be manipulated through representations using HTTP verbs such as GET—to fetch a resource, HEAD — to read the metadata of the resource, POST— to push or create a new resource, PUT— to change (update) the state of a resource and DELETE— removes the specified resource while OPTIONS— checks the functionality of a web server [20]. There are other methods as well such as TRACE, CONNECT, and PATCH.

Stateless interactions: While resources are stateful, their interactions should be kept stateless. At the end of every transaction, resources should have information about themselves but not how the last interaction was done. This is the reason REST architectural design achieves high scalability [21].

Hypermedia as the engine of application state: In order to navigate between resources, URIs such as hypertext can be used in resource representation [1].

2) RESTful Web Services RESTful web services are web enabled services built on

the architectural principles of REST over HTTP. RESTful web services provide more desirable architecture that makes mobile clients to communicate to the server through proxies [1].

Figure 2. Levels of design in REST [22]

The stateless interaction eases the impact of network volatility [1]. Further, because of URIs, apps can easily be invoked from mobile clients with less risk of network overloading [1]. In “Richardson Maturity Model: steps toward the glory of REST” [22], four levels of abstraction is noted as reproduced graphically in Fig. 2. Level 0 describes the use of Plain Old XML (POX) to create simple request

15

response interaction over HTTP. Level 1 focuses on building resources that can be interacted with individually in a 1 to many relationship which helps in overcoming the traditional way of interacting with a single service endpoint. Level 2 is the use of all the HTTP verbs beyond POST and GET for most of the interactions; thereby supporting the full CRUD (Create, Read, Update, Delete) operations. Level 3 is the use of hypermedia controls for making protocols more discoverable. The works of Lee et al. [23] and Selonen et al. [24] in building low-rest and lightweight REST respectively fall within Level 0 and Level 1 in the Richardson maturity model.

Selonen et al. [24] in their work in building mixed reality service employ REST as an architectural style in order to achieve interoperability, decoupling, scalability and security. These are the key functions of modern heterogeneous web services. The authors proposed a service model which is later changed to resource model using UML class diagrams and the final implementation was done as a lightweight method of REST. They employed Java EE-Hibernate- Restlet which aided them to use uniform interface and define resource states. However as a limitation, Selonen et al. also report that sometimes building RESTful web services can be difficult since some publicly available API’s which seems to be RESTfully built are not.

In building an “Adaptive and Multi-device Application Sharing” service that preserves the same look and feel of applications deployed on different mobile platforms, Stirbu [25] report the use of event-based RESTful approach. Since resources contain self-descriptive messages, interactions between them are converted to events which are controlled remotely to deliver content with the same functionality on different systems. This work was done to overcome the well-known challenge of REST which is the client being the one that mostly initiates the conversation to the server.

According to [26], combining RESTful design with other technologies like caching provides great system scalability. Further, synchronization between client and application host is achieved since they can both initiate conversation in a request response pattern. Stirbu [25] observed that using REST makes their system to scale with multiple users and devices but also complained about some limitations imposed on the system at the network level which has to do with response request.

Han et al. [17] on the limitations of REST argue that many firewalls permit only the GET and POST methods. There is also a size limit on the URI for the GET method encoding; and HTTPS is not cacheable.

C. Mobile Cloud Computing and Services One of the primary ways of consuming cloud hosted data

is through Web services interfaces. Today, Software-as-a Service (SaaS) facilities (e.g., social media) provide Graph APIs which can be invoked as Web Services for consuming data; Infrastructure-as-a-Service (IaaS) providers such as Amazon Web Services and Dropbox are offering REST and SOAP APIs for consuming cloud hosted data in personalized or enterprise oriented applications; and Google App Engine and Microsoft Azure which are Platform-as-a-Service

(PaaS) are offering their development environment primarily as Web Services [27]. The important thing is most of the cloud providers offer both the SOAP and REST APIs; which means the choice is for the consumer (developer) to make.

Christensen [1] in his work explored the network capabilities of smartphones by linking context-enable features to cloud computing. Smartphones unlike desktop computers are constrained with storage space and memory allocations therefore exploring the power of cloud computing can help with some computational features being stored in the cloud. Since mobile phones now have connections either through Wi-Fi or Bluetooth, data in the cloud can be accessed readily. Christensen [1] reported the convenience of building web services RESTful for smartphones since REST requires passing simple XML or JSON. Christensen [1] also reports on how the combination of smartphone, REST based cloud computing and context enablement transformed the mobile application paradigm to activity based service.

Now that we have re-visited the past and report the basics of the CAP theorem and the Web Services design paradigms plus the cloud technology wave, the question is what next for the mobile, cloud, and web services space? To answer this question, we present the focus of this paper in the next section.

IV. THE FOCUS OF OUR WORK AND A USE CASE It is very clear that the future promises consumer driven

mobile cloud architecture with high demand for the consumption of cloud resources on mobile devices [28]. It is very common nowadays to see consumers with more than one device. As a result, some of the consumer cloud providers such as Apple have introduced the iCloud1 service which aids users to synchronize their data across multiple devices. The challenge with the iCloud service however is currently, the users are compelled to use iOS supported devices which makes it difficult to use the same service from other mobile vendors. Also, the service API is not given to the external developers therefore, it is a challenge to integrate the iCloud service into any other consumer cloud.

Further, there are other consumer driven cloud services such as Dropbox2 that offer file sharing services on multiple platforms. Currently, Dropbox has mobile Application Programming Interfaces (APIs) which facilitate applications development for file sharing across platforms (i.e., the PC and mobile devices). Again, the Dropbox mobile APIs support a limited number of mobile platforms such as the BlackBerry, iPad, iPhone, Android, and Kindle Fire.

Also, the Amazon cloud services such as the Amazon Simple Storage Service (Amazon S3)3 facility is becoming a very popular platform for file and document storage. The service offers APIs and SDKs that can be employed to build applications that support reliable access to data.

Our aim is to build a framework called ALILI that emulates the iCloud service but offers flexibility to the consumer to use multiple devices as well as multiple IaaS

1 https://www.icloud.com/

2 https://www.dropbox.com/ 3 http://aws.amazon.com/s3/

16

cloud stores. We are considering multi cloud platforms specifically, Dropbox and Amazon S3 as the cloud back-ends. As a use case, we are building the ALILI framework for the Graduate Students in Computer Science at the Multi-Agent Distributed Mobile and Ubiquitous Computing (MADMUC) Lab at the University of Saskatchewan to share their data on multi screens for seamless access. To be able to deploy the ALILI framework, there are some key research questions that we seek to address which are:

1. How do we manage the synchronization of the data (which are Web services/resources) between the consumer devices (mobile and PC) and the cloud providers (Dropbox and Amazon S3)?

2. How do we authenticate the users of the system and determine what their data are?

3. How do we minimize the bandwidth consumption in the wireless environment and its implications on energy consumption?

4. How do we ensure that updates are enforced in a low-latency fashion?

To answer the aforementioned questions, we adapt the concepts from the CAP theorem phenomenon, mobile cloud computing, and the Level 2 supported REST to model the data as Web resources. In the next section, we discuss the detail architectural design of the ALILI framework.

V. THE ARCHITECTURE OF THE ALILI FRAMEWORK The ALILI framework is a 4-tier architectural design as

illustrated in Fig. 3 with multiple sub-layers. The architecture consists of the consumer devices, an IaaS cloud-hosted proxy layer, SaaS-oriented cloud layer and the IaaS cloud providers. The upcoming discussions address each of the layers and their sub-layers.

A. The Heterogeneous Consumer Devices In order to move away from the “closed garden” app

deployment (such as iCloud), we decided to open the ALILI framework to all modern smartphone and tablet platforms including the PC. Our approach requires studies on data consumption formats that can enforce platform independent app development; the reason we adopt the REST Web services mechanism. In today’s heterogeneous networks that consist of Wi-Fi, 3G or 4G networks, most of the consumer devices in client-server and events-driven systems are smartphones and tablets, running native apps or mobile Web apps [29].

Mobile Web apps provide the platform for a single code based to be deployed on variant mobile platforms. The advancement in HTML5 makes the Web app design approach deliver similar and more improved user experience as native (resident) apps [29]. The mobile browser pattern has become the de facto standard for mobile applications since the Web is everywhere. One key benefit of adopting the mobile web methodology is the use of the latest HTML5 oriented web technology frameworks. Web frameworks such as PhoneGap [30], Sencha Touch [31], and jQuerymobile [32] support diverse mobile operating systems and allow mobile web developers to leverage their web technology

skills in creating appealing applications. Moreover, these frameworks facilitate dynamic access capabilities to the device native features [29].

However, there are challenges when the mobile Web app approach is employed. Due to browser diversity, the applications deployed tend to have different look and feel. Further, some JavaScript functionalities failed to work on certain platforms; for example, the alert() function in JavaScript works on the BlackBerry platform but not on the Android platform during the implementation of our framework.

Hence, our first task is to build the mobile side of the application in a way to overcome the issues of browser diversity. To address this issue, we build the client side application as a Platform Independent Model that has the specific features of each of our client devices. So, depending on the platform on which the application is deployed, the application uses the features of that platform to render the same look and feel. Currently, the app supports the BlackBerry Playbook, Android powered tablets, iPad, iPhone, Windows 7 Phone, and the PC. Further, the mobile side application consists of jQuerymobile, JavaScript, and CSS.

B. The Public IaaS Consumer Cloud Though the ALILI framework is a hybrid 4 cloud

architecture, each component is serving a distinctive purpose. First, we focus on the Infrastructure as a Service (IaaS) oriented cloud services which specific to this paper are the Amazon S3 and Dropbox facilities. The facilities are employed primarily as repositories where documents in different formats are stored. The motivation for using the two facilities is necessitated by our use case:

We expect that the graduate students have their own Dropbox account and service to keep their personalized data. On the other hand, we keep a pool of shared materials on the Amazon S3 which can be accessed by the members of the lab. The assumption is that, materials which are on the S3 facility can be seen by all including the tracking of changes to the various data. It is impractical to allow the graduate students to keep the shared data which comprises of huge application codes in their Dropbox account since most of them subscribed only for the 2GB free space. However, there is lab funding to pay for more space on the S3 facility to facilitate data sharing.

Equally, we expect that grad students who want to share resources from their private Dropbox account can do so by just sending the data to the Amazon S3 facility by a click of a button on the consumer device. However, the main issue to discuss is the identical security workflow of the two cloud providers. When Amazon S3 account is created, the customer is given an Access Key Id and a Secret Access Key. Based on these two keys, the customer has to generate/create a Hash Message Authentication Code (HMAC) signature which is SHA-1 Base 64 encoded.

4 Hybrid cloud architecture consists of public clouds and a private

cloud in a single unified architecture.

17

Iden

tific

atio

n

HTTP

Retr

ieve

Acc

ess

Toke

n

REST

API

Figure 3. The generic ALILI framework from a single user perspective

When a customer wants to access a resource on the Amazon S3 facility, s/he has to add to the HTTP request headers the access key id and the HMAC signature (but not the secret key id). The Amazon Security Gateway will retrieve the access key and decode the signature to determine the credibility and the eligibility of the requester. If the authentication test is passed, the Amazon S3 facility will allow the request and issue a response back to the customer otherwise, the request is denied. It is interesting to note that, the Dropbox facility also follows the same authentication workflow as the Amazon S3. However, we are now faced with the bigger security challenge which has to do with the issuance of the key. The question is:

How do we authorize multiple grad students to access a data from a common source (Amazon S3) on their devices without giving every user the security keys?

The importance of the above question is the avoidance of storing the security keys within a client application domain and denying the user any knowledge of what the keys are. Also, in case the mobile device gets into the wrong hands, the data cannot be accessed if the security keys are not stored within the mobile application domain. The above question further exposes the security loop hole in the Dropbox mobile version which the company has rolled out recently.

The answer to this question is one of our motivations to propose a proxy platform and allow third party security integration from the consumer devices. In the next section we discuss the details of the SaaS cloud layer which offers OAuth 2.0 security from social media services; specifically, Facebook and Google+.

C. The SaaS Cloud Layer The Software as a Service (SaaS) cloud layer is

employed primarily to enforce the client side authentication and allow the use of trusted social relationship among the users. The SaaS layer also enabled us to decouple the authentication of the users from the entire system.

The question has always been asked whether consumers can use their social networking accounts such as Facebook, and Google+ through third party applications to access data hosted on cloud platforms such as Dropbox and Amazon S3. From the perspective of some enterprises such as marketing and advertising agencies, the social networking approach is a huge boost to getting consumer participation. As well, it reduces the cognitive workload of the consumer if s/he can only use a Facebook login in one call to access data that is spread across multiple cloud platforms.

In this research, to authenticate the users of the system from the consumer device, the proxy employs the OAuth 2.0 technique with social networking sites such as Facebook and Google+. The OAuth 2.0 technique ensures the authentication of the user from an external social media cloud and allows the proxy to retrieve the user’s social media credentials such as security access tokens. The access tokens also permits the proxy to retrieve the basic information of the user including the id and name. But more importantly, the access tokens allow the proxy to retrieve the friend lists of the user and this makes it easier for us to map the grad students’ files in a shared pool with their colleagues that they want to share certain documents with.

Also, the deployment of the OAuth 2.0 authentication mechanism aided our work to hide the security keys of the IaaS cloud providers from the mobile application domain; but rather allowed us to enforce a decentralized controlled access to the backend from our proxy. Next, we discuss the functionalities of the proxy and provide further clarifications on the OAuth 2.0.

D. The Private Cloud Hosted Proxy The proxy which is an application server can be hosted

on any IaaS compute cloud layer be it a public cloud (e.g., Amazon EC2) or a private cloud but this paper puts forward the latter platform since we wanted to have more control over the security. The proxy is the hub that links all the actors (i.e., the consumer devices, the SaaS cloud, and the IaaS cloud services) in the ALILI framework. In Fig. 4, the

18

anatomy of the proxy framework is illustrated with the three HTTP/S interfaces that are exposed to the actors which are external services. The numbers show the order of activity flow. Next, we discuss the flow execution of the proxy and where necessary, we show code snippets to clarify the behavior of some of the core system components.

HTT

PS In

terf

ace

HTT

P In

terf

ace

CRU

D

Figure 4. The anatomy of the proxy server (showing three HTTP interfaces that are exposed to external services).

First of all, when users launch the ALILI App on the device, the client side HTTP interface is called (as shown in step 1) which is primarily the Universal Resource Identifier (URI) of the proxy. The URI call which is treated as a request is immediately intercepted by the Service Coordinator which is the component that is responsible for the coordination of all the system flow activities. The Service Coordinator routes the request call through the social media HTTP interface in step 2 to the OAuth 2.0 Engine which is an external authentication system. Specific to this paper, we are using the OAuth 2.0 from Facebook and Google+. In the C# code snippet in Fig. 5, we present the authentication flow for the Facebook Graph API to further explain the OAuth 2.0 concept. The request from the HTTP interface in step 2 to the Facebook endpoint (https://graph.facebook.com/ oauth/access_token?) is shown as: var facebookUrl = _fb.GetLoginUrl( new { client_id = "385826384253563"; client_secret = "52a5f9574ca5c9f555950e56c233f277", redirect_uri = "http://madmuc.alili.ca/Account/FacebookCallback", response_type = "code", scope = "user_about_me,publish_stream,manage_pages", state = state });

Figure 5. Request to Facebook using OAuth 2.0

The request is sent to the Facebook endpoint with the above supplied information where client_id and client_secret are values assign to us when the ALILI app is registered on Facebook, redirect_uri is the site to which the user should be directed to after the successful authentication process (which in our case is the home screen page as shown in Fig. 7, response_type is a code for the utilization of the proxy server after the authentication process, scope is the data that the proxy is requesting for, and state is a unique value which is

assigned to applications to prevent cross-site request forgery (CSRF) [33].

Typically, when the request is issued to the Facebook OAuth 2.0 system, Facebook provides a login interface that requires the user to input the username and password; this process is captured in step 3 in Fig. 4. After the successful authentication with Facebook, a response in JSON format is returned to the proxy through the HTTP interface in step 2. A sample response captured from Facebook for a user called Richard Lomotey in our system is shown below in Fig. 6. { "id":"585332871", "first_name":"Richard", "last_name":"Lomotey", "link":"http://www.facebook.com/rlomotey", "username":"rlomotey", "gender":"male", "verified":true, } { "access_token":"AAAFe6DRpWQ0BAJs1vKlDHLp3VV0Xr8reds" }

Figure 6. Response from Facebook

The data from Facebook is actually more but we present a simplified outlook of what data we are interested in retrieving. The Google+ OAuth 2.0 mechanism is similar except for a difference in the end points. For further details on OAuth 2.0 and automatic error handling, the reader is referred to [33]. What is more important for us is the access_token which is unique for every user. Hence, when the above response is sent from the OAuth 2.0 Engine, the service coordinator sends the response to the User Account Service Marshup in step 4. The security marshup service has a key/value pair repository that stores the responses from the OAuth 2.0 Engine using the access_token as the key. Since the ALILI framework supports both Facebook and Google+ logins, the access tokens of the same user are mapped in the repository using a hash map. So, the system is able to determine the same user even if the user has multiple accounts.

Moreover, the entire decentralized authentication system enforces multi-level security throughout the framework. Firstly, the user and the consumer application domain are shielded from the Dropbox and Amazon S3 sources and rather, the user is authorized through a third party (SaaS) security layer using the OAuth 2.0. Secondly, the SaaS security service is also shielded from acquiring any knowledge of the existence of the cloud storages because the information gathered from the SaaS layer is just stored in a repository; and the decision to use the stored data to do the actual authentication to the IaaS cloud storages is handled by a different component on the proxy.

The ALILI application is designed to work in two modes; offline and online modes. Assuming the authentication procedure fails in either steps 1, 2, 3, or 4, the application will switch to the offline mode where the users are able to access their documents and modify them locally on their devices but they will not be able to update their files with any of the cloud storage. Further, the users are not permitted

19

to access shared documents which are sent to the S3 service by other colleagues in the offline mode. The users cannot also synchronize their personalized Dropbox files if the application is in the offline mode.

However, the successful authentication process flow automatically switches the application to the online mode. In that case, all the limitations present in the offline mode are overcome and the users can do “live synching,” meaning they can be receiving updates from the cloud storages as well as pushing updates to the backend from the consumer devices in real time. At this point, it is important that we discuss the remaining components of the proxy which are actually functionalities that are activated after the successful authentication process.

When a user is successful with the OAuth 2.0 security authentication, the application interface as shown in Fig. 7 becomes accessible in the online mode which means the users can perform the CRUD (Create, Read, Update, Delete) operations within the system. Currently, we summarized these four operations in two verbs in order to support the REST APIs from Dropbox and Amazon S3. Hence, the system uses the HTTP POST method to either store a new file or update an existing file. We employ the HTTP GET method to fetch the files from the IaaS cloud sources to the consumer device storage. When a file is deleted (removed) from the system, we equally treat it as a write operation so we use the POST method to ensure that the file is deleted from the either end.

Furthermore, when an online user issues an HTTP request, the Service Coordinator redirects the request to the Request Router component in step 5. The Request Router determines the nature of the request based on which CRUD operation is to be performed by extracting the HTTP verb from the HTTP request header. The Request Router also determines which IaaS cloud storage the request is meant for; whether Dropbox or Amazon S3. The Request Router then forwards the request plus the security credentials of the user from the User Account Service Marshup repository to the HTTPS interface in step 6. The HTTPS interface pushes the request using the REST API of the intended cloud storage and waits for the response from the cloud storage. All incoming requests from the proxy have to pass through the security gateway of the cloud storage systems as shown earlier in Fig. 3. When the cloud storage responds to a request, the response is sent across the HTTPS interface back to the Request Router which determines the intended user that the response is meant for. The identification and matching of a response to a particular requester is crucial in the system since we are dealing with concurrent users. When a response is successfully matched to the appropriate requester, the Request Router then pushes the response to the requester’s device. Next, we discuss the approach this paper adopts to keep data up to date across the user’s devices.

VI. DATA UPDATE MANAGEMENT Clearly, the transaction of the ALILI framework falls

within the CAP theorem as discussed in Section II. There are chances of not having connectivity to the IaaS cloud services and the fact that the user’s data are stored on distributed

layers (i.e., Dropbox, Amazon S3 and n-consumer devices) means that partition tolerance is inherent in the architecture. This means the system can only achieve consistency of data within the system or ensure high availability as the complementary guarantee. Conventionally, the Dropbox service opts for the availability option which means, the system allows for some time lag within which the data is synchronized across the multiple platforms. This also means that there are times when users view outdated data in their Dropbox account especially when the synchronization process is not complete. Moreover, the Dropbox service enforces session consistency (explained in Section II). In view of this, the ALILI framework is aligned to offer the availability guarantee and compromise on data consistency. We can equally guarantee consistency by compromising on availability. To do this, we just have to introduce locks on the proxy (following the ACID approach in Section II) which ensures that the moment a user is authenticated, every transaction of that user has to be complete before any other transaction can be initialized by the same user. However, from the lessons learned in our reviewed literature and our target group, the consistency guarantee is less preferred. Naturally, users want to have access to data and keep working and later synchronize it if the need be.

So, we guarantee the availability of the system by providing the offline mode as mentioned earlier in the previous section. The question now is how do we ensure soft real time data synchronization? The answer to this question leads to the discussion of the last component of the proxy which is the Workflow Engine.

The Workflow Engine in step 7 in Fig. 4 is initialized when the user completes the authentication process through the OAuth 2.0 Engine. The role of the workflow engine is to issue asynchronous HTTP HEAD request to the two cloud providers concurrently. The reason we issue the requests concurrently is to minimize the waiting queue if the sequential request technique is adopted. Also, we issue the HEAD request in this case because the header information is lighter which is good for the bandwidth utilization. The workflow engine issues the request to retrieve only the Etag5 value of the stored data. This value is compared with all the stored data of the user on the n-consumer devices and mismatch Etag pairs call for synchronization of the data from either end.

Further, when the user is in the offline mode, the Workflow Engine still polls updates from the cloud sources and puts the updates in notification mode. So, as soon as a user switches to the online mode, the workflow engine informs the Service Coordinator which also directs the Resource Router to issue the requests for the updated files. The proposed workflow engine aids the proxy to push the updated resource (data) states to the consumer devices faster.

VII. IMPLEMENTATION AND EVALUATION Currently, there is no Software Development Kit (SDK)

that combines APIs from multiple IaaS cloud providers;

5 Etag is a string attribute of a Web resource that changes whenever the resource is modified.

20

largely due to business product differentiation issues. However, the Dropbox and Amazon S3 facilities have REST APIs that developers can use to interact with their services. So, we built our own C# .Net library for the ALILI framework which combines the APIs from Dropbox, Amazon S3, Facebook, and Google+.

From the architectural design, it is evident that our best development approach is to adopt the Model-View-Controller (MVC) design. The MVC approach is ideal in our case to decouple the activities on the consumer device from the proxy and the SaaS security layer. Using the Microsoft ASP .Net MVC3 tool in the Visual Studio 2012 development environment, we built the library for the ALILI framework to interface with the SaaS and IaaS layers when configured.

The MVC3 tool provides an HTML5 interface that runs on the C# application server so basically, the View component of our architecture is what we deploy on the consumer device. The View provides the GUI interface that the users can employ to interact with the system. Also, we added jQuerymobile framework to enforce device independent look and feel. The interface of the ALILI framework is shown below in Fig. 7.

Figure 7. The Homepage of the ALILI App on Galaxy Nexus

The Controller component is responsible for all the activities of the proxy server as outlined in the architectural design. The Controller components are the request handlers from the View, the SaaS APIs, and the IaaS APIs.

The Model components are responsible for the execution of the actual application logics and storage. Hence, when any of the controller components receives a request, the corresponding model is called to execute the request and send the processed feedback to the controller.

The entire code set of the ALILI framework including the documentation on its configuration will be made available as an open source project to the research community at https://github.com/MADMUC/.

In order to evaluate the ALILI framework, we put forward some state-of-art consumer devices that support the HTML5 embedded browser. These newly purchased devices are owned by each grad students in the MADMUC Lab for research purposes and the devices have the following specifications: BlackBerry PlayBook — OS: BB Tablet OS, Resolution: 1024x600, Processor: 1GHz, Number of Cores:

Dual-Core, Storage: 16GB, RAM: 1GB, iPad 3 — OS: Apple iOS 5.1.0, Resolution: 2048x1536, Processor: A5X (dual-core, w/ quad-core graphics), Storage: 16GB, RAM: 1GB, NOKIA Lumia 900 — OS: Windows Phone OS, Resolution: 800x480, Processor: 1.4GHz, Number of Cores: Single-Core, Storage: 16GB, RAM: 512MB, Transformer Prime TF201 — OS: Android 4.0, Resolution: 1280x800, Processor: NVIDIA Tegra3, Number of Cores: Quad-core, Storage: 32GB, RAM: 1GB, Personal Computer (PC) — OS: Windows 7 System 32-bit, Processor: Intel Core i5, CPU 650 @ 3.20GHz 3.19GHz, Storage: 500GB, RAM: 4GB (2.99GB usable). The middleware is hosted on the Amazon EC2 instance with the following specifications: OS: Windows System 32-bit OS, Processor: Intel Xeon, CPU E5410 @ 2.33GHz, 2.41GHz, RAM: 1.70GB. The available Wi-Fi is 75Mbps Ethernet for the mobile testing.

A. Latency Test The first evaluation conducted in this research is latency

analysis in order to understand the time taken to receive updates on the consumer devices. We allow for a storage space of 3GB of data on the consumer devices which is shared approximately as 1.5GB on Dropbox and 1.5GB on Amazon S3 for simplicity of evaluation. The Amazon S3 actually has more data (approximately 50GB) which contains our lab project code sets and documentations. The individual files which are of varying formats (i.e., *.doc, *.ppt, *.pdf, *.mp4, and so on) are approximately 1.5MB. We analyzed the time taken for a data that is stored on the Dropbox to become visible to a connected consumer device and measured similar time for the Amazon S3; and technically, the maximum time of completion for both scenarios is considered as the actual latency 6 time for the ALILI framework. Mathematically, the max(TDRP, TS3), is the update time of the ALILI framework where TDRP is the update completion time for Dropbox on the consumer device and TS3 is the update completion time on the consumer devices from the Amazon S3 facility. The time is measured for increasing number of files from 150MB to 1.5GB. The file sizes shown are not for single files but rather multiple documents. The experiment is repeated five times per device and the average times for both IaaS cloud sources are plotted in Fig. 8a-8e. We also present the overall outlook of the update for the ALILI framework per device in Fig. 8f for ease of reading.

The overall evaluation shows an improved delivery time from the Amazon S3 in comparison to the Dropbox service which means, the benchmark for the measurement of update time for the ALILI framework is the Dropbox delivery time since that accounts for the maximum time. Throughout the experiment, it is observed that increasing file size has a linear relationship with the file upload time; contrary to our expectation that the two parameters will have an exponential relation.

6 Latency in our case is the time frame within which the updates are pushed to a connected consumer device. It could be a round-trip time but in this test, we are only interested in the time of update from the backend to the consumer device.

21

Update time on the (a) BlackBerry Playbook and (b) iPad3

Update time on the (c) Android powered Asus Device and (d) NOKIA Lumia 900

Update time on the (e) Windows PC and (f) shows the overall average latency outlook on each device

Figure 8. Latency outlook on the consumer devices

From Fig. 8a which focuses on the Playbook, the minimum and maximum times for the Dropbox service is 61.56s and 312.44s respectively for the minimum and maximum range for the files. The Amazon S3 service produces a minimum and maximum time of 50.04s and 300.93s within the same range. The test on the iPad3 (Fig. 8b) shows a minimum and maximum times of 65.56s and 327.36s respectively for the boundary values of the file size from Dropbox and a minimum and maximum times of 59.44 and 315.66 respectively from the Amazon S3 facility. In Fig. 8c, the minimum and maximum times for the Dropbox service on the Android Asus Transformer Prime device are 107.56s and 407.34s respectively for the corresponding minimum and maximum file sizes while the Amazon S3 facility produces a minimum and maximum times of 95.44s and 400.01s respectively. The NOKIA Lumia 900 which is a Windows 7 Phone records in Fig. 8d minimum and maximum times of 217.56s and 541.23s respectively for the Dropbox service and a minimum and maximum times of 145.16s and 488.34s respectively from the Amazon S3 facility. The result on the PC in Fig. 8e shows that for the

minimum and maximum file sizes, the corresponding time frames are 34.08s and 209.33s respectively from the Dropbox service and 25.98s and 145.23s from the Amazon S3 service.

So, the next question is which device did better in the race? The answer is what is shown in Fig. 8f which summarizes the average time per device from both Dropbox and Amazon S3. It is important to state that the NOKIA device (which is just a smartphone) did perform poorly against the other devices because it is the most limited device in terms of resources. For instance, it has only a single core. On the other hand, the best consumer is the PC which has the richest resources such as higher processing and storage capabilities as well as higher and more stable bandwidth connectivity over LAN. The only surprise is the output of the Android device which is running on a quad core processor being in the fourth place finishing below the Playbook and iPad3 which are dual core devices.

Overall, the performance of the ALILI framework is encouraging because when our benchmark time from the Dropbox component is measured against the performance of

22

the actual Dropbox application, the time variation for the file sizes being analyzed is minimal; about 4.0seconds variation.

B. Scalability of the Proxy It is also important for us to determine the scalability of

the proxy application server of the ALILI framework considering its role as the hub and request router for all communications. Our methodology is to measure the throughput which is the number of requests that the proxy can process per a given time which is in seconds. Normally, scalability testing requires a lot of participants and the workload must be heavy. Thus, we decided to simulate the experiment with a tool called Apache Bench which is a load tester developed by Apache. The tool is deployed on Amazon EC2 instance and we configured the activities of 900 users of the system who are issuing varying requests concurrently from 1000 to 25000. However, we control the requests following the exponential distribution of mean 1 request per 10 seconds (i.e., 0.1 request/second) in order to simulate rapid growth. The graph in Fig. 9 shows the outlook of the scalability test.

Figure 9. Scalability Testing

The result shows that the lowest throughput is 350.00 requests/second and the maximum throughput is recorded as 467.45 requests/second. The average throughput for the entire test range is 412.73 requests/second with a standard deviation of 19.65 request/second.

Again, the result is promising considering the fact that in reality, 412.73 requests may not be issued by a single user in a second. Rather, the workload will be distributed among the

entire users; which means the system can handle even higher loads when less or equal to 900 users are using the framework in real life. This is a huge boost for consumer satisfaction.

VIII. CONCLUSION, LESSONS LERNED, AND FUTURE OUTLOOK

The mobile landscape is very fast aligning itself with cloud computing technologies to provide user satisfaction. But, the game changer is the advancement in Web Services which has facilitated the network space to render anywhere access to software and application services, social media services, online file and documents sharing and personalization, and many more options. In view of this, the cloud services providers have in many respects provide two of the most dominant Web Services APIs to developers and consumers in the form of SOAP and REST.

In this work, we aimed at providing a single complete service that integrates consumer devices (mobile devices and PC), the cloud technologies, and the Web Services. However, each of the technologies and platforms has their challenges which must be resolved. For instance, mobile devices experience intermittent disconnections while IaaS cloud providers enforce divergent product differentiation models. Hence, we proposed a framework called ALILI that focuses on the provision of a hybrid cloud to enable document and file sharing (which are modeled as Web services). The differences between the ALILI framework and other existing mobile cloud services are shown in Table I. The framework is built to take advantage of the Dropbox and Amazon S3 REST APIs while we also ensure the integration of the SaaS cloud services from Facebook and Google+; primarily to enforce security through the OAuth 2.0 mechanism.

In Section IV of this paper, we presented four research questions which we wanted to tackle and have successfully solved questions 1, 2, and 4. In the future, we shall dedicate much space for answering question 3 which is the management of bandwidth consumption and the implication for energy consumption in a mobile-cloud ecosystem. Our future works will also focus on PaaS integration into IaaS to provide a commodity cloud service.

TABLE I. THE DIFFERENCES/SIMILARITIES BETWEEN THE ALILI FRAMEWORK AND OTHER MODERN EXISTING MOBILE CLOUD SERVICES

iCloud Dropbox ALILI

User Authentication (Security) Requires Apple ID (Can be any email address as a registered id)

Requires any Email address but only one per account

Flexibility of using multiple social media accounts (Facebook or Google+)

Backend IaaS Services Apple Consumer Cloud Dropbox Cloud Dropbox Cloud and Amazon S3Heterogeneous Devices Currently limited to iOS devices Supports 5 platforms currently Supports any HTML5 embedded browser

Scaling and Adaptability May be very hard to do because the providers adopt a “closeed garden” business model.

The SDK can be adapted for multiple consumer platforms but the backend is static.

The backend can be changed (removed or adding) by just providing the API of the new IaaS provider to the proxy platform.

Multi-User Document Sharing Not supported Supported Type of Data Consistency Session Consistency

Email and Calendar Services Supported (plus file sharing) Not Supported (Purely file sharing services)

Product Orientation More focused on individual consumers. Group file sharing is not supported.

Focuses on individual consumers and enterprise usage is facilitated.

The priority is for enterprise group sharing and individual usage is secondary.

Multi-Product Satisfaction Not supported since the products belong to single service providers Supported

23

ACKNOWLEDGMENT Thanks to the Graduate Students in Computer Science at

the Multi-Agent Distributed Mobile and Ubiquitous Computing (MADMUC) Lab at the University of Saskatchewan, Canada. Thanks to Shomoyita Jamal who deployed the HTML5 front-end on the mobile devices that we put forward.

REFERENCES

[1] J. Christensen, “Using RESTful web-services and cloud computing to create next generation mobile applications,” Conference on Object-Oriented Programming Systems, Languages, and Applications, OOPSLA, p 627-633, 2009, OOPSLA 2009 Companion - 24th Annual ACM Conference on Object-Oriented Programming, Systems, Languages and Applications, OOPSLA 2009, Orlando, Florida, USA.

[2] E. Brewer, “Towards Robust Distributed Systems,” (invited Talk) Principles of Distributed Computing, Portland, Oregon, July 2000.

[3] S. Gilbert and N. Lynch, “Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Service,” SIGACT News, v 33, n 2, p 51-9, June 2002.

[4] C. Pautasso, Z. Olaf, and L. Frank, “RESTful Web Services vs. “Big” Web Services: Making the Right Architectural Decision,” 17th International Conference on World Wide Web 2008, WWW'08, p 805-814, 2008, Proceeding of the 17th International Conference on World Wide Web 2008, WWW'08.

[5] RADVIEW, RadView Software Whitepaper, Load Testing Web 2.0 Technologies: Ajax-RIA-SOA-Web Services, http://www.radview.com/files/Load%20Testing%20Web%202.0%20Technologies%20%5BWhitepaper%5D.pdf

[6] R. Royans, “Brewers CAP Theorem on distributed systems,” 2010. Last accessed September 23 2012. Available: http://www.royans.net/arch/brewers-cap-theorem-on-distributed-systems/

[7] D. Pritchett, “BASE: An Acid Alternative, In partitioned databases, trading some consistency for availability can lead to dramatic improvements in scalability,” Queue, v 6, n 3, p 48-55, May 1 2008.

[8] C. Young, “BizTalk Server 2006: The Compensation Model, Sagas” 2006. Last acceesed on September 30 2012. Available: http://geekswithblogs.net/cyoung/articles/100424.aspx

[9] Z. Kessin, “Building Web Applications with Erlang,” Publisher: O'Reilly Media, Inc., Pub. Date: June 7, 2012, Print ISBN-13: 978-1-4493-0996-1, Pages in Print Edition: 156.

[10] W. Vogels, “Scalable Web services: Eventually Consistent,” ACM Queue Vol. 6 No. 6 October 2008. Available: . http://queue.acm.org/issuedetail.cfm?issue=1466443

[11] CS Notes “Consistency Model - A Survey: Part I - What's Data Consistency Model and Why Should We Care?” 5/27/2009, Last accessed on September 1 2012, Available: http://xcybercloud.blogspot.com/2009/05/data-consistency-model-survey.html

[12] C. Monash, “DBMS2: Read-your-writes (RYW), aka immediate, consistency,” A Monash Research Publication, May 1, 2010. Last accessed on August 17, 2012, Available: http://www.dbms2.com/2010/05/01/ryw-read-your-writes-consistency/

[13] Read-Your-Writes Consistency, Getting Started with Replicated Berkeley DB Applications, June 10, 2011, Last accessed on August 17 2012, available: http://download.oracle.com/docs/cd/E17076_02/html/gsg_db_rep/C/rywc.html

[14] J. Browne, “Brewer's CAP Theorem,” January 2009, Last accessed on August 19 2012. Available: http://www.julianbrowne.com/article/viewer/brewers-cap-theorem

[15] V. Beal, “Understanding Web Services,” September 2010, Last accessed on September 02 2012, Available: http://www.webopedia.com/DidYouKnow/Computer_Science/2005/web_services.asp

[16] A. S. Cartwright, “SOAP Soup,” Last accessed on August 15, 2012, Avail.: http://www.xmlfiles.com/articles/adam/soapsoup/default.asp

[17] H. Han, S. Kim, H. Jung, Y. Heon, C. Yoon, J. Park, and Y. Lee, “A RESTful approach to the management of cloud infrastructure,” IEEE International Conference on Cloud Computing (CLOUD), p 139-42, 2009 CLOUD 2009.

[18] R. Sessions, “Fuzzy boundaries: Objects, components, and web services,” ACM Queue, v 2, n 9, p 40-7, Dec. 2004-Jan. 2005.

[19] X. Feng, J. Shen, and Y. Fan, “REST An Alternative to RPC for Web Services Architecture,” First International Conference on Future Information Networks. ICFIN 2009, p 7-10, 2009.

[20] Hypertext Transfer Protocol. Last accessed on September 04, 2012, Available: http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol

[21] S. Tilkov, “InfoQ: A Brief Introduction to REST,” Community Architecture, Dec 10 2007. Last accessed on September 17 2012, Available: http://www.infoq.com/articles/rest-introduction

[22] M. Fowler, “Richardson Maturity Model: steps toward the glory of REST,” March 2010, Last accessed on September 30, 2012, Available: http://martinfowler.com/articles/richardsonMaturityModel.html

[23] W. Lee, C. M. Lee; J. W. Lee, and J. Sohn, “ROA Based Web Service Provisioning Methodology for Telco and its Implementation,” Proceedings 12th Asia-Pacific Network Operations and Management Symposium, APNOMS 2009, p 511-14, 2009.

[24] P. Selonen, P. Belimpasakis, and Y. You, “Experiences in Building a RESTful Mixed Reality Web Service Platform,” Proceedings 10th International Conference, ICWE 2010, p 400-14, 2010 .

[25] V. Stirbu, “A RESTful Architecture for Adaptive and Multi-device Application Sharing,” ACM International Conference Proceeding Series, p 62-65, 2010, Proceedings of the 1st International Workshop on RESTful Design, WS-REST 2010.

[26] B. Sletten, “The REST architectural style in the Semantic Web,” JavaWorld.com, April 2009. Last accessed on September 20, 2012, Available: http://www.javaworld.com/javaworld/jw-04-2009/jw-04-rest-series-4.html

[27] Q. Wang, and R. Deters, “SOA's Last Mile-Connecting Smartphones to the Service Cloud,” CLOUD, pp.80-87, 2009, IEEE International Conference on Cloud Computing, 2009.

[28] M. Cantara, “Hype Cycle for Cloud Services Brokerage, 2012,” Gartner Report, ID:G00234256, July 2012. Available: http://www.gartner.com/technology/reprints.do?id=1-1BJMEZ4&ct=120731&st=sb#h-d2e3337

[29] R. K. Lomotey, S. Jamal, and R. Deters, "SOPHRA: A Mobile Web Services Hosting Infrastructure in mHealth," Mobile Services (MS), 2012 IEEE First International Conference on Mobile Services, vol., no., pp.88-95, 24-29 June 2012.

[30] PhoneGap, http://phonegap.com/ [31] Sencha, http://www.sencha.com/products/touch [32] jQuerymobile, http://jquerymobile.com/ [33] R. Boyd, “Getting Started with OAuth 2.0,” Publisher: O'Reilly

Media, Inc., Pub. Date: February 22, 2012, Print ISBN-13: 978-1-4493-1160-5, Pages in Print Edition: 80

[34] R. Lomotey, “Enabling Mobile Devices to Host Consumers and Providers of RESTFul Web Services,” Master of Science (M.Sc.) University of Saskatchewan, March 2012. Available electronically from http://hdl.handle.net/10388/ETD-2012-03-371 .

24