Noname manuscript No.(will be inserted by the editor)

Towards an Elastic Application Model for Augmenting the ComputingCapabilities of Mobile Devices with Cloud Computing

Xinwen Zhang · Anugeetha Kunjithapatham · Sangoh Jeong· Simon Gibbs

Received: date / Accepted: date

Abstract We propose a newelastic applicationmodel thatenables seamless and transparent use of cloud resources toaugment the capability of resource-constrained mobile de-vices. The salient features of this model include the partitionof a single application into multiple components calledwe-blets, and a dynamic adaptation of weblet execution config-uration. While a weblet can be platform independent (e.g.,Java or .Net bytecode or Python script) or platform depen-dent (native code), its execution location is transparent –itcan be run on a mobile device or migrated to the cloud, i.e.,run on one or more nodes offered by an IaaS provider. Thus,an elastic application can augment the capabilities of a mo-bile device including computation power, storage, and net-work bandwidth, with the light of dynamic execution con-figuration according to device’s status including CPU load,memory, battery level, network connection quality, and userpreferences. This paper presents the motivation behind de-veloping elastic applications and their architecture includingtypical elasticity patterns and cost models that are applied todetermine the elasticity patterns. We implement a referencearchitecture and develop a set of elastic applications to val-idate the augmentation capabilities for smartphone devices.We demonstrate promising results of the proposed applica-tion model using data collected from one of our exampleelastic applications.

Keywords elastic application· cloud computing· mobiledevice· weblet· dynamic execution configuration

X. Zhang, Huawei Research Center, Santa Clara, CA, USA, xin-wen.zhang@huawei.com· A. Kunjithapatham and S. Gibbs, SamsungInformation Systems America, San Jose, CA, USA,{anugeetha.k,s.gibbs}@samsung.com· S. Jeong, member of IEEE, sango-hjeong@gmail.com

1 Introduction

Applications on smartphones traditionally are constrainedby limited resources such as low CPU frequency, smallmemory, and a battery-powered computing environment.For example, the iPhone 3G is equipped with 412MHz CPU,512MB RAM, and a battery allowing about 5 hours of talk-ing time. The new Samsung Galaxy Android phone has528MHz CPU, 128MB RAM, and battery offering about 6.5hours of talk time. Both devices have up to 7.2 Mbps 3G datanetwork connection. Compared to today’s PC and serverplatforms, these devices still cannot run compute-intensiveapplications such as complex media processing, search, andlarge-scale data management and mining.

Cloud computing delivers new computing models forboth service providers and individual consumers includ-ing infrastructure-as-a-service (IaaS), platform-as-a-service(PaaS), and software-as-a-service (SaaS), which enablenovel IT business models such as resource-on-demand, pay-as-you-go, and utility-computing [7]. From the perspectiveof service providers, cloud computing is often viewed as avast and scalable platform for service delivery. We suggestanew perspective, one tuned to the needs of mobile devices.We consider cloud computing as a means to extend or aug-ment the capabilities of resource constrained devices.

There are several approaches to realize this perspective.One approach is to duplicate the runtime environment of thedevice in the cloud and then run the application either on thedevice or in the cloud. The off-device runtime environmentis sometimes called a “surrogate” [19], a “clone” [10], or acloudlet [24]. Virtual machine technology is often used tohost and isolate the off-device runtime so making this ap-proach fit well with emerging IaaS platforms such as Ama-zon EC2 [1]. Running a device clone in the cloud has someattractive properties such as enhanced CPU and memory re-sources which lead to better performance. Furthermore, ap-

2

plications do not need any modification – the clone and thephysical device can run identical binaries. However, this ap-proach has disadvantages too. First, the application on theclone may need to access the physical hardware on the de-vice. For example, consider a GPS application or simply thequestion of how an application running in the clone inter-acts with the user. It is certainly possible to transfer deviceI/O between the device and clone environment over the net-work, but this may impact responsiveness and battery use.Secondly, simply replacing one processor with another failsto take full advantage of cloud compute resources. Ideally,acloud application should be able to run in a highly parallelfashion distributed over many cloud nodes. Thirdly, com-pletely duplicating a device and running it on the cloud in-creases the complexity of device management. For example,the cloud system needs similar security protection and dataprivacy control as those on the device since it runs all possi-ble applications with data from the original device.

The above considerations lead us to focus on applica-tion level augmentation instead of cloning a complete de-vice environment. Often these applications are data-parallelwith high compute-to-communication ratio. Examples in-clude media processing, search, and data mining. Our goalis to design an architecture and related middleware to enableelastic applicationswhich consist of multiple componentscalledweblets, each of which can be launched on a mobiledevice or in the cloud. The decision of where to launch aweblet is based on application configuration and/or the sta-tus of the device such as its CPU load and battery level.Ideally the application model could also support migrationof weblets between the device and cloud platform duringruntime. While offloading and delegating computing havebeen proposed by many researchers [12,9,19,15], the nov-elty of our approach lies in enabling flexible and optimizedelasticity by considering multiple factors including devicestatus, cloud status, application performance measures, anduser preferences (e.g., different running modes of an appli-cation including power-saving mode, high speed mode, lowcost mode, offline mode, or in terms of expected applicationspecific modes).

To enable this new application model, many challengesexist in different areas, including management of heteroge-neous computing environments, data management and com-munication dependencies between weblets, state synchro-nization between weblets, and cost-effective dynamic ex-ecution configuration. The middleware should provide in-frastructure for seamless and transparent execution of elas-tic applications and offer convenient development support.This paper first gives the concepts and typical elasticity pat-terns (Section 2). We then focus on the optimization of cost-effective execution configuration by considering multiplefac-tors (Section 3), which we believe is one of the most criticaland unique components of the application model. We then

present a high-level description of an implemented refer-ence framework including deployment and runtime archi-tecture and software development kit (SDK) (Section 4).We then illustrate a set of example elastic applications de-veloped based on our reference architecture and cloud plat-form (Section 5). We show some experimental results whichconfirm the augmentation capabilities of our approach withcollected data from an elastic image processing application(Section 6). We present some related work and oversee fur-ther research themes along this novel application model atthe end of this paper (Section 7 and 8).

2 Concepts & Elasticity Patterns

2.1 Concepts and Benefits

