Supporting the Personal Cloud From Mobile Cloud Computing (MCC) to Ubiquitous Cloud Computing (UCC)

Ashik Kazi, Rahnuma Kazi Department of Computer Science

University of Saskatchewan Saskatoon, Canada

{kaa734, ksr494} @mail.usask.ca

Ralph Deters Department of Computer Science

University of Saskatchewan Saskatoon, Canada deters@cs.usask.ca

Abstract—Using apps on mobile devices as intermediaries for accessing cloud services leads to an app-ification of these services with a focus on device-specific user experiences. However, as the number of computing devices a user owns increases, the importance of cross-platform deployment and cross-platform experience increases. Instead of the user experience on a specific device, the consistent user experience across multiple devices becomes the key concern. Being able to use cloud services in a location, time and device independent manner results in a novel cloud experience. Unlike the device-centric mobile cloud computing the focus is on a user-centric cloud computing experience called personal cloud. In the personal cloud users are able to access their digital assets and services via apps across multiple devices in a seamless manner. This paper focusses on the underlying infrastructure challenges of the personal cloud and presents a consumer-centric cloud portal (C3P) that assists apps in device, time and location independent access of cloud services.

Index Terms—Personal Cloud, Mobile Cloud Computing, Ubiquitous Cloud Computing

I. FROM MOBILE TO UBIQUITOUS CLOUD COMPUTING

“Cloud-Computing” is a broad term that encompasses applications/functionality delivered as services over the internet and the software/hardware infrastructure to host them [1]. This “utility computing model” (John McCarthy, 1961), allows the purchase of virtualized hardware (Infrastructure as a Service, IaaS), software platforms (Platform as a Service, PaaS) or applications/functionality (Software as a Service, SaaS) in a pay-as-you-go manner, comparable to the metered purchase of electricity, gas or water. While cloud computing is most often used as a means for organizations to outsource IT infrastructure [2], Mark Baccue [3] identified the use of cloud computing as a means to compensate for the lack of computational resources of the relentlessly growing number of smartphones [4]. Given the emphasis on mobile computing devices with wireless connectivity, Baccue called this form of cloud-computing Mobile Cloud-Computing (MCC). In mobile cloud computing, the apps running on the device use cloud-services to overcome resource-constraints of their host device, outsource resource-consuming tasks or to provide access to cloud services. Using apps on mobile devices as intermediaries for accessing cloud services leads to an app-ification of these services with a focus on device-specific user experiences. However, as the number of computing devices a user owns

increases cross-platform deployment and experience become more important. Instead of the user experience on a specific device, the consistent user experience across multiple devices becomes the key concern. Being able to use cloud services in a location, time and device independent manner results in a novel cloud experience. Unlike the device-centric mobile cloud computing the focus is on a user-centric cloud computing experience called personal cloud. In the personal cloud users are able to access their digital assets and services via apps across multiple devices in a seamless manner. Being able to link connected consumer devices like smartphones, portable media players, storage device, tablets and (smart) TVs to cloud services enables richer experience with the devices, cloud hosted services, and their apps.

Fig. 1: C3P connecting consumer devices to cloud services

Enabling the personal cloud experience, requires the need

for cloud based storage of user context, digital assets and app state and their seamless synchronization across the devices. This in turn requires special mechanisms for data delivery and data consistency management. Besides the 4 above mentioned functional requirements

Storage Synchronization Delivery Consistency Management

we identify 2 non-functional requirements, namely

Dependability and Scalability.

C3P

2012 IEEE Asia Pacific Cloud Computing Congress (APCloudCC)

978-1-4673-2904-0/12/$31.00 ©2012 IEEE 25

To overcome the challenges of the personal cloud, this paper argues for the use of cloud hosted portal services that provides the infrastructure for apps and services. As shown in figure 1, the consumer-centric cloud portal (C3P) is a middleware that acts as an intermediary between apps and services. Given that mobile devices can experience intermittent connectivity, C3P provides mechanisms for optimizing bandwidth usage and dealing with short-lived loss of connectivity. The remainder of the paper is structured as follows. Section 2 provides an overview of relevant work. This is followed in section 3 by the introduction of a consumer cloud-computing platform that enables device and vendor independent access to cloud-services. Section 4 presents results of the evaluation and the paper concludes with a summary, conclusions and an outlook.

