FOCUS: Mobile Software Development
Mobile Content as a Service A Blueprint for a Vendor-Neutral Cloud of Mobile Devices Mikko Raatikainen, Aalto University Tommi Mikkonen, Tampere University of Technology Varvana Myllärniemi, Aalto University Niko Mäkitalo, Tampere University of Technology Tomi Männistö, Aalto University Juha Savolainen, Danfoss Power Electronics
// A proposed approach to cloud computing for mobile devices maintains content in the device where it was first created. //
The ability to seamlessly and conveniently share content is becoming increasingly important as the number of types and uses of mobile devices continues to rise. Although the individual devices’ complexity and features vary, they often produce content that can be accessed by other kinds of devices.
Furthermore, they’re increasingly Webenabled and can therefore upload content to the Web as needed. Although various hosting services let users upload and share content, user reliance on the service providers raises trust and usability issues. Service providers could gain access to a
28 I E E E S o f t w a r e | p u b l is h e d b y t h e I E E E c o m p u t e r s o c ie t y
user’s content and exploit numerous privileges with it. Furthermore, once users have uploaded content to a service, changing service providers can present difficulties. For example, users can have problems permanently deleting content from the original service. Users also must choose what content to share and with whom. In general, sharing requires explicit user effort, including selecting specific services and setting privacy attributes, which can vary among services. In the end, some users might find it easier to not share the content at all. To deal with these problems, we’ve developed an architecture for managing the content created in and distributed among numerous mobile devices: a mobile device cloud, or mobile cloud, for short. Unlike current Web hosting and cloud computing services and content management systems (CMSs), the mobile cloud’s main function is to store created content on devices. Instead of uploading everything to central server, each device provides its own content to others as a service when requested. A server that maintains information about the users, devices, and privileges associated with the content manages this distributed hosting. Because the content remains on the devices, there’s no infrastructure that would lock users to a single vendor, as is the case with many content management systems. Considering the content as a service enables extensions to other kinds of services. First, existing services, such as Facebook, Twitter, or email can be added to the system as additional devices, making their content available in the same framework. Second, besides content, other device resources that can’t be uploaded (such as cameras and microphones) can be made available in the device cloud for creating compound services over multiple devices. 0 74 0 -74 5 9 / 12 / $ 3 1. 0 0 © 2 0 12 I E E E
Existing CMSs As the number of devices we actively use increases, so does the amount of content they include, calling for improved content management facilities. Although the term “content” is central and commonly used in connection with the Web, precisely defining it is somewhat difficult. The closest definitive terminology, used by Society of Motion Pictures and Television Engineers and the European Broadcasting Union, divides content into two parts. Essence is the content’s core—the raw program material.1 Metadata contains information about the essence and its representations. Examples of metadata include the content’s title, location, and format. CMSs manage both the essence and metadata. A CMS should include2–4 • storage in a safe location, • easy access regardless of time and place, • the ability to handle all phases of the content’s life cycle, and • easy, natural navigation and search. Currently, for mobile content, two common content management methods build on Web facilities. One synchronizes everything to the Web in a deviceor manufacturer-specific fashion. The other uses a service that manages the content for you.
Device Synchronization When using a device-synchronization service, you essentially create a backup of a device, for instance, by using the backup software the device manufacturer provided. Then, if the device malfunctions or you purchase a newer device, the service can restore the data and install it onto the new device with relative ease. However, this can create vendor lock-in and inherently limits
different devices and users from sharing content. When a single manufacturer can provide all the parts of the architecture, services are often tightly coupled with the vendor. For example, Apple’s iCloud (www.apple.com/icloud) supports vendor-specific devices and generic Web browsers, enabling the uploading of almost any imaginable content, including photos, videos, and music. This hybrid service can be considered both a backup and sharing mechanism, particularly between a user’s different devices. However, it doesn’t fully support sharing between users or between different vendors’ devices; in fact, it makes doing so rather inconvenient.
Service-Based Content Management Uploading content to a specific service generally requires user intervention, relies on pushing data without knowing whether anyone will ever wish to access it, and raises issues of data ownership. Moreover, if only some data is uploaded, the device itself needs content management. This type of management takes one of two approaches. In the first, the service can be available for generic content or tailored for certain types of content. This approach offers a simple model to allow a variety of content types—for example, DropBox (www.dropbox. com) relies on a file system—and a variety of devices can access the service. However, content management operations are relatively limited. In the second approach, services specialize in specific types of content— for example, Flickr (www.flickr.com) handles images. This approach can provide rich operations and metadata on the supported content, although at the expense of the content’s generality. These services upload content and copy it to multiple locations. So,
managing content becomes quite a burden. For instance, if a user wants to delete some content, he or she might need to browse through multiple services to remove the copied content, and there’s still no guarantee that the content will be removed from all the services. Also, each service’s pricing models and conditions can bring additional hassle. For example, with Flickr, users might temporarily lose access to some of their content if they’ve exceeded the limit of free uploads and don’t have a Pro account or haven’t renewed it. Moreover, Flickr can delete accounts that haven’t been used for 90 days.
What We’re Missing Neither of these methods is particularly flexible. The original vision of cloud computing is about openness and interoperability (both of which can be considered vendor-neutral). In reality, complications can arise when cloud service providers assume control over the uploaded content. To improve service, we propose a more flexible approach in which no unnecessary uploading occurs. Instead, the content always resides in the source device, with exceptions when making backups or caching. (For a look at a different approach related to ours, see the “Proximiter” sidebar.)
The Mobile Cloud The mobile cloud provides a general architecture in which, for example, security isn’t dealt with beyond rudimentary access control. This forms a natural extension of the existing cloud infrastructures, simply making mobile devices, together with their resources, first-class cloud citizens.
Architecture and Design In a cloud of mobile devices, direct device-to-device connectivity can lead to
J u ly/A u g u s t 2 0 1 2
| IEEE
S o f t w a r e 29
FOCUS: Mobile Software Development
Client devices
VisualREST server
Devices with content
Figure 1. An architecture for managing content in a cloud of mobile devices. The content resides on the devices; the VisualREST server mediates between them. It contains metadata for the content; provides a search over the metadata; and manages and authenticates users, devices, and access control. (REST stands for representational state transfer.)
complex, potentially cyclic interactions, which might further cause inefficient use of network and computational resources. We can avoid this by introducing a centralized element to mediate between devices. In our architecture, we call this central server the VisualREST server. Our mobile cloud’s architecture consists of two key elements: the VisualREST server and mobile devices (see Figure 1). The interfaces between these must be uniform, open, and flexible. The VisualREST server contains metadata for content created and residing on the devices. It provides a search over the metadata and manages and authenticates users, devices, and access control. Additionally, it can sometimes host the essence, if a mobile device can’t do so or must provide caching to prevent overload when users try to access the same content multiple times.
Mobile devices have dual roles. They act as service providers, storing created essence locally, uploading metadata to the server, and providing essence on request. They also act as user clients, searching for metadata and accessing the essence regardless of its location. The architecture in Figure 1 is also applicable in other scenarios. For example, the central element can be a service offered to numerous users by a single (potentially global) cloud computing service provider. Or, it can be a user-specific computer that manages the content of that user’s devices. This setting determines the scope of mobile devices that belong to the same cloud and determines how content in the devices is accessed.
Implementation and Deployment The VisualREST server interacts with
30 I E E E S o f t w a r e | w w w. c o m p u t e r . o r g / s o f t w a r e
devices that access content and devices that provide content. Furthermore, the VisualREST server includes additional code for storing data that has been backed up or cached in the server and for accessing relevant social media content. So, these sites appear to the user as additional devices in which content can be exposed through the same system. On the device side, each contenthosting mobile device needs a piece of code for communicating with the VisualREST server and for maintaining its own content. Although several options exist for detecting content changes, in our experiment, we monitored file system changes. Each client device needs software for accessing content. In the simplest case, you can download this application on the fly from the VisualREST server as a webpage. However, to create more compelling applications, creating purpose-built clients for individual tasks is often necessary. To complement the Web-based system, we implemented a middleware application running on a Nokia N900 smartphone. This represents cloud content in terms of file systems, which means that legacy applications that can treat files can access cloud content without modifications. The interaction between elements in the architecture relies on standard protocols following RESTful principles: all resources are accessed with a generic interface, each request from client to server must contain all the information necessary to understand the request and can’t take advantage of any stored context on the server, and the system is comprised of resources named using a URL.5 Consequently, we can scale the server simply by introducing more computing resources as needed. All the communication between the client and the server happens via HTTP. The request mechanism for certain content from a device is based on XMPP (Extensible Messaging and Presence Protocol; http://xmpp.org). If XMPP isn’t
available, the system will do its best with HTTP, although this will likely cause delivery delays. The system’s implementation details appear elsewhere.6,7 Pieces of our system software are available for download as open source, at https://github. com/hpeltola/VisualREST or www.soberit.hut.fi/cloudsoftware.
Design Decisions Our architecture’s most obvious benefit is the autonomy created by sharing without uploading data to the cloud. Users don’t need to commit to a certain vendor’s devices or services and can even create a personal system if they desire. Furthermore, we considered the ease of deployment throughout the design process. We believe that the system manifests simply the fundamental deployment steps that are necessary to remain vendor-neutral. On the technical side, the design and implementation have given us unique insight into designing systems that exploit mobile data as a service. Because the system has no single control point, it remains vendor-neutral, and devices and computers from different manufacturers can be used. The only potential control point is the VisualREST server, which is available as open source, and the system can scale to various user needs. The approach’s downside is possible inconvenience for users. Each contenthosting device needs special software, which at this point must be installed. Given the appropriate standardization effort, the software could be preinstalled in a portion of mobile phones, but this would require support from a wide industrial consortium of vendors. However, we expect that webservers eventually will find their way to mobile devices, which will be a key element in the mobile realm’s transition to the open Web. This transition will be crucial to designing vendor-neutral systems in other existing domains. This,
Proximiter Proximiter is a content-management system based on a cloud of mobile devices.1 Unlike our approach (see the main article), Proximiter uses device proximity as the design driver. In this design, nearby devices can form an implicit mobile cloud in which they can exchange content. Furthermore, operations are geared toward exchanging content more interactively and thus are generally simpler than in our architecture. Generalizing the Proximiter approach results in cloudlets that build on locally available infrastructure.2 Cloudlets assume that mobile devices’ resources are always considerably inferior to fixed computers. In contrast, we expect that mobile devices will be increasingly powerful and capable of performing hosting tasks. So, building on their facilities will be an increasingly feasible option. References 1. B. Xing, K. Seada, and N. Venkatasubramanian, “Proximiter: Enabling Mobile Proximity-Based Content Sharing on Portable Devices,” Proc. 2009 IEEE Int’l Conf. Pervasive Computing and Communications (PerCom 09), IEEE, 2009, pp. 1–3. 2. M. Satyanarayanan et al., “The Case for VM-Based Cloudlets in Mobile Computing,” IEEE Pervasive Computing, vol. 8, no. 4, 2009, pp. 14–23.
in turn, might simplify system creation with minimal installation by the user. Apart from the code in content-hosting devices, the situation is more promising. The VisualREST server itself can be deployed flexibly. For instance, it can be provided as a cloud-based service, a separate hardware element readily available from a store, or a piece of downloadable software installable on existing computers. In addition, increasingly compelling applications can be coupled with Web technologies only. This would enable an approach in which the VisualREST server provides different content-consuming applications as a service, and they could be loaded along with the content when necessary. Furthermore, because onthe-fly webpage updates still have problems, it’s also possible to create native apps that will make the content even more appealing, assuming that additional programs can be installed. The VisualREST server can also serve as a gateway to services available in the Web. For example, we’ve used the system to generate Facebook and
Flickr content. The implementations associated with these functions reflect their counterparts designed for mobile data, treating each data source as a virtual device (although, for practical reasons, much caching occurs). Researchers have also designed similar systems that balance the capabilities and capacity of cloud computing facilities and mobile devices. Some of these systems contain additional features such as offloading tasks to the cloud.8
A
s mobile devices become increasingly capable, we expect advances in providing mobile data as a service. Furthermore, new networks providing faster connectivity make it increasingly feasible to implement such systems. However, to create a single, vendor-neutral system for managing in-device mobile data, we still need standardization. Although many major mobile device manufacturers have a positive opinion of vendor-based services, the best way to approach standardization is in terms of
J u ly/A u g u s t 2 0 1 2
| IEEE
S o f t w a r e 31
About the Authors
FOCUS: Mobile Software Development
Mikko Raatikainen is a researcher at Aalto University, Finland.
His research interests include empirical research in software engineering, software architecture, and variability management. Raatikainen has an MSc (Tech.) in software engineering from Helsinki University of Technology. Contact him at
[email protected].
the open Web. This approach would most likely lead to a solution that could be generalized to be universally applicable in the Web. We’re excited about such an opportunity and look forward to the benefits it could bring.
Acknowledgments Tommi Mikkonen is a professor of software engineering at Tam-
pere University of Technology, Finland. His research interests include mobile software, cloud computing, Web programming, embedded systems, and mashup development. Mikkonen has a PhD in software engineering from Tampere University of Technology. Contact him at
[email protected].
Varvana Myllärniemi is a researcher and teacher at Aalto University’s Software Business and Engineering Institute. Her research interests include software architectures, quality attributes, and software product families. Myllärniemi has an MSc in computer science from Aalto University, Finland. Contact her at
[email protected].
Niko Mäkitalo is a researcher at Tampere University of Technology’s Institute of Software Systems. His research interests include distributed systems, cloud software, and mobile devices. Mäkitalo has an MSc in software engineering from Tampere University of Technology, Finland. Contact him at
[email protected].
Tomi Männistö is a professor of software engineering at Aalto Uni-
versity, Finland. His research interests include software architectures, software variability management, and flexible requirements engineering. Männistö has a PhD in computer science from Helsinki University of Technology. He chairs the International Federation for Information Processing Technical Committee 2 Working Group 2.10, Software Architecture, and is a member of the IEEE Computer Society and ACM. Contact him at
[email protected].
Juha Savolainen is a software systems manager at Danfoss Power Electronics, Denmark. His research interests include software engineering, software product lines, requirements engineering, and software architectures. Savolainen has a PhD in computer science from Aalto University. He’s a member of the IEEE Computer Society. Contact him at
[email protected].
We thank the participants of this study at Tampere University of Technology, Aalto University, and the Nokia Research Center, especially Timo Aaltonen, Subhamoy Ghosh, Adrian Hornsby, Tapani Leppänen, and Heikki Peltola.
References 1. A. Mauthe and P. Thomas, Professional Content Management Systems: Handling Digital Media Assets, John Wiley & Sons, 2004. 2. A. Spedalieri et al., “Multimedia Content Management Support in Next Generation Service Platforms,” Proc. 3rd Int’l Conf. Mobile Multimedia Communications (MobiMedia 07), Inst. for Computer Sciences, Social Informatics, and Telecommunications Eng., 2007, pp. 14:1–14:7. 3. K. Curtis, P. Foster, and F. Stentiford, “Metadata—the Key to Content Management Services,” Proc. 3rd IEEE Meta-Data Conf. (Meta-Data 99), IEEE, 1999; www.ee.ucl. ac.uk/~fstentif/curtis.htm. 4. C.D. Cranor et al., “Design and Implementation of a Distributed Content Management System,” Proc. 13th Int’l Workshop Network and Operating Systems Support for Digital Audio and Video (NOSSDAV 03), ACM, 2003, pp. 4–11. 5. R.T. Fielding and R.N. Taylor, “Principled Design of the Modern Web Architecture,” ACM Trans. Internet Technology, vol. 2, no. 2, 2002, pp. 115–150. 6. S. Ghosh et al., “Cloudifying User-Created Content for Existing Applications in Mobile Devices,” Proc. IEEE 35th Ann. Computer Software and Applications Conf. (COMPSAC 11), IEEE CS, 2011, pp. 510–515. 7. N. Mäkitalo et al., “VisualREST: A Content Management System for Cloud Computing Environment,” Proc. 37th Euromicro Conf. Software Eng. and Advanced Applications (SEAA 11), IEEE CS, 2011, pp. 183–187. 8. E. Lagerspetz and S. Tarkoma, “Mobile Search and the Cloud: The Benefits of Offloading,” Proc. 2011 IEEE Int’l Conf. Pervasive Computing and Communications Workshop, IEEE CS, 2011, pp. 117–122.
Selected CS articles and columns are also available for free at http://ComputingNow.computer.org. 32 I E E E S o f t w a r e | w w w. c o m p u t e r . o r g / s o f t w a r e