âthe life-cycle of adaptive software systemsâ, including evaluating and moni- ... instantiated. This enables the development of reusable dynamic planning and.
Self-Adaptive Systems: A Middleware Managed Approach Eli Gjørven1 , Frank Eliassen1,2 , Ketil Lund1? , Viktor S. Wold Eide1 , and Richard Staehli1 1
2
Simula Research Laboratory, P.O. Box 134, N1325 Lysaker, Norway Dept. of Informatics, University of Oslo, P.O. Box 1080 Blindern, N-0314 Oslo, Norway
Abstract. Recent works on self-adaptivity use a middleware-based approach where the adaptation mechanisms and meta-level information are separated and externalized from the application code. Current solutions generally target individual life-cycle phases of an application in isolation, preventing easy integration of design-time and run-time adaptability. Integration is needed in order to support the introduction of new adaptive behavior during run-time. Self-adapting systems therefore need to support both planning, instantiation and maintenance of applications throughout their life-time. In this paper we propose middleware managed adaptation, in which services are specified by their behavior, and planned, instantiated and maintained by middleware services in such a way that the behavioral requirements are satisfied throughout the service life-time. Central to this approach is mirror-based reflection, which supports introspection and intercession on an application, or any service, through all the phases of its life-cycle, including pre-runtime. The mirror of a service may contain information about its implementation, including the developer’s knowledge about how this implementation will perform in different contexts. By making this knowledge available to the middleware, we facilitate the implementation of a wide range of self-adaptive behaviors.
1
Introduction
Self-adaptive systems [11] adapt themselves to changing requirements and environments, providing dependability, robustness and availability with minimal human interaction. A self-adaptive system must support both the consistent evolution of applications over time, and adaptation of running applications. There is consensus in the research community that general solutions, which separate and externalize adaptation mechanisms and control from the application implementation, are necessary to achieve self-adaptation [7]. Several proposed approaches indicate that middleware-based solutions are suitable for enabling such an externalization, see e.g. [2][4]. ?
Ketil Lund is currently employed at the Norwegian Defense Research Establishment
In [11] a comprehensive adaptation methodology is described that supports management of both evolution and adaptation as two simultaneous and connected processes. Evolution management is concerned with managing software change over time. Such software change may imply rearranging and replacing parts of the application while it is executing, a process which presents a great challenge with regard to the dependability of the application. Performing these changes is part of adaptation management, which is concerned with managing “the life-cycle of adaptive software systems”, including evaluating and monitoring observations, planning changes and deploying change descriptions. This life-cycle can have humans in the loop, or be fully autonomous with no human interference. Inspired by [11], we propose a middleware-based solution to self-adaptation where the middleware is responsible for planning, instantiating and maintaining applications. In line with service oriented computing [9] we characterizes an application by the services it provides to its users. To this end we define a service as a subset of outputs and their causally related inputs to some composition of components [12]. This definition applies both to the work performed by a complex distributed application and to the work performed by lower level services from which the application is built. Furthermore, a service can evolve over time, for instance by adding new adaptive behavior. By leaving the responsibility for managing service adaptation to the middleware, we enable a clean separation between adaptation related concerns, for example deciding when and how to adapt, and the functional implementation of services. However, making good decisions about adaptation, requires detailed technical knowledge about the service implementations and their alternative configurations. In order to facilitate automated reasoning about services, the developer can annotate service implementations with QoS predictor functions, which encode the developer’s knowledge about the Quality of Service (QoS) delivered by a service implementation under different contextual conditions. The middleware adaptation mechanisms and algorithms may exploit the result of these functions without being dependent on their implementation, thereby opening up for the development of a wide range of reusable, application-independent algorithms for self-adaptation. The middleware architecture presented in this paper is based on reflection on a service, as it is defined above. Both static and dynamic meta-information about a service is contained in a service mirror, which can be obtained using the middleware API. A service mirror reflects what is known about the behavior, architecture, implementation (including the QoS predictors mentioned above) and instantiation of the service. Mirror-based reflection extends the scope of reflection to include reflecting on services both before and after they are actually instantiated. This enables the development of reusable dynamic planning and adaptation algorithms that are based on mirrored information only. By providing a reflective API to both evolution related activities and adaptation related activities, service mirrors provide a connection point between evolution management and adaptation management.
The rest of this paper is organized as follows. In Section 2 we describe related research, and in Section 3 we describe the adaptive middleware architecture. In Section 4, we describe a prototype implementation of an adaptive application based on the middleware architecture described in this paper, and finally Section 5 contains conclusions and some open issues that require further work.
2
Background and related technologies
State of the art research in the area of self-adaptive systems is much concerned with different ways to separate and externalize adaptation mechanisms and concerns from the implementation of self-adaptive applications. In this Section we will discuss related work focused on providing the application developer with different types of infrastructure facilitating the development of self-adaptive systems. These infrastructures facilitate the externalization of certain concerns, and thereby allow the application developer to avoid making application code entangled with code for managing adaptation related concerns. 2.1
Architecture-Based Self-Adaptive Software
Architecture-based approaches to self-adaptation exploits architecture models to reason about and control adaptation at run-time. An architecture model represents the adaptable system as a composition of components and their interconnections, with mappings to their implementations [11]. In the course of service evolution, changes to the architectural model are mapped to the application implementation by an architecture evolution manager, and can be deployed to a running application as change descriptors. The Rainbow project[7] introduces a system architectural model in its system model in order to evaluate and adapt the running system. Rainbow extends architecture-based adaptation by adopting architectural styles, which characterizes a family of systems related by shared structural and semantic properties. Architectural styles are used to tailor the adaptation infrastructure by encoding the developers system-specific knowledge, including adaptation strategies and system concerns. An adaptation strategy specifies which adaptations that can be used to move a system away from an undesirable condition, while system concerns are the properties, defined by the systems style, on which adaptation should focus. The Rainbow infrastructure does satisfy the goal of separating adaptation related concerns from application code as discussed above to a certain degree. It allows reuse of adaptation properties, mechanisms and strategies between systems, but only to the extent they have architectural commonalities that can be expressed in shared architectural styles. However, in order to support services whose adaptive behavior can evolve over time, there is a need for higher level adaptation policies that are independent of architecture, and only specified in terms of functional and qualitative behavior.
2.2
Reflection
A reflective system is one that performs computation about itself, and that provides inspection and control through its reflective interfaces [10]. Reflective middleware [8] has been used in several approaches to provide run-time information about an executing system. For example, in the OpenCOM component model [5], each component supports a reflective API that provides access to both structural and behavioral meta-information. Consequently, reflection is tightly coupled with running instances, and cannot be used, for example, to reflect on the architecture of a service that has not yet been instantiated. In the domain of reflective programming languages, object mirrors have been proposed as an improvement of traditional reflective facilities such as Java reflection and the Smalltalk reflective features [3]. In mirror-based reflection, metalevel functionality is implemented separately from base-level objects using metaobjects called mirrors. For example, instead of querying an object about its class membership, the reflective system is queried for the object’s mirror, which contains the object’s meta-information. Mirror-based reflection ensures that clients are not dependent on how the targets of reflection are implemented. In contrast, [3] shows that some traditional, reflective facilities, such as Java reflection, break this principle, and thereby make it difficult to implement certain reflective features. Consider for example, in a distributed system, the problem of reflecting on the class membership of an object that is a local proxy for a remote object. Using Java reflection, querying the proxy for its class will return the Java Proxy class. However, in the case of distributed system, it is the class of the remote object we are interested in. By factoring the reflective functionality out from the implementation of ordinary objects and into an object mirror, we make the mirror responsible for deciding how to mirror objects of different kinds. Furthermore, by separating the metainformation contained in a mirror from the objects themselves, reflective code can execute independently of the reflected system, or even be removed if at any time the reflective facilities are not needed. In the domain of middleware, the principle of mirror-based reflection makes it possible to design a reflective API according to the programming abstractions defined by the middleware “language”. In our case, a mirror can be defined to reflect a service, in terms of middleware abstractions like “type”, “interface”, “service” and “binding”, without being dependent the running instances. In Section 3 we discuss some advantages enabled by this approach. 2.3
Adaptation Policies
One of the complex problems of self-adaptability is deciding how to adapt a running system to better fit the current state of the operational environment. Depending on the system and the targeted domain, this process may take different forms by adopting different adaptation policies. In [13] Walsh, et al., distinguish between three kinds of policies (i) action policies, (ii) goal policies and (iii) utility functions.
Action-policies are the most popular and widely used in different domains such as computer networks, active databases and expert systems. An action policy consists of situation-action rules, which specify exactly what to do in certain situations. While action policies appear powerful to control adaptation, the management of such policies becomes complex from the user point of view. Indeed, the use of situation-action rules require policy makers to be intimately familiar with low level details of the implementation of an adaptable system such as its architecture. This complicates maintenance of the policy when adaptation alternatives of an adaptable service evolve architecturally. Goal polices establish higher-level performance objectives for an adaptive system possibly independent of architecture, leaving the adaptation system or middleware to determine the actions required to achieve those objectives. This is typically the case of some works that develop algorithms that allocate and control computational resources to guarantee promised levels of QoS. Goals provide a binary classification of adaptation alternatives of an adaptable service into “feasible” and “unfeasible” configurations for a given state of the operational environment. Utility functions allow one to specify the degree of desirability of different adaptation alternatives of an adaptable service. Utility is often defined as a function of the achieved QoS of an implementation alternative for a given state of the operational environment. Utility functions permit on the fly determination of a “best” feasible implementation alternative while goal policies select any implementation that happens to be both feasible and acceptable with no drive towards finding “better” adaptation alternatives[13]. While all of the above kinds of policies may be applied in middleware managed adaptation, we believe a truly self-adaptive system should not require administrators to ascribe value to low-level resources or to base their adaptation policies on detailed knowledge of all possible configurations of an adaptable service. Instead, they should be able to specify adaptation goals or utility in terms of the service level attributes that matter to them or their customers, such as end-to-end response time, latency, throughput, etc. In our work we therefore explore goal-oriented and utility-function policies to control adaptive behavior.
3
The QuA middleware approach
In our approach to middleware support for self-adaptation, services are specified by their behavior (service type and quality requirements), and then planned, instantiated, and maintained by middleware services in such a way that the behavioral requirements are satisfied throughout the service life-time. The middleware reflective API provides access to a service’s meta level both before and during the running phase of the service. A service’s meta-level reflects what is known about the behavior, architecture, implementation (including the QoS predictors mentioned above) and instantiation of the service.
3.1
Mirror-Based Reflection
In our approach, we adopt the principles of mirror-based reflection as described in Section 2.2. We define access to the meta-level as a middleware service, like traditional middleware services such as service instantiation and binding.
platform dependencies
QoSPredictors ServiceMirror
Behaviour Type
has
Architecture Blueprint
instance interfaces
Interface Quality
If atomic component, an implementation class, and if composition, the roles, types and bindings.
Fig. 1. Service Mirror
The service mirror provides reflection on both static and dynamic aspects of a service. Conceptually, a service mirror consists of a Behavior part, an Architecture part and an Interfaces part. Figure 1 illustrates these three parts. The Behavior part reflects the type of the service, which defines the functional behavior of the service in terms of its provided interfaces. In addition to defining functional behavior, service type defines a set of QoS dimensions, also called QoS model, which are used to describe the qualitative behavior of the service. A service behavior definition may be refined by adding qualitative requirements and preferences statements on the QoS dimensions. This is illustrated in the figure as the Quality part of the behavior part. We propose to use utility functions, as described in Section 2.3, to express such statements. The Architecture part contains the name of a so called Blueprint that encapsulates a service implementation conforming to the functional behavior specified by the service mirror. Additionally, it contains a service mirror representing a platform, or virtual machine, able to interpret this blueprint and instantiate services from it. For example, if the blueprint contains one or more Java classes, the platform must run on a Java virtual machine, in order to be able to load the Java classes. Or, a blueprint may be independent of any particular platform. For example, by specifying a service as a composition of subservices, i.e. set of typed roles, and bindings between the roles, the blueprint can be interpreted by the middleware itself. The Architecture part also contains a set of QoS predictors, which encode the developers knowledge about the QoS of the service implementation, as mentioned in Section 1, providing QoS-values according to the QoS-dimensions defined by the service type of the mirror.
As indicated by the figure, a service mirror may be a recursive tree structure where each mirror in the tree may define zero or more dependencies to other services, also represented by mirrors. A QoS-predictor may depend on predictor functions for these dependencies. This recursive structure enables automatic reasoning about the quality delivered by the top-level service by recursively parsing the QoS-predictions contained in the tree. The Interfaces part of a service mirror contains references to the run-time objects that provide the interfaces specified by the service type. Service mirrors representing services both before and during their running phase, can be advertised or obtained using the middleware API. This enables run-time mapping between service types, alternative service implementations and running service instances, which can be used by planning and adaptation mechanisms as described in the next sections. 3.2
Service Planning
Central to our approach is a process called service planning, whose responsibility is to plan the initial configuration or the reconfiguration of a service. The service planner developed in the QuA project, is based on searching through and evaluating a set of alternative service mirrors in order to find and select a service implementation that satisfies the functional and qualitative service requirements. It uses a centralized algorithm where all decisions are made locally. In the case of distributed applications, actions decided by the orchestrating planner, such as to instantiate a component or to create a binding, can be delegated to middleware instance running at other participating hosts. The input to the service planner is a mirror that at least contains a behavior specification, i.e. type specification and quality requirements expressed as a utility function. The mirror may also contain an architecture blueprint, and even instance interface references, in which case it is up to the planner to decide whether to plan the service based on the existing implementation, or to consider other alternatives. The service planner queries a broker for alternative service mirrors that match the type specified by the input mirror. It evaluates the alternative mirrors, and tries to recursively resolve any dependencies defined. We say that a service mirror is fully resolved if it has an architecture with no dependencies, or it has an architecture whose dependency mirrors are all fully resolved. Otherwise, we say that the mirror is partially resolved. When a mirror is fully resolved, the QoS provided by the mirrored service may be recursively calculated using QoS predictors. Each resulting prediction is used as input to the utility function in the behavior specification, in order to calculate the utility of the service provided by each variant. Finally, the planner ranks the alternative fully resolved mirrors based on their utility. The result of service planning is normally the mirror ranked highest by the planner, but in some cases it may be useful to keep partially resolved mirrors, for example as a cache for later planning.
By separating the meta-information contained in a mirror from the objects themselves, we enable reflective code and service planning to execute independently of reflected services. For example, in the case of mobile nodes with limited resources, service discovery and planning may be performed on connected servers only, while a light-weight version of the middleware runs on the mobile nodes. We envisage that service planning together with the ability to dynamically advertise and discover service mirrors can be exploited to support service evolution. Since mirrors can be advertised at run-time, new and improved software versions and service configurations of an existing service can be advertised as service mirrors after the service has been initially taken into use. The next time the service is planned, the new implementations may be automatically discovered by the broker and considered for use during the planning process. 3.3
Adaptation
Middleware managed adaptation includes reasoning and making decisions about when adaptation is initiated, and planning and executing reconfiguration at runtime. Adaptation in this setting means to go back to the planning phase and reconsider the architecture that was selected, or one or several of its resolved dependencies, a process we call replanning. This leads to the following generic adaptation algorithm: 1. Get the service mirror that represents the service to be adapted 2. Perform service replanning in the current context 3. If the result of service planning imply changes to the running service, modify the service mirror using the mirror’s meta-object operations 4. Transfer the changes made to the service mirror to the base-level During service replanning in step 2) above, the QoS predictors and the utility functions are calculated in the new context of the service. If any of the alternative implementations returns a better utility value, this alternative is selected by the planner, and a reconfiguration will happen in step 3) above. Such reconfiguration could consist of for example replacing a component with a better performing component, or migrating a component to another location. Note that the adaptation algorithm is independent of planning algorithm, service implementations or even service domain. Based on this algorithm, a family of different, specialized algorithms can be developed in order to handle different adaptation concerns. These specialized algorithms may encode adaptation strategies to make decisions about when and how to adapt. For example, the adaptation strategy could specify context events that should trigger adaptation, or could use historical information to reason about how to adapt in order to reach a stable system.
4
Case study and prototype
We now describe how the QuA middleware architecture presented in Section 3 is used to implement an application with self-adaptive behavior.
4.1
The Personal Media Server Application
In order to demonstrate self-adaptive behavior, we have developed an application called Personal Media Server (PMS), which can be viewed as an in-house personal proxy server for storage and delivery of multimedia content. The PMS receives media data from external providers, for instance, a regular TV-broadcast via cable or an audio stream from an Internet radio provider. A client device, such as a laptop or handheld computer, may be used to connect to the PMS and initiate streaming from any location, assuming Internet connectivity. If the user is watching a video while on the move, the operational environment may change over time. For example, the available network bandwidth between the PMS and the client device may vary considerably, or even drop to zero. Being self-adaptive, the application continuously monitors such variations and adapts itself in order to maintain the best possible user experience. In case of bandwidth degradation, the video streaming may continue by reducing the framerate and/or the image quality. If the available bandwidth becomes insufficient for streaming even the lowest quality acceptable to the user, the application should notify the user, pause until the network again becomes usable, and then resume. 4.2
Defining Service Behavior
The PMS offers a service called WatchTV. The functional behavior of WatchTV is to stream live or stored video content to a client device. The WatchTV service type defines four QoS dimensions, namely framerate, frame quality, temporal displacement and time scaling ratio. The PMS may handle an unreachable client device by either dropping the frames received from the media source or by buffering the frames in order to resume streaming once the connection is reestablished. Such buffering introduces delay, a timeshift. Once the network becomes accessible, the delay may steadily be reduced by streaming the video somewhat faster from the buffer compared to the buffer arrival rate. Such time scaling results in a higher framerate at the client device while catching up with the stream arriving at the PMS. The temporal displacement dimension is the number of seconds introduced by timeshifting, while the time scaling ratio is the speed of the presented video relative to the speed of the original stream. The PMS application developer uses the QuA middleware to instantiate a service of the type WatchTV, leaving to the middleware to find the implementation of WatchTV that provides “the subjective best possible presentation experience”, according to user needs and preferences. A user watching his favorite football team playing an important game may be eager to know the result. Receiving the newest data is probably preferable, even if fragments of the match are lost when network bandwidth is scarce. In contrast, a football expert performing a game analysis, would prefer receiving the whole game, even if this implies timeshifting the video and thereby prolonging the presentation considerably. Such preferences may be input by means of a graphical user interface and then mapped to a utility function over the QoS dimensions defined by the WatchTV service.
Media Source
PMS
Client Device
Live streaming:
VideoSource
WatchTV Receiver Sender
VideoSink
Redirect to disc:
VideoSource
WatchTV Receiver
VideoSink
Buffer
Timeshift:
VideoSource
WatchTV Receiver Sender
VideoSink
Buffer
Fig. 2. The three architectures of the PMS application
4.3
Service Implementation and QoS Prediction
The PMS was implemented using already existing software for capturing, encoding, streaming, decoding, and presenting video content [6]. The software was refactored and published to the middleware as service implementations, and service mirrors describing these implementations were advertised. Figure 2 illustrates the three different architectures of the streaming service: (1) live streaming to the client device, (2) redirecting the stream to buffer instead of to the client device, and (3) streaming from buffer to the client device. In order to support middleware managed adaptation and more specifically to enable QoS-aware planners to reason about different implementation alternatives, the developers also had to implement QoS-prediction functions for each architecture as described in Section 3. The predictor associated with an architecture calculates a value for each QoS dimension based on the current context. The context elements that are taken into account by the predictor are the current available bandwidth and temporal displacement. The predictor may classify an architecture as invalid if the architecture cannot deliver a useful service in the current context. For example, an architecture is invalid if the estimated bandwidth requirement, given a certain framerate and frame quality, is less than the current available bandwidth. In this work, we assume a context management system, such as the QuAMobile context manager described in [1]. In the PMS prototype, we use a context simulator to provide this information. During service (re)planning (step two of the generic adaptation algorithm), the service planner iterates through different service mirrors and invokes the QoS predictors. The predictions are used as input to an application specific utility function, that calculates utility by weighing the QoS dimensions according to user preferences. The mirror with the highest utility is selected.
4.4
Observations
During the work with the PMS prototype application, we have made some observations on programming with the QuA middleware. Porting the existing software to QuA services and creating mirrors to represent them was mainly a matter of defining and encoding meta-information (e.g., service type, QoS dimensions, and dependencies) into mirrors. Very few modifications of the existing code were necessary. However, we observed that defining the QoS-dimensions, or QoS model, used to describe the qualitative behavior of the service was intimately related to the adaptive behavior introduced by the timeshift feature. This may seem to contradict the goal of separating adaptation concerns from application concerns, but must in fact be expected since the goal of adaptation is to influence the qualitative behavior. When new adaptive behavior is introduced to the system, the developer may refine the QoS model used to specify the behavior of the service into a more complete model. Naturally, a more complete model allows more complete and finer grained service specification than less complete models. A detailed discussion about QoS models and completeness is given in [12]. Defining the QoS-predictors required detailed knowledge about existing code and dependencies between the implementations. Similarly, defining the utility functions was also non-trivial, because detailed understanding of the behavior of the service and the mapping to user preferences was required. This reflects the fact that expert skills are required in order to understand the performance of an implementation in different situations and for making this knowledge available. The same is the case for understanding the relationship between different dimensions of QoS, and user satisfaction. By including such knowledge in the reflective API, we not only enable automatic reasoning that exploits this knowledge, but we also allow experts to publish new and better functions as more knowledge and experience with the services and their implementations are gained. The middleware decision mechanisms can thereby immediately exploit this information, without the need for reimplementing application code, planning algorithms, or adaptation algorithms. The initial experience with the PMS application supports our hypothesis that it is possible to encode developer knowledge as prediction functions, and to implement planning and adaptation algorithms using a mirror-based reflection API including these functions. So far, the presented middleware managed approach to self-adaptiveness seems promising.
5
Conclusions
In this paper, we have described the QuA approach to middleware managed adaptation, based on service planning and mirror-based reflection. Mirror-based reflection provides meta-information on both static and dynamic aspects of a service, for example its behavior, architecture and instantiation, and QoS predictor functions to estimate the qualitative behavior of a service. The service
planning process uses service mirrors to recursively evaluate and select service implementations that match the current context and user preferences. The QuA middleware architecture presented in this paper, has been used to implement an application with self-adaptive behavior, the Personal Media Server. This work has provided some initial experience with programming with platform managed adaptation. We plan to extend this research by investigating how new adaptive behaviors can be introduced into the system by inserting updated and improved QoS-predictions and utility functions. We also intend to explore how the middleware can support long term service evolution. This is motivated by the fact that since mirrors can be advertised at run-time, the adaptation services are able to continuously discover, reason about, and exploit new software versions and service configurations. This we believe will facilitate supporting service evolution using the same mechanisms as for short term adaptation. We also plan to investigate how service mirrors can be used to reason about distributed services, and to develop distributed service planning and adaptation management. As computational cost is an important factor in any reflective system, we also will compare the cost of using mirrorbased reflection to traditional reflection. Finally, we plan to extend this research by introducing middleware services that adapt not only self-adaptive applications, but also the adaptation mechanisms themselves, for example by reasoning about the need for specialized planning or adaptation algorithms. By regarding adaptation mechanisms and control as services themselves, the same principles may be used for managing adaptation services as well as application services.”
Acknowledgments We would like to thank all persons involved in the QuA project for contributing to the ideas presented in this paper. In particular we appreciate Jørgen Andreas Michaelsen’s contributions in designing and implementing the PMS prototype.
References 1. S. L. Amundsen and F. Eliassen. Combined Resource and Context Model for QoSaware Mobile Middleware. In 19th International Conference on Architecture of Computing Systems, pages 84–98, 2006. 2. Gordon S. Blair, Geoff Coulson, Anders Andersen, Lynne Blair, Michael Clarke, Fabio Costa, Hector Duran-Limon, Tom Fitzpatrick, Lee Johnston, Rui Moreira, Nikos Parlavantzas, and Katia Saikoski. The Design and Implementation of Open ORB 2. IEEE Distributed Systems Online, 2001. 3. Gilad Bracha and David Ungar. Mirrors: Design Principles for Meta-level Facilities of Object-Oriented Programming Languages. In Proceedings of the 19th Conference on Object-oriented programming, systems, languages, and applications, pages 331–344. ACM Press, 2004.
4. L. Capra, W. Emmerich, and C. Mascolo. CARISMA: Context-Aware Reflective mIddleware System for Mobile Applications. IEEE Transactions on Software Engineering, 2003. 5. Geoff Coulson, Gordon Blair, Paul Grace, Ackbar Joolia, Kevin Lee, and Jo Ueyama. A Component Model For Building Systems Software. In Proceedings of Software Engineering and Applications, 2004. 6. Viktor S. Wold Eide, Frank Eliassen, and Jørgen Andreas Michaelsen. Exploiting Content-Based Networking for Fine Granularity Multi-Receiver Video Streaming. In Surendar Chandra and Nalini Venkatasubramanian, editors, Proceedings of the Twelfth Annual Multimedia Computing and Networking (MMCN ’05), San Jose, California, USA, volume 5680, pages 155–166, January 2005. 7. David Garlan, Shang-Wen Cheng, An-Cheng Huang, Bradley Schmerl, and Peter Steenkiste. Rainbow: Architecture-Based Self-Adaptation with Reusable Infrastructure. IEEE Computer, 37(10):46–54, 2004. 8. Fabio Kon, Fabio Costa, Gordon Blair, and Roy H. Campbell. The case for reflective middleware. Commun. ACM, 45(6):33–38, 2002. 9. D. Georgakopoulos M. Papazoglou. Service-oriented computing. Communications of the ACM, 46(10), 2003. 10. Pattie Maes. Concepts and experiments in computational reflection. In OOPSLA ’87: Conference proceedings on Object-oriented programming systems, languages and applications, pages 147–155, New York, NY, USA, 1987. ACM Press. 11. Peyman Oreizy, Michael M. Gorlick, Richard N. Taylor, Dennis Heimbigner, Gregory Johnson, Nenad Medvidovic, Alex Quilici, David S. Rosenblum, and Alexander L. Wolf. An architecture-based approach to self-adaptive software. IEEE Intelligent Systems, 14(3):54–62, 1999. 12. Richard Staehli and Frank Eliassen. Compositional Quality of Service Semantics. In SAVCBS’04, Workshop at ACM SIGSOFT 2004/FSE-12 October 31-November 1, pages 62–69, 2004. 13. William E. Walsh, Gerald Tesauro, Jeffrey O. Kephart, and Rajarshi Das. Utility Functions in Autonomic Computing. In First International Conference on Autonomic Computing (ICAC’04), 2004.
This article was processed using the LATEX macro package with LLNCS style