II. RELATED WORK

Offloading is a well-studied approach of using cloud services within the context of apps on mobile devices. A common approach that has its roots in the mobile agent community is the sharing/moving of part or parts at the VM level. Cloudlets [9], ISR [10], Horatio [11], MAUI [12] and Clone Cloud [13] are all based on the concept of offloading mobile devices by migrating part or parts of their virtual machines to a remote host. Besides the obvious security concerns the required high bandwidth and low latency tend to pose major challenges to all these approaches. In addition VM migration assumes a very tight coupling between mobile device and provider since both sides must share the same VM environment. ThinkAir [14] virtualizes the complete mobile device in the cloud. Besides the obvious backup features, the physical device can push tasks to its virtual clone. However, the bandwidth and latency requirements are still high, limiting the use of this approach.

Partitioning of the app, e.g. identifying components that can be moved or replaced with cloud-hosted services is an alternative to the VM-centric offloading. In the Cuckoo [15] framework, applications are expected to be ready for distributed execution. In overload situations, marked parts of the applications can be offloaded to a cloud-service. Obviously, reliable communication with low latency is required, since the once local calls are now RPCs. Mei et al. [16] uses a code repository to push components onto various cloud platforms thus allowing for more flexibility. The Weblet approach [17] is based defining RESTful services that can be executed in the mobile device or the cloud. Weblets are implemented using special SDK and using C# which allows the automatic generation of cloud-ready and mobile device-ready components. Depending on the load, the mobile device can request the spawning of a Weblet in a cloud service (e.g. EC2) that will replace the internal component. While partitioning of apps avoids the tight coupling of the VM-centric offloading, it is still based on a device-centric view, assuming good interconnectivity and single device usage.

Ardissono et al. [18], Song et. al. [19] and Tian et al. [20] overcome these issues by introducing cloud-hosted infrastructure/middleware. The Personal Cloud Platform (PCP)

from [18] is a GAE based solution that offers synchronization, notification and context functionality for web clients. However, PCP assumes reliable connections and thus ignores data consistency issues. Its event-based synchronization support is based on the publish-subscribe pattern. The channel-based solution seems to target digital assets (e.g. documents). Since PCP targets resource rich web browser apps with good and stable connectivity there is no support for app state. Tian et al. [20] identify the growing pool of available (commercial) cloud services as elements of a personal cloud infrastructure. Tornido Sync [21], iCloud [22], PongoPlug [23], Iomega tools [24], AWS (Amazon) [25], SkyDrive (Microsoft) [26] and Google Drive [27] are just some examples from the steadily growing pool of cloud storage services that also offer basic file synchronization services. The main contribution of Tian et al. [20] is the introduction of a framework for ensuring security that consists of a proxy server called end-user service portal that controls the access to the cloud services. The proxy itself communicates with special components residing within the cloud-service provider space. While offering components with a clear semantic and an emphasis on the separation of concerns, the main drawback of this approach is the tight coupling of proxy and cloud services.

The Web Based Application Program Management (wAPM) framework [20] offers a more elaborate framework consisting of proxy and device hosted components. It supports user, device, (file) synchronization and application management. The communication seems to be push based allowing for loose coupling between proxy and devices. Unfortunately the paper provides little technical detail and evaluation. It also seems that the synchronization is focussed on files ignoring app state. Finally there is no support for dealing with consistency and communication issues arising from intermittent connectivity. Scalability and dependability are also not addressed.

III. CONSUMER-CENTRIC CLOUD PORTAL

The consumer-centric cloud portal (C3P) shown in figure 2 follows the proxy middleware pattern [18, 19, 20].

Fig. 2: Architecture of C3P

It is designed as an event-driven system that provides

RESTful web service APIs and thus assumes HTTP-based

26

communication. The use of event messages within C3P allows asynchronous communication and thus loosely coupled components which in turn enable distribution and replication of components. As shown in figure 2, C3P consists of one or more HTTP servers that expose the system to connected devices and 4 container components that host the core elements, namely

Connectors container Resource container Workflow container and Proxy container.

A. HTTP server