We define elastic applications as having two properties. First,following the client/server split of traditional web applica-tions, an elastic application is split or partitioned so that ex-ecution occurs partially on the device and partially on thecloud. Previous work has proposed many mechanisms forsplitting an application into modular components for remoteexecution orcyber foragingpurposes, such as [8,9,12,15,22,26]. For elastic devices we assume application develop-ers can determine how to organize weblets based on theirfunctionalities and runtime behaviors such as computationdemand, data dependency, and communication need, whichwe believe should be part of high-level design considerationof an application. Elastic middleware should provide neces-sary SDK and tools allowing developers to implement andtest their designs. A unique requirement for elastic applica-tions is that a weblet’s functionality should not be affectedby the location or environment where it is running. Essen-tially, the location of individual weblets should be transpar-ent to users. One principle for partitioning applications isthat each weblet should have minimum dependency on oth-ers. This is not only for robustness but decreases communi-cation overhead between weblets during runtime.

Second, theexecution configurationof an elastic appli-cation is not static, instead it is determined when the appli-cation is launched and potentially modified during runtime.By execution configuration, we mean the assignment of ap-plication partitions to execution units (e.g., cores or virtualmachines), either on the device or in the cloud. The left handside of Figure 1 shows some possible execution configura-tions for an application using three weblets.

There are several benefits that the elastic application con-cept offers to mobile users and application developers de-riving from coarse-grained application partitioning and dy-namic configuration. First, elastic applications are not con-strained by the compute capabilities of today’s mobile plat-forms and can be configured to take advantage of multiple

3

Elastic App

Device

Cloud

ReplicationPattern

Weblet1

Weblet3

Weblet2

Elastic App

DeviceCloud

Splitter

SplitterPattern

Weblet1

Weblet3

Weblet2Elastic App

Device Cloud

AggregatorPattern

Aggregator

Weblet

Weblet

Weblet

Elastic App

Device

Cloud

Elastic App

Device

Elastic App

Device Cloud

Weblet

Weblet

Elasticity Patterns

Weblet

Weblet

Weblet

Weblet

Cloud

Weblet

Weblet

Weblet

Execution ConfigurationsHTTP request

Weblet push

HTTP request

Weblet push

Fig. 1: Execution configurations and elasticity patterns.

processing cores when available. If more compute (or stor-age) is needed then this can be obtained from the cloud. Asdevices become more powerful, compute and storage canshift back to the device. On the other hand, mobile devicecompute and storage need not be designed to satisfy themost demanding applications. Device resources can be mod-est (and less power consuming) since the more demandingapplications can acquire resources from the cloud. From aperformance perspective, the ability to allocate resources inthe cloud and migrate functionality gives the device greatflexibility. For example, performance can be increased oroptimized to fit various goals (such as responsiveness, mon-etary cost, or power consumption). Furthermore, applicationcomponents that are partitioned for migration can also bereplicated. The failure then of one instance of a replicatedcomponent need not compromise the application. Also, theelastic application model offers a testbed for future tech-nologies of mobile devices. Applications that run on thecloud today can move to the device in future products. Thisgreatly extends the lifetime of applications and reduces de-velopment costs.

2.2 Elasticity Patterns

We now consider elastic applications and weblets in moredetail. Our motivation for using weblets is that developersare familiar with the web application model and so can eas-ily transition from the client/server partitioning of web ap-plications to the more general form of partitioning foundin elastic applications. Furthermore, programming methodsused for web applications, for example AJAX and REST, areadapted by weblets. To see the similarities and differencesofweb applications and elastic applications, it is interesting tocompare weblets with traditional web services. We highlightsome areas for comparison in Table 1.

In designing a web application, a key issue is determin-ing what logic will run on the server and what on the client.For early web sites, the client was mainly used for renderingand input, but now with JavaScript, AJAX, and plug-ins suchas Flash and Silverlight, many tasks can be performed by theclient. With elastic applications there is a similar issue,butbecause several weblets can be created by a single applica-tion, the topology of elastic applications is more varied. Itappears these topologies fall into some common patterns,what we callelasticity patterns, several of these are shownon the right hand side of Figure 1 and briefly summarized asfollows.

4

Table 1: Weblets vs. Web Services

Weblets Web Services

HTTP (REST interface) HTTP (REST or SOAP interface)single client many clientsclient is application root or other weblet clients are generally browsers or other web servicesshort-lived & long-lived requests generally short-lived requestsdynamic endpoints (may migrate) fixed endpointslifetime is client dependent lifetime is client independentruns on servers or client (cloud or device) runs on serverspush to client possible not available or non-standard

Replication Patterns: Pools and ShadowingWeblet repli-cation refers to running multiple weblets with the same in-terface, i.e., accepting the same types of request. There aretwo forms of replication:poolsandshadowing. Weblet poolsallow an application to leverage cloud CPU cycles and aug-ment its throughput. With this pattern, the application issuesrequests that are routed to weblets as they become available.Weblet pools are well suited for applications that are eas-ily divided into similar tasks, for example processing setsof images or scanning sets of files. Closely related to poolsis shadowing in which the same request is sent to a set ofreplicated weblets in parallel. Shadowing can be used forfault tolerance and latency control. For example, shadowinga weblet on the device with a copy on the cloud can helpthe application recover from loss of network connectivity orloss of battery power. Shadowing can also enable more flex-ible latency control for an application, e.g., the device canuse the earliest response from multiple shadowed webletson the cloud.

Splitter Pattern With the splitter pattern, a set of workerweblets perform variant implementations of a shared inter-face. For example, the workers may encapsulate adapters toaccess different social networks, or codecs to process dif-ferent media formats. The application is decoupled from thevarious implementations by a splitter weblet that routes re-quests to appropriate workers. This pattern increases appli-cation extensibility since new worker weblets are added with-out changing the application structure. Splitting can alsoen-hance the user experience by converging multiple serviceson a single device. For instance, in the case where the workerweblets access different social networks, the splitter weblet’sinterface provides a unified or converged interface to a rangeof social networking services.

Aggregator Pattern An elastic application can also ag-gregate computations from multiple worker weblets. In thispattern, an aggregator weblet collects information from mul-tiple worker weblets and usesweblet pushto relay this in-formation to the device. For example, an application canrun multiple weblets in the cloud as background threads thatmonitor the user’s web accounts (e.g., emails or instant mes-sages), the aggregator weblet pushes events (such as account

activity) to the device. In some cases the splitter and aggre-gator patterns are combined or overlaid, the splitter pushesrequests to the workers while the aggregator pushes eventsback to the device.

3 Cost Optimization for Elastic Applications

3.1 Cost Model

The augmented computation of an elastic application is notfree but introduces costs to the mobile device and user, whichdepends on when and where a weblet is running and com-munications within weblets or between weblets and Internet.Furthermore, elastic applications can exhibit variant runtimebehaviors with dynamic execution configurations, such aspower consumption, monetary consummation, applicationperformance, and even security and privacy properties. There-fore, the dynamic execution configuration of an elastic ap-plication is decided based on some cost saving objectives,which form a cost model in our framework. As Figure 2shows, the cost model takes inputs of sensor data from bothdevice and cloud sides, and runs optimizing algorithms todecide execution configuration of applications. Device andcloud related data such as battery level, network conditions,device loads, cloud loads and other performance data includ-ing current latency of the application, are obtained from ap-propriate sensing modules. The output of the cost model ispossible actions that lead to the optimal execution config-uration for the application, such as allocating resources onthe cloud, launching/migrating weblets on/to device and/orcloud, selecting/switching between different network inter-faces, replicating and shadowing weblets on cloud, etc.

