VOLARE: Context-Aware Adaptive Cloud Service Discovery for Mobile Systems Panagiotis Papakos
Licia Capra
David S. Rosenblum
Department of Computer Science University College London London WC1E 6BT, UK
Department of Computer Science University College London London WC1E 6BT, UK
Department of Computer Science University College London London WC1E 6BT, UK
[email protected]
[email protected]
[email protected]
ABSTRACT
1. INTRODUCTION
With the recent widespread use of smart mobile devices, as well as the increasing availability of fast and reliable wireless Internet connections for mobile devices, there is increased interest in mobile applications where the majority of the processing occurs on the server side. The flexibility, stability and scalability offered by cloud services make them an ideal architecture to use in client applications in a resource limited mobile environment. This is because mobile application usage patterns tend to be uneven, with various usage spikes according to time and location. However, the mobile setting presents a set of new challenges that cloud service discovery methods developed for non-mobile environments cannot address. The requirements a mobile client device will have from a cloud service may change due to changes in the context of the device, which may include hardware resources, environmental variables or user preferences. Binding to a service offering different quality of service levels from the ones required may lead to excess consumption of mobile resources such as battery life, as well as unnecessarily high provision costs. This paper introduces VOLARE, a middleware-based solution that monitors the resources and context of the device, and dynamically adapts cloud service requests accordingly, at discovery time or at runtime. This approach will allow for more resource-efficient and reliable cloud service discovery, as well as significant cost savings at runtime.
One of the latest distributed computing paradigms to emerge is that of cloud computing [3][4][1], which promises reliable services delivered through next-generation data centres that are built on resource virtualization technologies. There is particular interest in the commercial applications of cloud computing [4] using the Platform as a Service (PaaS), Infrastructure as a Service (IaaS) and Software as a Service (SaaS) delivery models, where software and resources are hosted on the cloud instead of with the client, who pays for the required resources according to their resource usage. Cloud computing can offer some significant advantages to mobile application developers, by enabling completely scalable remote data storage, computation capabilities and so on, while also offering accessing to online resources and services in a manner similar to Web services and Grid computing [1][2]. However, in the case of client applications in mobile devices, the local context, which may include resources, environmental variables and user preferences, may change during runtime [9][11][12]. The quality of service (QoS) levels initially requested by the client program may not match the capabilities of the device in its current context to receive and process data, resulting in resource wastage and higher monetary cost, than what corresponds to the current context of the mobile device [1]. In this paper, as a solution to this problem we are presenting the VOLARE project: Context-Aware Adaptive Cloud Service Discovery for Mobile Systems. VOLARE is a middleware approach that enables dynamic adaptation of cloud service discovery and binding according to the context of a mobile device, ensuring QoS level supported by the context, efficient resource utilization and savings in monetary provision costs.
Categories and Subject Descriptors D.2.11 [Software Architectures]: Service-Oriented Architecture (SOA), Languages, Domain Specific Applications – adaptive systems, service discovery, distributed architectures.
General Terms Design, Economics, Experimentation, Performance, Languages
The VOLARE middleware operates at two levels. At service discovery time, it intercepts service requests from the client application while also monitoring the context of the mobile device. This may include hardware resources (such as battery consumption, CPU, Memory usage etc.), environmental variables (like network bandwidth) and user preferences (like Low Cost Binding, Low Power Operation etc). It then proceeds to adapt each service request according to the context data, to better reflect the current QoS requirements of the client. At runtime, the middleware monitors existing cloud bindings and the changing context of the device; if the context of the client device or the provided QoS level changes beyond specified thresholds then VOLARE negotiates a dynamic adaptation of the QoS levels
Keywords Keywords: context awareness, cloud computing, mobile systems, semantic Web, service discovery, quality of service Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. ARM'2010, November 30, 2010, Bangalore, India. Copyright 2010 ACM 978-1-4503-0455-9/10/11…$10.00.
32
provided by the cloud service itself or initiates service discovery and rebinding to a more appropriate service. The thresholds and the relationship between the context of the device and the QoS levels required are described using a declarative adaptation policy language developed for this purpose. This declarative language allows developers to specify adaptation policies for individual applications, without modifying the application itself, as well as allowing global adaptation of common QoS variables for all cloud applications on the device.
workflows [8], something that currently is less relevant to the mobile application area and to cloud applications in general. The Q-CAD [9] project is a resource discovery and selection framework for mobile systems, taking the current execution context and quality-of service (QoS) requirements into account. These methodologies however do not include dynamic adaptation and rebinding of services during runtime. DINO [13] allows such functionality, but since it is a broker centric architecture, it does not take account of the context of the client device.
In this paper we first discuss related work and then present an example scenario to illustrate VOLARE’s use. Following that, we present the VOLARE functionality and architecture and the policy language. Finally, we present the results of adaptation simulations and the evaluation of the preliminary VOLARE prototype, conclusions and future work.
Finally, there has recently been similar work on context-aware adaptation of mobile applications [4] with cloud services discovery, focusing on market analysis based adaptation of the service request. It focuses on choosing the most efficient service by means of cost-analysis of currently available services available in the market and does not take into consideration the context of the client device.
2. BACKGROUND AND RELATED WORK Cloud computing confers many advantages to developers and organizations [1]. Clients no longer need to be concerned about usage spikes, or over provisioning, as the cost is determined by the total resource usage. Thus, the overall cost of hosting distributed applications of dynamically changing usage levels decreases and is usually fixed per unit resource used.
3. EXAMPLE SCENARIO
It also follows that services based on cloud resources are more reliable, as they are able to cope with usage spikes [3]. This is because cloud resources are assumed to be practically infinite from the client’s perspective, and thus instantly scalable.
On activation by the User of, for instance, the video-streaming application for a video on demand on the Cloud service, the device starts service discovery and binding to the service through a Broker at a typical for 3G (or other) network bandwidth bitrate.
These advantages present particularly useful opportunities for mobile application developers [1]. Mobile applications tend to have usage spikes depending on context variable such as time, date, and external events. In these cases having a scalable platform to launch the application from limits the resource costs.
However, at any bandwidth drop due to mobility, the User does not get the initially QoS requested, while at the same time the binding cost and the device resources spent will correspond to the initially requested high bandwidth service, with current bandwidth possibly only be a fraction of it. Even if the application has adaptive features like frame rate modification etc, as long as the heart of the problem is not tackled: restoring the initial context and QoS agreed or a QoS level that can be currently supported by the device, the service Provider will provide the initial high bandwidth service. As a result, User satisfaction will be low, device resource utilization inefficient (tuned to high bandwidth) and the service Provider will be charged by the Cloud Provider with binding charges corresponding to the high bandwidth service and, depending on the User-Provider agreement so will the User.
In a typical scenario, a mobile “User” uses applications binding on Cloud services, like a video-streaming application. The Cloud Provider charges the service “Provider” for the data transfer volume, while the User may or may not be charged by the Provider, depending on the User – Provider agreement.
Cloud services are typically accessed using brokers. The broker allows clients to submit a service request, including required QoS levels for that service. The broker will then proceed to bind the best matching provider for the requested service and QoS levels [3][4]. There is a significant market of commercial brokers already in use, such as Deltacloud [5], Cloudswitch [6] and Elastra [7], or ones included in cloud suites like Eucalyptus [2]. There is however, currently no standardised method for advertising cloud service QoS level, though there is research currently being performed on the subject [1] [4].
The User as well as the Provider would like the best possible QoS that the device can get at any time, as well as the binding cost to correspond to what the device requests and can really get. With the VOLARE middleware installed on the mobile and consequently context-aware adaptive service discovery and binding on cloud commercial services, the User will enjoy at any time the most appropriate QoS level and cost of binding that the current context permits. Any time a context parameter (like bandwidth) changes (upwards or downwards) beyond specified limits, then transparently to the User and the application, the middleware will search and bind to a service providing the QoS level supported by the current context, ensuring User satisfaction and a toll on device resources and the cost of binding (for the data volume transfer) corresponding to the current context and QoS level and not the nominal binding settings.
There has been extended work in the last decade on context-aware adaptation for Web Services. Middleware like CARISMA [11], CHISEL [12] etc were developed to cope with changing context and necessary adaptation. CARISMA and CHISEL also use a declarative policy language to insert the reasoning rules for adaptation. The MUSIC [10] project follows a similar approach, in the Web Services scenario. It supports dynamic rebinding to Web services that better satisfy a client’s requirements, as such services become available. However, this focuses on adapting to changes of the available services at runtime, not on changes to the requirements of the client device itself due to changes to its context, which is far more likely to occur in the arena of mobile devices where approaches such as VOLARE are better suited. PLASTIC [8] also deals with adaptation of web services in a similar manner. Such dynamic adaptation techniques geared for Service-Oriented Architectures focus on adaptation of entire
33
The QoS Monitoring Module periodically checks if the QoS levels of service offered by the service provider deviate significantly from the agreed requirements. If so, the Service Request Module is notified to start a new cycle for discovery of a new service matching the new requirements.
4. ARCHITECTURE & FUNCTIONALITY The VOLARE middleware is active, monitoring and appending context data through the Context Monitoring Module at a specified recheck rate (meaning the rate by which the middleware rechecks for changes in the context). The client device runs an application which requests a service from the cloud. As it can be seen in Figure 1, the VOLARE middleware is situated on the client device. VOLARE’s architecture follows a modular approach, consisting of several independent modules.
CLOUD Service Binding
Adapted Service Request
Service Binding Module
QoS Monitoring Module QoS Monitor Data
The way the adaptation will be performed and in particular the relationship between the client’s context variables and the QoS levels required, are described in a specialized policy file that uses the VOLARE Adaptation Policy Language.
Cloud Broker
Renegotiation Request
Service Binding
The Service Binding Module initiates service discovery or rebinding sending the adapted service request to the Broker. When an appropriate service is discovered, the Service Binding Module forwards the service binding to the mobile OS through the QoS Monitoring Module.
Service Provision Events
Context Service Data & Binding Context Change Events
This architecture enables VOLARE to be used with already developed applications without modifying the application itself. Instead, the developer only needs to provide a suitable adaptation policy file for the application. VOLARE achieves this by intercepting the service request after it has been initiated by the client application, and adapts it without the application’s direct intervention. The policy is independent of the application itself.
Adapted Service Request
Some VOLARE modules dealing with acquiring context and QOS measuring functionality are, by necessity, platform specific. This enables VOLARE to support a wide variety of context data sensors according to the particular device or family of products it is installed upon. The rest of the VOLARE modules have been implemented in Java ME, able to run in compatible platforms.
Adaptation Module
Service Request
Context Monitoring Module
Service Request Module
5. POLICY LANGUAGE The adaptation policies will be written in a two level policy specification language. The reason for two levels of policy (global and service policy) is to facilitate the developer’s work, having all the universally applying functionality and thresholds in the global level policy and allowing for optional specific service level policies to command desired behaviour of the middleware for a specific application. Additionally the global level policy will allow adaptation of the middleware itself, including the rate in which it rechecks context data etc.
VOLARE Context Data
Service Binding
Service Request
Mobile OS
Application
Service Request
Client Device
The global-level policy will be a policy file specifying the rebinding thresholds of the client device. This policy file will specify when the application will attempt to rebind to a more appropriate service as its requirements change. These thresholds may be further adapted according to changes in the context. This rebinding may be as simple as getting a SOA for a higher and more cost effective QoS package from the same provider, or moving to a different provider if the service is deemed unsatisfactory. This policy file will also be able to specify default adaptation policies for various common variables present in service requests. These rules however, may be overridden by service level policies according to developer specification. Finally, the global-level policy defines a set of rules for adapting requests that have failed to achieve a satisfactory service, as well as thresholds of how much the QoS levels of an offered service can deviate from the request in order to be considered satisfactory.
Figure 1 - The VOLARE middleware modules
The Service Request Module intercepts the service request from the client application and forwards it to the Adaptation Module. This module implementation is, by necessity, platform dependant. The Context Monitoring Module monitors the context of the device, providing context data to the Adaptation Module. At runtime, if there are significant deviations of the context from the currently bound service at runtime, the context monitor alerts the Adaptation Module to re-evaluate whether the presently bound service satisfies the requirements of the client based on its new context. This module implementation is also, by necessity, platform dependant. The Adaptation Module at discovery time handles the adaptation of the service request according to context and resource data or further adaptation based on the results of the initial search. At runtime, it is triggered by alerts from the Context and QoS Monitoring Modules, to re-evaluate and possibly rebind to a more appropriate service according to the context and QoS level.
Service-level policies will enable developers to specify adaptation policies in regards to specific service requests. These policies may override global level policies concerning the same variables. Such a service-level policy includes a definition of the specific
34
variables, pointing them to variables in the QoS request in question, and a set of rules to show how these variables are affected by the context and resource data. To declare a policy, the developer must simply declare a policy for the name of the service, and then include in it possible variations of that policy
costPreference = lowCost; In this case, the global policy used depends on the available battery and the user preferences. What follows is an example of a simple service-level policy. policy dataService plainData cost = 1.5*cost; compressedData cost = 0.5*cost; size = 10; criteria dataService plainData bandwidth > 40; battery> 50; compressedData bandwidth < 40;
policy serviceName policy1 requestQoSVariable = contextVariable* requestQoSVariable; policy2 requestQoS Variable = 50; policy3 void; Criteria objects must then be declared for each policy, to indicate the criteria with which each policy will be activated. By default an AND relationship is assumed for each criteria in a criteria Object. However, the developer can designate OR descriptors. Criteria serviceName policy1 contextVariable1 < 5; policy2 contextVariable1 > = 5; contextVariable1 < 10; OR contextVariable1 >50; policy3 default;
It can be seen in this simple example that for a single service, in this case dataService, a policy sequence allows the specification of multiple different sub-policies which are activated according to certain criteria specified by the criteria statements.
6. EVALUATION 6.1 Case Study In our Case Study Evaluation, we are studying a video streaming application running on a mobile device. We used four video streaming services, each offering streaming video in different bitrate: 28 kbps, 56 kbps, 128 kbps and 256 kbps. By default, the application will bind to a 256 kbps video service. We also assume that the phone on which the application is developed supports an EDGE 3G connection, with a maximum theoretical downstream bandwidth speed of 384 kbps. For ease of evaluation of the resource efficiency of the adaptation functionality, the application does not proceed to decode the video, but instead simply to receive the streaming packets.
Here is an example of a global-level policy, that will enable a global adaptation of the cost levels required by every service request from this devices, as well as the recheck rate(the rate by which the VOLARE middleware rechecks the context data for significant changes, in order to ascertain if a rebinding should be executed). policy global normal recheckRate = 5; lowPower recheckRate = 10; lowCost recheckRate = 3; cost = 0.8*cost;
The purpose of this evaluation is to measure the efficiency of the VOLARE middleware in supporting context-aware adaptive service discovery and binding of a cloud service client.
6.2 Simulation Before completing the implementation of VOLARE, simulations of the context-aware adaptive service discovery behavior of the middleware were run on MATLAB, applying different adaptation policies.
We can see that in this case, depending of the global policy selected, VOLARE will operate with different recheck rates, in order to conserve battery or, alternatively, increase the speed with which VOLARE reacts to context changes by increasing the recheck rate. Additionally, the locCost policy will also instigate a global reduction of the cost QoS request variable, meaning that all service requests from that device have lower costs requirements than during normal operation. The criteria for the different global policies also follow. criteria global normal default; lowPower battery < 50; lowCost battery >= 50;
We used context and resource mobile usage models for specific periods of time to simulate the usage of resources in a mobile device such as battery levels, and the fluctuation of environmental variables such as network bandwidth availability in an attempt to simulate a typical mobile device usage. Then calculations of the expected resource and cost of binding savings in comparison to the non adapted operation were derived by a mathematical model applying the adaptation policy on the context usage models. As an example, in one of those simulations the adaptation procedure was run using the following adaptation policy, requiring a rebinding with current bandwidth and cautionary reduction in relation also to declining battery level: Policy StreamingService
35
complicated policies relating multiple context variables. The middleware was then run on the mobile emulator. In this case, in order to evaluate the performance and behavior of the middleware, since there is no mobile device and battery, the Context Monitoring Module appends the resource and context data with time from the same mobile resource and context usage models used for our simulations. The prototype has been tested on a mobile video streaming client application implemented in Java ME. The client streams video from Amazon cloudFront service using the RTP/RTMP protocol [14]. As in Section 6.1 is described, service discovery is addressed to four alternative streaming cloud services we set up on Amazon cloudFront, for provisioning at bandwidths: 28 kbps, 56 kbps, 128 kbps and 256 kbps.
unadaptedStreaming Response.bandwidth = 256; adaptedStreaming Response.bandwidth= Responce.bandwidth*((Context.bandwidth– 0.2*Context.bandwidth)/100)– Responce.bandwidth*(0.5*(1-Context.battery));
6.4 Adaptation Policy Example For simplicity of presentation, we show results of the implementation tests run using a simple, one context variable adaptation policy, to easily monitor the resource and binding costs of the VOLARE preliminary prototype. The policy used is: Figure 2 - Simulation Results: Bandwidth, Battery and the Cost of the bound service across time
policy streamingService responseQoS = responseQoS*(context.bandwidth*0.8);
In Figure 2, we can see on the Adapted Cost data line how fluctuating battery levels and bandwidth affect which service the client binds to. The context variables, in this case the bandwidth and battery levels are presented as a percentage of maximum values on the y axis. As these fluctuate during a period of time (the x axis), we can see that, applying the above adaptation policy, the service will rebind to more efficient services. This will affect cost and resource consumption of the application, as higher QoS require streaming of larger volumes of data. As Cloud provisioning is typically priced according to volume we can see the difference in cost and cost savings with the Adapted Cost data line. The Adapted Cost is represented as a percentage of the unadapted Cost of binding at nominal conditions. This simulation calculation estimates a binding cost saving of 30.20833% in monetary terms, assuming the cost is linearly proportional to the size of the provided data transfer, and also significant savings in CPU, memory and battery consumption, in contrast to the highest quality service bound by default for non adapted operation.
In this case we have specified a direct correlation between the available bandwidth (measured in percentage of the maximum possible bandwidth) and the adapted service request bandwidth. This example adaptation policy shows that despite the assumed maximum bandwidth for this device, the VOLARE adapted service request will only ask for the quality of video the device is capable of receiving given the available bandwidth, which makes it a simple yet motivating context-aware adaptive operation.
6.5 Preliminary Prototype Results For this evaluation we run our prototype on a the mobile phone emulator described in Section 6.3 with the adaptation policy of Section 6.4 and the streaming service continuously, with the Context Monitoring Module appending the data from our resource usage models and we measure how long it takes for a complete rebind to another streaming service and the resource and cost savings. During our evaluation with the prototype adapting a video streaming client’s request, we found that rebinding lasts an average of 0.963 seconds. This of course affects further the adaptation compared to adaptation simulation results where delay for rebinding is zero. While VOLARE maintains its responsiveness during the rebinding process, streaming time is now lost during the process of reconnecting to another stream.
It should be noted that as the current bandwidth levels cannot support high quality streaming all the way through runtime, the lowering of QoS levels will of course reduce video quality, but enable the service to maintain its frame rate. Depending on the application, binding to a lower quality service may even improve the user experience, such as maintaining frame rate without jitter or loss in the case of video streaming. This simulation example demonstrates that dynamic adaptation during runtime can provide significant savings in cost and hardware resources, without compromising the user experience.
6.3 Prototype Implementation A prototype of the VOLARE middleware has been implemented using Java ME. A mobile emulator platform was set to conform to the DefaultClDcPhone1 device specifications. The Java ME emulator was configured at CLDC-1.1 setting, with the MIDP-2.0 profile. A series of adaptation policies were developed for this application, designed to test the adaptation process in relation to a single context variable, such as bandwidth, as well as more
Figure 3 – Available Bandwidth (%) and corresponding Video Quality, during 31s (in ms), with a recheck rate of 1s.
36
Using the simple adaptation policy described above, we ran the prototype implementation using different recheck rates. In Figure 3 it can be seen how VOLARE rebinds to different video quality services over time, according to the changing bandwidth. The y axis is percentage, and the data lines depict the bandwidth and video quality with the max possible being 100%. In this relatively small timeframe (31 seconds – x-axis), we can also see that it takes time to rebind to another service several times.
using gradually decreasing recheck intervals. During testing, if we set the recheck rate to under 0.9 seconds, or if we use a cloud service provider with slower response time, VOLARE becomes unresponsive when rebinding. This means that the recheck rate should be higher from the rebinding time for each service provider.
As it can be seen, with even a short recheck rate of 1s VOLARE quickly adapts to all significant changes to the context variables. Note however that unlike in the simulation, here the rebinding process, visualized by the connecting lines between the various levels of Video Quality used at runtime, takes a significant toll in this case, with 13.4 seconds spent dedicated to rebinding, with savings on the cost of binding of 26.29%. Running the same policy on a usage model with less fluctuation yielded a 4.2 seconds delay. In this example we see a cost saving of 24.54% in comparison to the cost for unadapted operation.
In conclusion, the dynamic adaptation of service requests for cloud services for mobile systems is an issue that has yet to be sufficiently addressed by the current state-of-the-art. In this paper, we present a solution to this problem via the VOLARE middleware. The middleware monitors the context of the mobile device and then proceeds to dynamically adapt cloud service requests accordingly. This yields an improvement on service discovery of cloud services and binding, resource efficiency and cost-effectiveness by choosing the most appropriate services conforming to the current needs of the client. Monitoring of the QoS levels and available resources will allow for rebinding during runtime, which will increase system reliability and reduce resource and binding costs.
7. CONCLUSIONS AND FUTURE WORK
There are several areas of this work that will be expanded in the future, such as further evaluation of the benefits of dynamic adaptation of cloud service bindings, particularly in monitoring the QoS levels provided from the cloud provider as well as the local context of the device, implemented on a mobile device, instead of a mobile emulator. In this case, we shall be able to monitor the total cost of monitoring and adaptation mechanisms (extra memory and CPU use, power consumption, i.e. the middleware overhead) and the gains in resource and binding cost savings and video QoS. These will be compared on the one hand to the non adapted mobile operation results and on the other hand to the adaptation values derived from the simulations calculations.
Figure 4 – Available Bandwidth (%) and corresponding Video Quality, during 31s (in ms) with a recheck rate of 5s. On the other hand, in the same initial usage model, with a slower recheck rate (see Figure 4), it can be seen that VOLARE can adapt to the bandwidth usage in a more conservative fashion, providing more significant savings in cost and resource efficiency, while ignoring usage spikes. In a usage model with less fluctuating bandwidth, a policy with faster recheck rate would be much more efficient to take advantage of changes in context more readily, since there is less chance of usage spikes and quick fluctuation. In this usage model, we saw cost of binding savings of 22.38% in comparison to unadapted operation. Therefore, with appropriate adaptation policies, VOLARE is versatile enough to be useful in varying usage patterns.
The middleware functionality is also sought to be extended to discover and bind to more than one service on the cloud. One further step of this research will be to develop a mechanism on conflict resolution that will be examined to supplement the declarative adaptation policy language. Event-based re-evaluation that will trigger re-evaluation only on significant changes in context is currently being considered. Finally, the next phase of this research will be the open issue of automatically ascertaining reasonable adaptation policies and recheck rate without need for a manual adaptation policy from the developer, using the context history of the device to anticipate context changes in the future and produce or modify adaptation policies accordiningl.
These examples demonstrate a scenario where bandwidth availability changes rapidly over a short amount of time. When running tests on a more conservative bandwidth availability scenario, with a 10 s recheck rate, over a 30 min streaming session, we got an average of 5 rebinds, and 19.85% savings in cost. In this case we have an average of 4.6 s rebinding time over the course of the runtime, a proportionally far lower resource cost. We see that parameters like rebinding time to a Cloud service, recheck rate and adaptation policy as well as the variability of context variables (namely of bandwidth) significantly affect the middleware performance, in terms of binding cost reduction, resource savings and QoS level ensured.
There are further avenues of research in methods for efficient and standardized dynamic switching from one provided service to another during runtime. There is also a need for a standardized method for QoS advertisement across multiple providers.
8. REFERENCES [1] Armbrust M., Fox A., Griffith R, Joseph A. D., Katz R. H., Konwinski A., and Lee G., Patterson D.A., Rabkin A., Stoica I., Zaharia M.. Above the clouds: A Berkeley View of cloud Computing, UCB/EECS-2009-28, 2009. [2] Nurmi D., Wolski R. Grzegorczyk C., Obertelli G., Soman S., Youseff L., Zagorodnov D., The Eucalyptus Open-Source
We stress-tested the prototype by continuously streaming using the Cloud service, while randomly generating bandwidth changes
37
cloud-Computing System, Proceedings of the 2009 9th IEEE/ACM International Symposium on Cluster Computing and the Grid, (May 18 - 21, 2009). CCGRID. IEEE Computer Society, Washington, DC, 124-131. DOI= http://dx.doi.org/10.1109/CCGRID.2009.93. [3] Weiss A. Computing in the clouds. netWorker, 11(4):16-25, Dec. 2007. [4] Buyya R., Yeo Chee Shin, and Venugopal S. MarketOriented cloud Computing: Vision, Hype, and Reality for Delivering IT Services as Computing Utilities. In High Performance Computing and Communications, HPCC '08. 10th IEEE International Conference, 5-13, 2008. [5] DeltaCloud: http://www.cloudswitch.com/page/products-andpricing, Last visited at 11/08/2010 [6] CloudSwitch: http://www.cloudswitch.com/section/products Last visited at 11/08/2010 [7] Elastra: http://www.elastra.com/products/elastra-enterprisecloud-server, Last visited at 11/08/2010 [8] Bertolino A., Emmerich W., Inverardi P., Issarny V., Liotopoulos F., Plaza P., PLASTIC: Providing Lightweight Adaptable Service Technology for Pervasive Information & Communication. Automated Software Engineering Workshop Contents, ASE Wksp, 2008 23rd IEEE/ACM International Conference on Bertolino. 2009.
[9] Capra L., Zachariadis S. and Mascolo C., Q-CAD: QoS and Context Aware Discovery Framework for Adaptive Mobile Systems, In Proc. of IEEE Int. Conference on Pervasive Services (ICPS05), Santorini, Greece, July 2005. [10] Rouvoy R, Barone P, Ding Y, Eliassen F, Hallsteinsen S,Lorenzo J, Mamelli A, Scholz U., MUSIC: middleware support for self-adaptation in ubiquitous and service-oriented environments. Software Engineering Self Adaptive Software Systems LNCS 5525:164–182, 2009. [11] Capra L., Emmerich W., Mascolo C., CARISMA: contextaware reflective middleware system for mobile applications. Software Engineering, IEEE Transactions on, 29(10):929– 945, 2003. [12] Keeney J., Cahill V., CHISEL: A Policy-Driven, ContextAware, Dynamic Adaptation Framework. Fourth IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY 2003), 4–6 June 2003; 3–14. [13] Mukhija A., Dingwall-Smith A., Rosenblum D. S., QoSAware Service Composition in Dino, (ECOWS.2007), 5th European Conference on Web Services, 2007. [14] Schulzrinne H., Casner S., Frederick R., Jacobson V., RTP: A transport protocol for real-time applications, IETFRFC 1889, Jan. 1996.
38