One or more HTTP servers are used to expose the resources, workflows and proxies as REST web services. The HTTP servers’ primary purpose is the transformation of inbound HTTP traffic (e.g. HTTP requests, WebSocket messages) into C3P event messages and the conversion of C3P event messages back into HTTP traffic. To support consumers with intermittent connections, the HTTP servers communicate with the resources, workflows and stubs via a connections container. This allows a consumer that loses connectivity to maintain a presence in C3P and thus resume the communication once connectivity has been regained.

B. Containers

The C3P system uses containers as a means of structuring the different types of concurrently executed activities. Each container contains one globally visible message router e.g. resource_message_router, that is responsible for handling the delivery of inbound and outbound messages for the container. Containers can be divided into sub-containers that in turn reside on different hosts allowing for horizontal scalability.

1) Connector Container The connector container hosts the connectors that represent

individual HTTP connections from an app on a device to the C3P system. The HTTP server that maintain the “physical” HTTP connection to the device pushes the data it receives in form of event messages to the connectors that in turn send them to the corresponding resource, workflow or proxy. Event messages that are received by the connectors are stored in their FIFO message queue and the connected HTTP server receives a notification indicating that messages are available for transmission to the device. The HTTP server then requests the next message and upon receiving it sends it to the device. Upon successful delivery, the HTTP server is required to send a delete message to the connector which triggers the persistent removal of the message from the queue. Should a device loose connectivity, it can reconnect using the same or a different HTTP server. Once the device has successfully connected, the HTTP server rebinds with the connector of the device/app id and starts sending queued messages.

2) Resource Container Resources represent the standard entry points to the C3P

system. Following REST principles, these resources are

organized hierarchically allowing for unique paths that are used to reference them. The root resource in this layer is the generic app resource (app_resource). Individual apps are added as child nodes (via POST) to the root resource. The individual app nodes, each representing a different app, contain the unique ids of their registered users as child nodes. The user nodes themselves contain the user-models, services, devices and app-states as child nodes. Finally the nodes, user-models, services, devices and app-states nodes, contain child nodes with instances of their respected parents e.g. devices contains as child nodes resources representing the tablets & smartphones that are owned by the user and have the app installed. The resources serve three purposes. They

provide entry-points for the apps to the services, serve as caches for requests to the resource and store all meta-data associated with the resource.

Since each resource is uniquely identified by its URL, an

app on a mobile device can use standard HTTP requests to engage it. Using the standard HTTP verbs HEAD (meta-information), GET (read), PUT (replace), PATCH (write), POST (create) and DELETE (destroy), a state-centric form of interaction is enforced which allows for caching of responses. Since the resources are exposed via the HTTP servers, all traffic to the resources has been preprocessed by the HTTP server and thus arrives as structured C3P messages. The messages received by a resource are processed sequentially to avoid overloads. Upon receiving a request message, the resource checks if the request can be served by using the cache. If this is possible, the data in the cache is used to create the response message which is sent back to the HTTP server. In case the cache can’t be used, a workflow instance in the workflow container has to be created. This is done by sending a create event to the manager of the workflow layer. The create event contains the original request, the meta-data of the resource, and a URL of the workflow definition. Upon receiving a response event message (a 4-tuple consisting of request, response, meta-data and timestamp) the resource creates a response message and sends it to the HTTP server. If the timestamp of the response message is newer than the one contained in the resource, the meta-data and the cache are updated.

3) Workflow Container The workflow container hosts a workflow manager and the

workflows that define the behaviors of the RESTful resources. Since workflows can engage more than one cloud service, the workflow layer supports a declarative N:M mapping of resources and cloud services. Each workflow is given a unique opaque URL. Upon receiving a create workflow event, the workflow manager checks that the current number of workflow instances is below a preset values and then spawns a new workflow instance that will be concurrently executed. Upon starting, the workflow is given the original request and the resource meta-data. Using the proxies as intermediaries, the workflow instance engages the cloud services in the prescribed manner. Once completed, the workflow returns the result in

27

form of a 4-tuple response event message consisting of request, response, new resource state and timestamp back to the resource which in turn updates if needed its cache and/or state and returns the result to the requester.

4) Proxy Container The proxy container contains the proxies that hide all the

communication details needed for engaging the cloud services. Each proxy is responsible for creating the service invocations and handling the responses. This includes request augmentation e.g. adding tokens and credentials to the requests and signing them, and protocol transformation e.g. switching from REST to SOAP. The service layer returns a 3-tuple response event message consisting of request, response and timestamp.