An important part of the cost model is choosing the at-tributes or objectives that should be optimized. We considerthe following four attributes in our current elastic applica-tion framework, while we believe new cost objectives canbe integrated easily.

Power Consumption Each application/weblet running ona mobile device consumes battery power by using CPU cy-cles, memory and radio module for communication with peerweblets on the cloud and/or external web services. The power

5

Cost Model

�������������

�����������

UI3G

Cloud

Device

WiFi

3) Replication �������

��

�

��

Goal (examples)Minimize costMaximize performanceMinimize powerMaximize robustnessMaximize security

ConstraintsResourcesCost modelApplicationRequirements

battery level

device loads

cloud loads

Performance

Weblet pool

1) Allocation & migration

2) Connection selection &switching

4) Shadowing

������

W

Connectionquality

……

Fig. 2: Cost model of elastic applications.

consumption of a weblet on the device heavily depends onthe I/O operations it performs [28,5,4]. In addition, differentcommunication channels, such as W-CDMA, WiFi (802.11)etc., consume different power [2,6,3]. Considering the above,it is evident that although launching/migrating weblets toclouds should ideally save power consumption of compu-tation on the device, the power consumption of network in-terfaces may override the benefits of the migration.

Monetary Cost Execution of a weblet on a cloud platformmay involve a monetary cost for the application user, basedon the exact resources consumed on the platform. Usually,a commercial cloud service provider measures the cost of acomputing task based on the amount of CPU cycles, stor-age, and communication traffic (in and out) of a cloud plat-form [1]. The monetary cost of a weblet running on thecloud platform is determined by the size of the input dataconsumed by the weblet (including those from peer webletson the device for the same application and external webservices), total execution time of the weblet on the cloudplatform, data size/rate for intra-cloud communication be-tween this weblet and others within the same cloud serviceprovider (if applicable), and any other attributes that affectthese parameters, such as network status affecting data trans-mission rate.

Performance Attributes As an elastic application poten-tially runs across different platforms, latency is an importantdesign consideration. There are different aspects of latency,such as impact on the user experience when using the ap-plication’s UI and network latency with different networkconnections and traffic status, and the application latencyto finish a particular computing task. Throughput also canbe an important objective for some applications. For exam-ple, an application that does image analysis to find similarpictures from a large database needs maximum throughput.To achieve this, the heavy computing tasks are launchedor migrated to the cloud, although there is a tradeoff be-tween doing this and the data communication overhead: toomuch communication may slow down the overall applica-tion throughput. Given this, building a good performancemodel is more challenging than power and monetary as-

pects. In general, to optimize latency, throughput and someapplication-specific options, CPU cycles and memory usedby the weblets, along with the available network bandwidthfor communication between the device and the cloud shouldbe carefully evaluated.

Security and Privacy Security is increasingly concernedin web-based computing systems. A mobile device poten-tially contains many user secrets and privacy-sensitive data,such as: contacts, SIM information, credit card details andmany other credentials that may be needed to consume webservices. Naturally, a mobile user may trust her device morethan the cloud platform which is controlled by a third-partyservice provider. As launching or migrating a weblet to thecloud may also require offloading user data to the cloud, theuser security and privacy concerns are even higher with anelastic mobile device. A weblet on the device or the cloudmay need to access external web services on behalf of theuser. For cost modeling purposes, we need to evaluate if aweblet requires any user data and if the user has strong con-cerns about offloading such data to the cloud. If the user hasconcerns over doing this, the weblet that requires this datashould be launched on the device only and never migrated.Furthermore, during runtime, if a weblet needs to acquireexternal user data from other web services, which usually re-quires user credentials (username/password, public key cer-tificate, or any other security credentials), the weblet mayhave to be migrated back to the device.

3.2 Optimizing Execution Configuration