IV. COMMUNICATION

Like the portals of [18,19,20], C3P can be engaged by sending a HTTP request from the connected device to its HTTP server. The HTTP request itself can be sent either as a standard request via HTTP/S or JSON encoded via a WebSocket connection. While the WebSocket requires some initial overhead in establishing the connection, it allows for significantly faster communication due to the avoidance of the HTTP overhead.

C3P supports the use of app-specific device hosted stubs. The stub allows encapsulating the communication between app and C3P in a single object and thus greatly simplifies the app development process. However, the main benefit of using a client hosted stub is the deeper integration between app and C3P. Stubs can maintain a cache, compensate intermittent connectivity and request pre-fetching based on the app state. While stubs can be generated for any host language, the current version of the C3P uses only JavaScript based stubs targeting mobile web apps and hybrid apps.

V. IMPLEMENTATION

While originally designed for the Node platform, the system was implemented in Erlang/OTP [6,7]. Erlang is a high-level concurrency-oriented programming language that supports large numbers of concurrent actor like activities, called Erlang processes. These Erlang processes are actor like constructs [8] that are controlled by the schedulers of the Erlang VM. Since Erlang does not support shared memory, communication between the Erlang processes is achieved by exchange of messages that are delivered via the internal messaging services. A particularly interesting aspect of Erlang is the ability of linking multiple nodes (hosts of Erlang VMs). Once Erlang nodes are linked, it becomes possible to seamlessly route messages and to spawn Erlang processes between them. Last but not least, Erlang/OTP offers a set of easy to use patterns/templates that allow the development of fault-tolerant systems.

In the C3P implementation YAWS 1.9 servers (HTTP servers written in Erlang) act as HTTP servers. YAWS was chosen due to its maturity, support for large numbers of concurrent connections, support for standard HTTP protocols like WebSockets and the native Erlang interface. The YAWS

servers are linked to the nodes hosting the containers to ensure seamless message exchange. YAWS servers are designed to handle each connection via a separate Erlang process. Using the configuration file of YAWS, URL patterns can be defined and linked to specific Erlang functions which process the HTTP traffic. C3P uses this mechanism to parse the inbound HTTP traffic and send it as Erlang messages to the connectors, which are implemented as processes on a different node. Within the current C3P system two basic communication protocols are supported via the YAWS servers, namely HTTP/S and WebSockets.

All containers in C3P are individual nodes (Erlang VMs) that have been linked together to allow seamless communication. The connectors, resources, workflows, workflow instances, stubs are all Erlang processes. In Erlang each process has a globally unique process ID (PID) that can be registered either locally or globally under a name. With the exception of the message routers that are registered globally, all PIDs are registered locally to allow for replication of the resources, workflows and proxies.

As mentioned earlier, the connectors in C3P are locally named Erlang processes. The Erlang processes of the HTTP server (YAWS) send their parsed HTTP traffic as messages to the message router of the connector container (connector_message_router). This globally registered message router for the connector container performs a local lookup and then uses the internal Erlang messaging system to deliver the message to the process. The connector then sends a message to the corresponding resource (via the resource_message_router).

The resources in the resource container are also Erlang processes and their URLs are the names under which their processes IDs are locally registered. The use of local registries enables the C3P to replicate Erlang processes across multiple nodes without creating naming conflicts. Each resource maintains a cache that is used to minimize traffic. In case the request can’t be served using the cache, a message is sent to the workflow manager instructing it to create a new workflow instance (Erlang process), and to pass it the name of function representing the workflow as well as the current meta-data of the resource.

The created workflow instance engages the cloud services by sending requests to the proxies. The proxies finally create the requests and invoke the cloud services using the Erlang httpc library. The responses are sent back to the workflow instance. Upon completion the workflow instance sends a response to the resource and then terminates. The resource uses the response from the workflow instance to update the cache & meta-data and sends a response to the connector that sent the request. The connector finally informs the HTTP server that is responsible for delivering the response to the app on the device.

VI. EVALUATION

One obvious advantage any service portal offers is the simplification of accessing the cloud services. However, the gains of reducing the lines of code within the app and the extra effort in maintaining and configuring a portal are difficult to