Once a cost model is developed for a particular applica-tion, a mechanism is needed for efficient and intelligent dy-namic execution configuration, e.g., via some lightweightmachine learning algorithms at the device side. In our imple-mentation of one elastic application, we use Naı̈ve BayesianLearning techniques to find the optimal weblet configura-tion (# of weblets on device and cloud), given device status(in terms of CPU, memory and network consumption), userpreference (in terms of expected # of images that should beconcurrently processed), and history data of the application.

As Figure 3 shows, a vector ‘x’ consists of values rep-resenting device status components such as the upload band-width, throughput, power level, memory usage and file cache.A vector ‘z’ consists of values representing user’s preferredsetting for cost objectives including monetary cost, powerconsumption, and processing speed. The configuration vari-able ‘y’ has values from 1 toN (max number of possibleconfigurations), where each value maps to a specific config-uration pair. Given all these data, the following expressioncan be applied to determine the most optimal configuration.

6

y∗ = argmaxy

p(y)

L∏

i=1

p(xi|y)

M∏

j=1

p(zj |y) (1)

In the above expression,xi is the i-th status compo-nent value that can have different number of states for eachcomponent andzj is a j-th preference component, wherei ∈ {1, 2, · · · , L} andj ∈ {1, 2, · · · ,M}, with L andMrepresenting the number of components in the status vectorand the number of components in the preference vector, re-spectively.

Training set

2),,( yzx Supervised Learning

Classifier

Offline computation

PowerSpeed Expense

zx y

1),,( yzxLog data

ny),,( zx…

x

y

Cloud …

1z 2z 3z 4z Mz

Fig. 3: Weblet scheduling through Machine Learning tech-niques.

Note that it is relatively easy to determine dynamic con-figurations in this application since it has only one type ofweblet. For a general application with multiple types of we-blets, each having different runtime behaviors, the optimiza-tion can be very complex and the computation itself mayoverride the cost savings. Considering that an elastic appli-cation can be installed and executed by many users on sim-ilar devices, a service-oriented cost optimization implemen-tation can save computation cost for the device.

4 Reference Implementation

4.1 Reference Architecture

To experiment with this new application model, we have de-veloped a reference framework including application bun-dle, architecture, and some example elastic applications.Ourframework works with Amazon EC2 and S3. Figure 4 showsthe main functional components.

In our current framework design, a typical elastic ap-plication consists of a UI component, one or more weblets,and a manifest. Weblets are autonomous software entitiesthat run either on the device or cloud and expose RESTfulweb service interfaces via HTTP. The manifest is a staticXML file that contains metadata for the application. It could

be used to specify any requirements and constraints for theapplication and the individual weblets, such as: the digitalsignature needed to download/migrate the weblets, require-ments for compute power, network and storage, time limitsfor weblet execution, maximum instances of the weblet thatcan be launched on the device and the cloud, if a weblet canbe launched/migrated to the cloud and specifics about han-dling data required/generated by the application/webletsetc.

On the device side, the key component is the deviceelasticity manager (DEM) which is responsible for config-uring applications at launch time and making configurationchanges during run time. The configuration of an applica-tion includes: where the application’s components (weblets)are located, whether or not components are replicated orshadowed (e.g., for reliability purposes), and the selectionof paths used for communication with weblets (e.g., WiFi or3G if such a choice exists). The router passes requests fromUI components to weblets. It insulates the UI logic fromweblet location. When a weblet is migrated, the router willbe aware of the new location and will continue passing re-quests from the UI to the weblet (and passing replies backto the UI). Each device also provides sensing data from thedevice such as processor type, utilization, and battery state.This data is made available to the elasticity manager and isused to determine when and where a new weblet instanceshould be launched.

Sensing

Device Elasticity Manager

Elastic Layer http

Router

UI Container

ApplicationStore

Application Installation

Elastic Device

Cloud Fabric

Interface

manifest weblet1

weblet 2

UI

Elastic

Application

CloudManager

NodeManager

CloudSensing

Application Manager

WebletContainer

WebletContainer

IaaS/PaaS

Cloud Elasticity Service

Weblet2

AppRoot

Weblet1

HTTP(s)

HTTP(s)

Fig. 4: Reference architecture for elastic application.

The cloud elasticity service (CES) consists of the cloudmanager, application manager, and sensing information col-lection. The cloud manager is responsible for allocating re-sources from, and releasing to, underlying cloud nodes. Itmaintains usage information, including compute, bandwidthand storage, for the various weblets running on the cloud.The application manager provides functions to install andmaintain applications on behalf of elastic devices, and helpslaunch weblets on different cloud nodes. Sensing informa-

7

Running

Paused TerminatedDie

Resume after migrate(from saved state)

AppRoot

Create Send ReplySend

Request

Die

Pause for migrate(save state)

Fig. 5: Lifecycle of a weblet. A weblet is always created bytheAppRoot, and can be in state ofRunning, Paused,or Terminated.

tion refers to the collection of operational data on the cloudplatform. These data are made available to the cloud man-ager to assist it in tracking usage. In addition to applicationperformance data, sensing may collect information on cloudarchitecture, failures of various forms, and resource avail-ability. As a service provider, the CES exports a web service,referred to as the cloud fabric interface (CFI) to elastic de-vices and applications. A node manager on each cloud nodeoversees resources associated with a particular node (server)within the cloud. It communicates directly with the cloudmanager and application manager. Each node runs one ormore weblet containers which are the weblet runtime envi-ronments hosted on an Amazon EC2 instance.

4.2 SDK Development

We have implemented a preliminary SDK based on the ref-erence architecture, which is used to develop the basic in-terfaces of weblets in our example applications. Using thisSDK as a base, developers can build elastic applications inhigh-level languages such as JavaScript, Java, and C#. Cur-rently the SDK has C# bindings; however it is easy to extendit to other languages.

A typical elastic application includes aAppRoot com-ponent and one or more weblets. TheAppRoot is the partof the application that provides the user interface and is-sues requests to weblets. All of these are packaged into onebundle, which includes the binaries of weblets and a man-ifest describing the application, and most importantly, thedeveloper-signed hash values of the individual weblets. Fig-ure 5 shows a state diagram illustrating the lifecycle of aweblet, including the various states that a weblet can be inand the actions that cause the state transitions. A weblet isan independent functional unit of an application that is ca-pable of compute, storage, and networking tasks. It resem-

bles an embedded or dedicated web server and presents aweb service interface (i.e., it is accessed via HTTP). In ourSDK, an abstract class calledAbstractWeblet is de-fined to represent the core behavior of weblets. Other spe-cific types of weblets can be implemented as subclasses ofAbstractWebletand extend its methods as required. Eachweblet is associated with a weblet type and identified througha unique id. Once an application has defined one or moreweblet types, it can use the DEM to create instances (i.e., tocreate specific weblets) and issues requests to these weblets.We describe below the core interfaces supported by DEMand illustrate how to create and communicate with a weblet.

Create a weblet: In order to create a weblet, two param-eters are required including: the type of the weblet and acall back function to invoke when the weblet is created.For example, the following code creates a weblet of typeMyWebletType:

CreateWeblet("MyWebletType",

OnCreateMyWeblet);

Send a request to a weblet: A request can be sent to a webletusing theSendWebletRequest interface. The interfacerequires the following parameters: the weblet to which therequest is to be sent, the actual request (query string) to besent, and a callback function that is invoked when a reply isreceived. Below is sample code to achieve this:

SendWebletRequest(w, "RequestQuery",

OnMyWebletReply);

Receive a response from a weblet: When the DEM receivesa response from a weblet it invokes the callback functionindicated by the requestor along with request. With this, therequestor only needs to implement the call back functionto receive the reply. For example, in continuation with theexample given above, the DEM would invoke the followingfunction to convey the reply to the application:

OnMyWebletReply(w, reply);

The DEM can decide to migrate a running weblet fromthe device to the cloud or vice-versa; weblet migration istransparent to the application. When a weblet is running ondevice and the DEM decides to migrate it to a cloud node,the DEM issues aPause request to the weblet, this causesthe weblet to close its request interface, release resourcesand save state. The DEM then sends the saved state to thecloud via the CFI. After the state has been transferred tothe cloud, the weblet is resumed and restores itself from thesaved state. The CFI returns the new connection informationfor the weblet (e.g., IP address, port, and session tokens) tothe DEM so that the DEM may continue to route requests tothe weblet on cloud.

8

5 Elastic Applications

To demonstrate the elastic application model, we have de-veloped several applications with our SDK and deployed onthe reference architecture with Amazon EC2. This sectionexplains the design and elasticity patterns of these sampleapplications, aiming to provide the abstract principle of de-signing elastic applications in general.

5.1 Elastic Image Processing

The simplest is an image processing application in whichvarious filtering operations are applied to set of images. Fol-lowing the replication pattern, a weblet pool is created on thecloud; images are then processed in parallel by pool mem-bers. The application can adjust the size of the pool, so itis possible to compare throughputs for different executionconfigurations. The application supports 3 workloads (num-ber of images to process). Load 1 has 1 image, load 2 has4 images, and load 3 has 16 images. The images are 24-bitcolor images of size 240 x 360. Figure 6 shows a snapshotwhen the application is running on a Samsung Galaxy smartphone with Android 1.6.

Fig. 6: Snapshot of elastic image processing application.

The application implements many of the elastic applica-tion concepts described in the previous sections and enablesthe user to do the following through the UI: (1) Specify ifthe device is online (i.e., if it should make use of the cloudto run weblets); (2) specify the number of weblets to run onthe cloud; (3) specify the kind of filtering to be done on theimages; and (4) specify the load or the number of images toprocess concurrently.

This image processing application consists of only onetype of weblet (ImageWeblet), as shown in Figure 7. Itsfunctionality is to perform image filtering as specified by the

ElasticIP App

ImageWeblet 1

ImageWeblet n

ImageWeblet 2

…

ImageWeblet

App on Device (Analysis & Filtering of

images)

Fig. 7: Weblet topology of elastic image processing.

user. The weblet is replicated on the device and the cloud,as and when required. The total number of weblet instancesspawned depends on the load specified and the user specifiedvalue for number of weblets in the cloud.

5.2 Elastic Augmented Reality: Object Identification andReplacement

A second example is a form of augmented reality (AR) inwhich real-world objects are detected and enhanced. Thisapplication runs tracking and rendering on the device anduses the splitter pattern with a set of matcher weblets onthe cloud. Each matcher searches for different objects withinvideo frames. The splitter collects information on identifiedobjects and relays this to the device for rendering. By run-ning the matchers in the cloud, many more objects can bedetected (per unit time) than when the application runs fullyon the device.

A snapshot of this application is shown in Figure 8. Ona high level, the application works as follows. First, the im-age/video frame from the mobile device camera is captured,and the feature points for the image in the frame are ex-tracted. With these feature points, planar objects are thenidentified, by matching the extracted feature points to thoseof known planar objects in a database. The recognized pla-nar object is then used to select a replacement image in theuser’s choice of language. Finally, the replacement image isprovided to the device and is overlaid on top of the currentimage. For this scenario, the users are able to specify thelanguage of choice for the user and the number of webletsto run on the cloud through the UI. This augmented realityapplication would consist of three types of weblets, as illus-trated in Figure 9: The first type of weblet (Tracker) per-forms feature extraction on the live feed; the second type ofweblet (Matcher) matches extracted features with imagesin a database. As this is a compute-intensive task, multipleinstances of this weblet type are spawned on the cloud; andthe third type of weblet (Compositor) performs the imagereplacements on the device.

9

Fig. 8: Snapshot of elastic AR: object identification and re-placement.

ElasticAR App

Splitter

Matcher 1

Matcher n

Matcher 2 …

Tracker

Camera

App on Device (Identify, track &

replace “target” images)

Compositor

Fig. 9: Weblet topology of elastic AR: object identificationand replacement.

5.3 Elastic Augmented Reality: Augmented Video

Our third sample application is another elastic AR applica-tion which enables an augmented video scenario, where ina user visiting a building (e.g., a technology expo or a mu-seum) is able to seamlessly access information about pointsof interest (POIs)/demos in the area. When the user holds uphis phone camera, information about points of interest in thearea (title, description of demos and the number of people inthe demo area) is overlaid on the camera view, representedusing different types of icons and labels.

Figure 10 shows the snapshot of the application whenrunning on Samsung Galaxy. When running, the applica-tion obtains the accelerometer, compass and GPS readingsfrom the phone thus the current position and direction ofthe user are identified. The application then obtains a listof POIs/demos in the target area by submitting its locationinformation to a web service interface running on cloud.The web service also collects the number of people neareach POI, which would be done periodically by monitoringthe location/coordinates of people in the target area throughtheir devices; After these, the POIs near the user’s positionand within the camera’s field of view are determined, and the

Fig. 10: Snapshot of elastic AR: augmented video

ElasticAR App

PoiMonitor Crowd

Monitor

Crowd Monitor

Crowd Monitor …

UserTracker

Camera

App on Device (Display points of interest, based on user’s position). replace “target” images)