28

quantify. Since the personal cloud promises time, location and device independent access to cloud services, data transmission is an important issue that can be quantified.

A. WebSocket versus XMLHttpRequest

WebSockets are a relatively new communication protocol that runs over established HTTP connections. Its main advantage is the bi-directional communication without the need for sending request and response headers. To evaluate the impact of using WebSockets, an Asus Transformer tablet running Android 4 was used.

When accessing a REST web service using HTTP GET a total of 598 bytes of overhead data was sent, 464 bytes of request header data and 134 bytes of response headers). When a WebSocket was used, only 2 bytes of overhead was measured. However, establishing a WebSocket added a onetime overhead of 359 bytes (230 bytes sent from the client, 129 received from the server). The impact of the different overhead becomes more pronounced when executing consecutive read requests.

Fig. 3: Roundtrip times of 600 HTTP GET (read) requests (milliseconds)

Figure 3 shows the results of issuing 600 times a HTTP

GET requests that return 1000 bytes as payload in the response. The requests were sent at the rate of one 1 request per second and the times are shown in milliseconds for each request-response cycle. Repeating the same requests using WebSockets showed a significant difference as shown in figure 4.

While WebSockets are obviously a more efficient way to communicate, they are not supported by most commercial cloud services. This in turn means that WebSocket can only be used to communicate with the portal (using the stub).

To truly reflect the costs it is therefore necessary to add the costs for the portal of issuing the HTTP request and returning the result via the WebSocket to the tablet. In our evaluation we assumed that “reads” will outnumber “writes” in the personal cloud and that caching is possible. The performance of the C3P is therefore highly dependent on the used workflows e.g. mix of reads and writes.

B. Stub + WebSocket

Using a stub with local cache reduces the communication costs even further and compensate for intermittent

connectivity. However, as the amount of data stored in the cache of the stub grows, the costs for avoiding stale data increase. This problem can be overcome by providing the stub with app state information. If the stub has

a list of app states and the data needs of the app in each

it can pre-fetch the data needed for the app when a state change is signaled. This in turn allows for a significant reduction in communication with the C3P system.

Fig. 4: Roundtrip times 600 WebSocket read requests (milliseconds)

VII. CONCLUSION & OUTLOOK

Cloud computing has been viewed in the past primarily as a means for organizations to increase their flexibility. Recently however, cloud computing has begun to enter the consumer space by offering solutions to personal computing needs that are based on virtualization e.g. cloud storage. Accessing such cloud services with tablets and smartphones enables user and context aware cloud services resulting in a personal(ized) cloud. In the personal cloud users are able to access their digital assets and services via apps across multiple devices in a seamless manner.

This paper presents a consumer-centric cloud portal (C3P) that is designed to support the development of cross-platform apps. Unlike previous cloud portals [18,19,20], it provides a robust RESTful web service interface, allows for the definition of composite resources via workflows and encapsulates the details of engaging web services via proxies. Being able to define composite resources is of great practical importance since it allows bundling multiple cloud services into one single resource e.g. linking multiple free cloud storages into one larger one or to use RAID like distribution schemes when saving data. Hiding all the details of engaging a cloud service in a proxy greatly simplifies app development,

29

especially when building cross-platform apps. In addition the C3P system supports the use of stubs that reside in the app on the device and thus allow the use of highly optimized communication protocols and support for intermittent connectivity.

Our future work will focus on formalizing the cloud service needs of apps and the integration with tools for developing hybrid apps like Sencha Touch 2 & jQuery Mobile.

By providing a more formal way for app developers to identify when and how they wish to engage cloud services will allow automating the definition of stubs, resources and workflows within C3P. While our focus will remain on mobile web apps and hybrid apps, we also intend to explore to generation of stubs in the host’s language of the connected devices.

Providing integration with tools like Sencha Touch 2 and jQuery Mobile is fairly simple to achieve and would provide value for developers. We plan to provide JavaScript libraries that can be linked to jQuery page load/change events and Sencha’s view elements.

REFERENCES

[1] M. Armbrust et al.: “Above the Clouds: A Berkeley View of Cloud Computing”, http://d1smfj0g31qzek.cloudfront.net/abovetheclouds.pdf, 23 pages, 2009.