PoiFilter

Compositor

Fig. 11: Weblet topology of elastic AR: augmented video.

POIs and information about the number of people in theirproximity are overlaid on the user’s screen.

Figure 11 shows the weblet topology of this application,which consists of four types of weblets. The first type ofweblet (UserTracker) identifies the position and direc-tion of the user. The second type of weblet (PoiMonitorandCrowdMonitor) collects device information and cal-culates the number of people near the POIs. Multiple in-stances of this weblet type are spawned on the cloud. Thethird type of weblet (PoiFilter) determines the POIs inthe user’s vicinity and field of camera view. The fourth typeof weblet (Compositor) overlays the information aboutthe POIs on the device’s screen.

6 Experimental Validation

We validate the elasticity of our framework by using theaforementioned image processing application as benchmark.This application consists of only one type of weblet calledImageWeblet. Its functionality is to perform image fil-tering with an algorithm specified by the user. The webletis replicated on the device and the cloud, as and when re-quired. The total number of weblet instances spawned de-pends on application load and the number of weblets in the

10

Non-Elastic App

CFI

Monitor AppMonitor App

…

Node 1Controller

DEMDEM

ImageWeblet

ImageWebletImageWeblet

ImageWeblet

ImageWeblet

ImageWeblet

ImageWeblet

Elastic App

Node mController

Fig. 12: Experiment configuration for elastic image processing application.

cloud, both specified by the user. The application UI enablesthe user to do the following configurations during runtime:online (can launch weblet at cloud) or offline (all weblets arerunning on the device) mode of the application, number ofweblets to run on the cloud (if in online mode), the filteringalgorithm to be used, and the number of images (workload)to process at the same time. The images used in by the ex-periment are 24-bit color with size 240 x 360.

The goal of our validation is to compare the performanceof an elastic device (ED) and a non-elastic device (NED)running the same image processing application. Figure 12shows an overview of the demo configuration and systemsetup. For the elastic device, the application uses an in-housecloud comprising of 8 Linux boxes. A non-elastic versionof the application is also running independently in orderto compare it with the elastic version. Essentially, the non-elastic version uses only the device to run weblets, whereasthe elastic version uses both the device and the in-housecloud. The setup also includes PCs to host the CFI and a per-formance monitor application. The CFI is implemented withPHP scripts on a Linux server with Apache and MySQL.

The performance monitor collects several measurements,including the available upload/download bandwidth (KB/sec),application workload (number of images to be processed)and throughput (the number of image tiles processed/sec),average CPU usage (%), and available memory (MB), fromthe test device and from the cloud. In addition, it also main-tains information about the total number of weblets startedfor the application and the individual number of weblets run-ning on the device and the cloud.

Each configuration has a unique composition of deviceweblets and cloud weblets. We set the maximum numberof weblets as 16 and consequently, more than 100 differentconfigurations are possible. The configuration specifying 1device weblet & 0 cloud weblets is considered the defaultconfiguration for the non-elastic device. Among all possi-ble configurations, we chose the 74 configurations where thenumber of device weblets is less than or equal to 4 (due tolimitations with CPU utilization) for analysis. For each con-

figuration, the data was collected 20 times and the averagevalues were considered for final comparisons.

0

5

10

15

20

25

30

35

40

45

50

Ave

rage

Thr

ough

put (

tiles

/sec

)

Configurations = (# of Device Weblets, # of Cloud Weblets)

(0,16)(0,8)

(0,1)

(1,15)(2,14)

(3,13)

(4,12)

(1,0) (2,0) (3,0) (4,0)

(1,7)

(2,7)(3,6)

(4,6)NED

Fig. 13: Throughputs vs. configurations

0

20

40

60

80

100

Ave

rage

CP

U u

sage

(%

)

(4,4)(3,13)(2,6)

(1,8)

(4,0)(3,0)(2,0)

(4,12)(3,1)

(2,14)(1,15)

(0,1)

(0,8)(0,16)

Configurations = (# of Device Weblets, # of Cloud Weblets)(1,0)

NED

Fig. 14: CPU usage vs. configurations

Figure 13 shows the performance of the elastic deviceover 74 configurations. In comparison with the throughputof about 6 tiles/sec for the default/non-elastic device config-uration (1 device weblet, 0 cloud weblets), the throughputsof all other configurations are better. We can observe that thethroughput for the configuration with 0 device weblet and 16

11

Fig. 15: Available memory vs. configurations

cloud weblets has the highest throughput among the 74 con-figurations tested. The configuration with 16 device webletshas the best performance, as there are a total of 16 imagesin load 3. A surprising observation is that the configurationwith 8 weblets performed better than configurations with 9-15 weblets (a result of internal application logic). This in-dicates that an intelligent weblet scheduling is essentialtoidentify the most efficient weblet configuration.

CPU usage is more predictable overall, in that more de-vice weblets lead to more CPU usage. However, the trendis interesting when comparing the number of device we-blets. For configurations with up to 2 device weblets, run-ning more cloud weblets leads to more CPU usage. For con-figurations with 3 and 4 device weblets, a general trend isthat running more cloud weblets reduces the CPU usage. Bycombining CPU usage data in Figure 14 with the through-put data in Figure 13, we are able to identify the config-urations that lead to low CPU usage and high throughput:for instance, configurations (0,2), (0,3) and (0,4) have lowerCPU usage (than that of a non-elastic device) and higherthroughput. This results in more available CPU cycles forother applications and improves multi-tasking capabilities.

Figure 15 shows interesting but not easily comprehensi-ble results regarding the available memory versus configura-tions. Certain configuration such as (0,1), (0,2), (0,3), (1,0),(1,1), (1,2), (2,0), (2,1), (2,2), (3,0), (3,1), and (4,0) havemuch available memory. Most of the configurations haveonly up to 4 total weblets and using only the device we-blets consumed only a little memory up to 4 device weblets.Meanwhile, other configurations up to (3, 13) have similaravailable memory, but there is significant variation between(4,1) and (4,12). It is not clear why the system behaves thatway, but it could be related to cache operations and mem-ory paginations. This will need further investigations. Com-bining this result with Figure 13 can lead to a memory-constrained optimal configuration. Of course, it would alsobe conceivable to find a good configuration constrained onboth memory and CPU.

7 Related Work

7.1 Execution offloading

The elastic model builds on previous work in the areas ofremote execution and application offloading. Cyber forag-ing [26,9,8,19] is a common approach explored by many toaugment the capability of resource-constrained mobile de-vices. The basic idea is to dynamically discover and makeuse of nearby resources, aka surrogates, to offload the exe-cution of an application or parts of an application runningon a mobile device. Compared to these approaches, elasticapplication model has more flexible deployment patterns toparallelize tasks on multiple remote cores.

CloneCloud takes the approach of cloning the entireuser’s mobile device environment on a remote server. Appli-cations can then be quickly restarted on or migrated to theremote machine when the user’s machine is running low onresources [10]. Similar virtual machine-based approach isused by cloudlet [24]. As mentioned in Section 1, our elas-tic application model offloads computing tasks in more fine-grained level such that it leverages the parallel computingadvantage of cloud resources.

Some research work extend existing programming lan-guage and application runtime middleware to transform ap-plications into distributed systems [12,15,22]. AdaptiveOf-floading [12] leverages Java’s object oriented design to iden-tify possible partitions for a Java application and modifiedthe JVM to support such partitioning. Coign [15] makes useof the location transparency supported by COM and con-verts an application built from COM components into a dis-tributable application. R-OSGi [22] extends the centralizedmodule management functionality supported by the OSGispecification to enable an OSGi application to be transpar-ently distributed across multiple machines. The main limi-tation with these approaches is that they are tied to one par-ticular language or specification and hence not suitable forawide range of applications. Compared to these approaches,our proposed elastic application model is programming lan-guage independent, and can be extended to many existingapplication middleware.

Virtual machine migration [20,27] and VM-basedcloudlet [24] are complementary approaches to enable usersto seamlessly access their applications and data across mul-tiple and heterogeneous devices in general. It also enablesusers to instantly continue/restore an application on a dif-ferent device, when their current machine is running low onresources.

7.2 Cost-aware configuration

There have been literatures dealing with configuration meth-ods based on resource estimation. In [18,25], a resource-

12

aware configuration method decides the configuration basedon user’s quality of service requirement, resource and ser-vice availability, and application fidelity as a function ofre-sources. It tries to maximize a product-based utility func-tion so that the aggregate resource demand cannot exceedthe resource supply. A machine learning approach is intro-duced in [33] to capture the complex nonlinear relationshipbetween resource properties and computing power. It pro-vides resource selection for a job in Grid scheduling to havethe maximum utility of CPU. However, these works are notspecifically targeted for remote execution on mobile devices.The tactics-based remote execution in [9] aims to select thebest tactic, the useful knowledge about an application rele-vant to remote execution, using resource prediction and re-source monitoring. It tries to maximize the latency-fidelitymetric in the tactic selection. In [11], a similar work is pro-posed, using a product-based decision criterion for remoteexecution. It considers only three metrics of execution time,energy usage, and fidelity.

Narayanan et al. [21] use historical application loggingdata to predicate the fidelity of an application, which de-cides its resource consumption. However, in this work, onlyaspects of device hardware and application inputs are con-sidered. In our cost model, we consider more comprehen-sive factors not only on device side, but also on cloud side.Uniquely, we incorporates user preferences in terms of costobjectives. Gurun et al. [14] extend the network weather ser-vice (NWS) toolkit in grid computing to predict offloading,which can be leveraged as an implementation mechanismfor our cost model.

In [13], a Fuzzy Control model-based offloading infer-ence engine is introduced to solve when to trigger adap-tive offloading and how to partition an application. How-ever, the decision criterion is based only upon the memory,not considering multiple factors. Our approach provides anoptimized elasticity by considering multiple factors as costs,including device status, Cloud status/usage, applicationper-formance measures, and user preference to the cost factors.

Comparing with these approaches our work is based onthe assumption that cloud has huge resources, thus releas-ing the resource estimation requirement in the cloud fromthe decision of weblet scheduling. There are some litera-tures regarding cost analysis on the cloud side-only. Thetradeoffs between the cloud computing and desktop gridsare provided in [16]. The total cost of ownership and utiliza-tion cost is introduced in [17] to evaluate the economic effi-ciency of the Cloud. A workload balancing approach [31] isproposed between public Cloud and private Cloud for cost-saving. In [29], the monetary cost of leasing CPU time fromcommercial Clouds is compared with that of purchasing andusing a server cluster of equivalent capability.

8 Conclusions and Future Work

We propose an elastic application programming model aim-ing to remove the constraints of specific mobile platformsby providing a distributed framework that extends the de-vice into the cloud. The salient feature of this model is thatit offers a range of elasticity patterns between resource con-strained devices and Internet-based clouds. Each pattern inturn can be realized by several execution configurations. Acomprehensive cost model is used to dynamically adjust ex-ecution configurations thus optimizing application perfor-mance in terms of a set of objectives. We present the highlevel design of elasticity framework and primitive experi-mental results with an example application.

8.1 Future Work

There are aspects of this work that need further research ef-forts. We highlight some of them at the end of this paper.

Data and State Synchronization As aforementioned inthe elasticity patterns, weblets of a single application mayshare application data and state. For example, different we-blets may require the same data from the device for their in-put, or they may update the same data during runtime. Sinceweblets run in different locations, it is desirable to repli-cate data to increase performance, but then data integrity andsynchronization become issues. Alternatively, data synchro-nization can be explicitly performance by applications, orimplicitly by framework architecture and transparent to ap-plications. In the first case, an elastic application handlesits own data management including storage and synchro-nization between device and cloud nodes. The advantageis flexibility: a user or application developer can select thedata storage mechanism on the cloud. However, this leavesdata access handling to developers, and the user may needto manually initiate synchronization during runtime. In thearchitecture-based approach, application data are duplicatedand synchronized by the elasticity architecture, such thattheapplications are not aware of data location. APIs can be de-fined to access (read and write) data via middleware, whichhide the details of data management including synchroniza-tion and backup. This releases the burden of data manage-ment from application developers, while heterogeneous datastorage mechanisms at device and cloud side give challengesto middleware design.

Communication between weblets In our reference archi-tecture, weblet requests are initiated on the device side andcan propagate to the cloud to be passed from one cloud we-blet to another (as in thesplitter pattern). To support moreflexible elasticity patterns, a mechanism is needed to allowa cloud-residing weblet to invoke requests of device we-blets. This problem becomes challenging when the device is

13

mobile, it may switch between different network channels,e.g., between WiFi or 3G network, or even between differentwireless network providers, and it may be running behinda firewall or using NAT. Communication beyond organiza-tion boundaries is another challenging issue to be solved. In-creasingly smartphones run enterprise applications and con-nect to intranet servers. Typically VPN software is installedon these devices. How to enable secure and flexible com-munications between weblets on enterprise-owned mobiledevices and cloud servers needs further research efforts.

Media channel between webletsAlthough HTTP is light-weight and flexible, and is used in our reference architec-ture and example applications, it is not a good option formedia streaming or distributed visual processing betweendevice and cloud. Tasks requiring significant processing ordata storage, such as visual object recognition or renderingcomplex 3D models, can be performed in the cloud ratherthan on the device. However for cloud computing to be usedin highly interactive and visually rich applications, there isa need for a high-speed and low-latency transfer method forstructured visual data between the device and cloud. For ex-ample, consider a 3D game where some scene elements arerendered on the cloud and then sent, along with camera anddepth information, to the device for mixing with locally ren-dered elements. Early work in this direction includes frame-oriented 2D graphics protocols (e.g., RDP, RFB, VNC), pro-tocols for remote rendering of 3D graphics (e.g., X11 exten-sions for OpenGL) and protocols for encoding segmentedvideo (MPEG4). Generally these protocols involve a genericdecoder, i.e., no application-specific logic is required for de-code and display. For situations where application logic issplit between the device and the cloud, and visual process-ing takes place on both sides, new protocols are needed toexchange partially rendered and partially processed data.

Weblet migration Code and computation migration is atraditional problem in many systems [9,30]. To enhance themobile user experience, our model supports migration with-out the need to migrate code. During installation of elas-tic applications, the code used by weblets is installed onboth the device and the cloud. When a weblet is requiredto migrate from device to cloud, a new weblet instance isallocated on a cloud node, and the runtime state is copiedfrom the device weblet to this new weblet. We believe thisstate migration is more efficient than migrating a weblet’smemory image and state information. To support this typeof migration, a weblet is not migrated when in an arbitrarystate. Instead the weblet closes any pending requests andthen saves state information in preparation for transfer. Aftermigration the weblet loads the saved state and resumes itsoperation. With this approach, the specification and repre-sentation of a weblet state are critical. Basically, the state in-formation should include the current task status, its workingdata, and handles to any other weblets with which it com-

municates. The state should also ensure that the physical lo-cation of the new weblet does not affect existing communi-cation channels between other weblets and external parties.For this purpose, a routing-like mechanism should be pro-vided by the architecture and supported by the middleware.A weblet can then have some well-known name for use bythe application, while the binding between the name and aphysical weblet entry point (e.g., a URL) is dynamic.

Trust and security The elastic application model and mid-dleware should provide a mechanism to authenticate we-blets belonging to a single application. Authentication istheprerequisite to building secure communication between we-blets. Also, session management is essential, especially we-blet behaviors at cloud side should be accounted, e.g., togive the mobile user the resource usage and cost of the ap-plication. In our reference architecture, we have designeda lightweight protocol to distribute shared secrets and ses-sion keys between weblets for mutual authentication pur-poses [32]. Beyond this, there are some challenging prob-lems for elastic applications. First of all, a mobile user needstrust to launch weblets on a public cloud, especially whenthe computation and network traffic incur monetary bills tothe user. This demands that the computing environments inthe cloud should be verifiable by a user or a trusted party,e.g., to ensure there is no hidden or even malicious code run-ning beside weblets. Similarly, the quality of service fromcloud providers should be verifiable. Furthermore, a mobileuser should be assured that the weblets running in the cloudare the ones that she has installed and their integrity can beverified via trusted mechanisms. We believe that extendingthe trusted computing base (TCB) of the mobile device tosome necessary but minimum cloud service is necessary tosatisfy these security requirements [23].

References

1. Amazon ec2, http://aws.amazon.com/ec2/.2. Rfmd data sheet, http://www.rfmd.com/databooks.3. Wifi power consumption analysis,

http://nesl.ee.ucla.edu/fw/documents/reports/2007/poweranalysis.pdf.4. Samsung corp., flash/smartmedia/filesystem memory databook,

2000.5. Samsung semiconductor dram products,

http://www.usa.samsungsemi.com/products/family/browse/dram.htm,2001.

6. Analog devices data sheet, analog device inc.,http://www.analog.com/productselection/pdf, 2003.

7. M. Armbrust, A. Fox, R. Griffith, A. D. Joseph, R. H. Katz,A. Konwinski, G. Lee, D. A. Patterson, A. Rabkin, I. Stoica, andM. Zaharia. Above the clouds: A berkeley view of cloud comput-ing. Technical Report UCB/EECS-2009-28, EECS Department,University of California, Berkeley, Feb 2009.

8. R. Balan, J. Flinn, M. Satyanarayanan, S. Sinnamohideen,andH. Yang. The case for cyber foraging. InProc. of the 10th ACMSIGOPS European Workshop, 2002.

9. R. K. Balan, M. Satyanarayanan, S. Park, and T. Okoshi. Tactics-based remote execution for mobile computing. InProc. of The 1st

14

International Conference on Mobile Systems, Applications, andServices, pages 273–286, 2003.

10. B.-G. Chun and P. Maniatis. Augmented smartphone applicationsthrough clone cloud execution. InUSENIX HotOS XII, 2009.

11. J. Flinn, S. Park, and M. Satyanarayanan. Balancing performance,energy, and quality in pervasive computing. InProc. of the Inter-national Conference on Distributed Computing Systems, 2002.

12. X. Gu, A. Messer, I. Greenberg, D. Milojicic, and K. Nahrstedt.Adaptive offloading for pervasive computing.IEEE PervasiveComputing, 3(3), 2004.

13. X. Gu, K. Nahrstedt, A. Messer, I. Greenberg, and D. Milojicic.Adaptive offloading inference for delivering applicationsin per-vasive computing environments. InProc. of IEEE InternationalConference on Pervasive Computing and Communications, 2003.

14. S. Gurun, C. Krintz, and R. Wolski. Nwslite: A light-weight pre-diction utility for mobile devices. InProc. of International Con-ference on Mobile Systems, Applications, and Services, 2004.

15. G. C. Hunt, M. L. Scott, G. C. Hunt, and M. L. Scott. The coignautomatic distributed partitioning system. InProc. of the 3rd Sym-posium on Operating Systems Design and Implementation, pages187–200, 1999.

16. D. Kondo, B. Javadi, P. Malecot, F. Cappello, and D. P. Anderson.Cost-benefit analysis of Cloud computing versus desktop grids. InProc. of the IEEE International Symposium on Parallel & Dis-tributed Processing, 2009.

17. X. Li, Y. Li, T. Liu, J. Qiu, and F. Wang. The method and toolofcost analysis for Cloud computing. InProc. of IEEE InternationalConference on Cloud Computing, 2009.

18. V. Poladian, J. P. Sousa, D. Garlan, and M. Shaw. Dynamic con-figuration of resource-aware services. InProc. of InternationalConference on Software Engineering, 2004.

19. O. R. J. Porras and M. D. Kristensen.Dynamic Resource Man-agement and Cyber Foraging, chapter Middleware for NetworkEccentric and Mobile Applications. Springer Press, 2008.

20. M. Kozuch and M. Satyanarayanan. Internet suspend/resume. InProc. of the 4th IEEE Workshop on Mobile Computing Systemsand Applications, 2002.

21. D. Narayanan, J. Flinn, and M. Satyanarayanan. Using history toimprove mobile application adaptation. InProc. of the 3rd IEEEWorkshop on Mobile Computing Systems and Applications, 2000.

22. J. S. Rellermeyer, G. Alonso, and T. Roscoe. R-osgi: dis-tributed applications through software modularization. In Proc. ofthe ACM/IFIP/USENIX International Conference on Middleware,2007.

23. N. Santos, K. P. Gummadi, and R. Rodrigues. Towards TrustedCloud Computing. InProc. of the Workshop On Hot Topics inCloud Computing, 2009.

24. M. Satyanarayanan, P. Bahl, R. Caceres, and N. Davies. The casefor vm-based cloudlets in mobile computing.IEEE PervasiveComputing, (4), 2009.

25. J. P. Sousa, R. K. Balan, V. Poladian, D. Garlan, and M. Satya-narayanan. User guidance of resource-adaptive systems. InProc.of International Conference on Software and Data Technologies,2008.

26. J. Sousa and D. Garlan. Aura: an architectural frameworkforuser mobility in ubiquitous computing environments. InProc. ofthe 3rd Working IEEE/IFIP Conference on Software Architecture,2002.

27. F. Travostino. Seamless live migration of virtual machines overthe man/wan. InProc. of the ACM/IEEE conference on Super-computing, 2006.

28. N. Vijaykrishnan, M. Kandemir, M. Irwin, H. Kim, and W. Ye.Energy-driven integrated hardware-software optimizations usingsimplepower. InProc. of the Int. Symposium on Computer Archi-tecture, 2000.

29. E. Walker. The real cost of a CPU hour. IEEE Com-puter,42(4):3541, April 2009.

30. C. Xian, Y. H. Lu, , and Z. Li. Adaptive computation offloadingfor energy conservation on battery-powered systems. InICPADS,2007.

31. H. Zhang, G. Jiang, K. Yoshihira, H. Chen, and A. Saxena. Intel-ligent workload factoring for a hybrid Cloud computing model. InProc. of the Congress on Services, 2009.

32. X. Zhang, J. Schiffman, S. Gibbs, A. Kunjithapatham, andS. Jeong. Securing elastic applications on mobile devices for cloudcomputing. InProc. of ACM Cloud Computing Security Work-shop, 2009.

33. G. Zhao, Z. Shen, C. Miao, and C. Wan. ELM-based intelligentresource selection for Grid scheduling. InProc. of IEEE Interna-tional Conference on Machine Learning and Applilcations, 2009.