[2] Gartner Report G00166525: “Forecast: Sizing the Cloud; Understanding the Opportunities in Cloud Services”, 11 pages, 2009.

[3] M. Beccue, ABIresearch Report RR-MCC: “Mobile Cloud Computing”, 64 pages, 2009.

[4] Portio Research: “Portio Research Mobile Factbook 2009”, 37 pages, 2009.

[5] S. Kleynhans , Gartner Report “G00226511: The New Pc Era: The Personal Cloud”

[6] J. Armstrong, “A history of Erlang,” in HOPL III: Proceedings of the third ACM SIGPLAN conference on History of programming languages. New York, NY, USA: ACM, 2007, pp. 6–1–6–26.

[7] J. Larson, “Erlang for concurrent programming,” Queue, vol. 6, no. 5, pp. 18–23, 2008.

[8] G. Agha, Actors: a model of concurrent computation in distributed systems. Cambridge, MA, USA: MIT Press, 1986.

[9] M. Satyanarayanan, P. Bahl, R. Caceres, and N. Davies, “The Case for VM-based Cloudlets in Mobile Computing”, Journal IEEE Pervasive Computing Volume 8 Issue 4, pp. 14-23 October 2009.

[10] M. Kozuch and M. Satyanarayanan, “Internet Suspend/Resume”, Proceedings of the 4th IEEE Workshop on Mobile Computing Systems and Applications, Callicoon, NY, June 2002.

[11] S. Smaldone, B. Gilbert, N. Bila, L. Iftode, E. Lara, and Mahadev Satyanarayanan, “Leveraging Smart Phones to Reduce Mobility Footprints”, MobiSys '09, Kraków, Poland, June, 2009.

[12] E. Cuervoy, A. Balasubramanianz, D. Cho, A. Wolmanx, S. Saroiux, R. Chandrax, P. Bahlx, “MAUI: Making Smartphones Last Longer with Code Offload”, MobiSys '10 Proceedings of the 8th international conference on Mobile systems, applications, and services, 2010.

[13] B. Chun, S. Ihm, P. Maniatis, M. Naik, “CloneCloud: Boosting Mobile Device Applications Through Cloud Clone Execution”, EuroSys, 2011.

[14] S. Kosta, Andrius Aucinas, Pan Hui, Richard Mortier,Xinwen Zhang, “Unleashing the Power of Mobile Cloud Computing using ThinkAir”, In ArXiv e-prints, 2011.

[15] R. Kemp, Nicholas Palmer, Thilo Kielmann and Henri Bal., “Cuckoo: a Computation Offloading Framework for Smartphones,”MobiCASE 2010.

[16] C. Mei, James Shimek, Chenyu Wang, Abhishek Chandra, and Jon Weissman, “Dynamic Outsourcing Mobile Computation to the Cloud”,Technical Report Department of Computer Science and Engineering,University of Minnesota.

[17] R. Balan, D. Gergle, M. Satyanarayanan and J. Herbsleb.,”Simplifying cyber foraging for mobile devices”. In MobiSys '07: Proceedings of the 5th international conference on Mobile systems, applications and services (2007), pp. 272-285.

[18] L. Ardissono, A. Goy, G. Petrone and M. Segnan, “From Service Clouds to User-centric Personal Clouds”, IEEE Cloud Computing Cnference, 2009, pp. 1-8.

[19] H. Song, E. Choi, C. Bae and J Lee, “Web Based Application Program Management Framework in Multi-Device Environments for Personal Cloud Computing”, IT CONVERGENCE AND SERVICES, Lecture Notes in Electrical Engineering, 2011, Volume 107, Part 6, 529-536.

[20] Y. Tian, B. Song, E. Huh,” Towards the Development of Personal Cloud Computing for Mobile Thin-Clients”, International Conference on Information Science and Applications (ICISA), 2011 ,pp 1 -5.

[21] Tornido, http://www.tonido.com/app_sync_home.html

[22] iCloud, https://www.icloud.com/

[23] PongoPlug, http://pogoplug.com/

[24] Iomega Personal Cloud, http://iomegacloud.com/landing_page.php

[25] AWS, http://aws.amazon.com/

[26] SkyDrive, https://skydrive.live.com/

[27] GoogleDrive, https://drive.google.com/start#home

30