Software-based systems today are increasingly expected to dynamically self-adapt to accommodate resource variability, changing user needs, and system faults. Recent work uses closed-loop control based on external models to monitor and adapt system behavior at run time. Taking this externalized approach, the Rainbow framework we have developed uses software architectural models to dynamically monitor and adapt a running system. A key goal and primary challenge of this framework is to support the reuse of adaptation strategies and infrastructure across different systems. In this poster, we show that the separation of a generic adaptation infrastructure from system-specific adaptation knowledge makes this reuse possible. 1.

Most applications developed today rely on a given middleware platform which governs the interaction between components, the access to resources, etc. To decide, which platform is suitable for a given application (or more generally, to understand the interaction between application and platform) , we propose UML models of both the architectural style of the platform and the application scenario. Based on a formal interpretation of these as graphs and graph transformation systems, we are able to validate the consistency between platform and application.

A holy grail of component-based software engineering is “write-once, reuse everywhere”. However, in modern distributed, component-based systems supporting emerging application areas such as service-oriented e-business (where web services are viewed as components) and Peer-to-Peer computing, this is difficult. Non-functional requirements (related to qualityof-service (QoS) issues such as security, reliability, and performance) vary with deployment context, and sometimes even at run-time, complicating the task of re-using components. In this paper, we present a middleware-based approach to managing dynamically changing QoS requirements of components. Policies are used to advertise non-functional capabilities and vary at run-time with operating conditions. We also provide middleware enhancements to match, interpret, and mediate QoS requirements of clients and servers at deployment time and/or runtime. 1

Autonomic Computing is a concept that brings together many fields of computing with the purpose of creating computing systems that self-manage. In its early days it was criticised as being a “hype topic” or a rebadging of some Multi Agent Systems work. In this survey, we hope to show that this was not indeed ’hype ’ and that, though it draws on much work already carried out by the Computer Science and Control communities, its innovation is strong and lies in its robust application to the specific self-management of computing systems. To this end, we first provide an introduction to the motivation and concepts of autonomic computing and describe some research that has been seen as seminal in influencing a large proportion of early work. Taking the components of an established reference model in turn, we discuss the works that have provided significant contributions to that area. We then look at larger scaled systems that compose autonomic systems illustrating the hierarchical nature of their architectures. Autonomicity is not a well defined subject and as such different systems adhere to different degrees of Autonomicity, therefore we cross-slice the body of work in terms of these degrees. From this we list the key applications of autonomic computing and discuss the research work that is missing and what we believe the community should be considering.

This paper presents a component-based architecture for autonomous repair management in distributed systems, and a prototype implementation of this architecture, called JADE, which provides repair management for J2EE application server clusters. The JADE architecture features three major elements, which we believe to be of wide relevance for the construction of autonomic distributed systems: (1) a dynamically configurable, component-based structure that exploits the reflective features of the FRACTAL component model; (2) an explicit and configurable feedback control loop structure, that manifests the relationship between managed system and repair management functions; (3) an original replication structure for the management subsystem itself, which makes it fault-tolerant and self-healing. 1

Autonomous or semi-autonomous systems are deployed in environments where contact with programmers or technicians is infrequent or undesirable. To operate reliably, such systems should be able to adapt to new circumstances on their own. This paper describes our combined approach for adaptable software architecture and task synthesis from high-level goals, which is based on a three-layer model. In the uppermost layer, reactive plans are generated from goals expressed in a temporal logic. The middle layer is responsible for plan execution and assembling a configuration of domain-specific software components, which reside in the lowest layer. Moreover, the middle layer is responsible for selecting alternative components when the current configuration is no longer viable for the circumstances that have arisen. The implementation demonstrates that the approach enables us to handle non-determinism in the environment and unexpected failures in software components.

A common approach to adding self-management capabilities to a system is to provide one or more external control modules, whose responsibility is to monitor system behavior, and adapt the system at run time to achieve various goals (configure the system, improve performance, recover from faults, etc.). An important problem arises when there is more than one such self-management module: how can one make sure that they are composed to provide consistent and complementary benefits? In this paper we describe a solution that introduces a self-management coordination architecture and infrastructure to support such composition. We focus on the problem of coordinating self-configuring and self-healing capabilities, particularly with respect to global configuration and incremental repair. We illustrate the approach in the context of a self-managing video teleconference system that composes two pre-existing adaptation modules to achieve synergistic benefits of both. 1

Dynamic architectural change is defined as the addition and removal of components and connectors. Dynamic software architectures are those architectures that modify their architecture and enact the modifications during the system’s execution. This behavior is most commonly known as run-time evolution or dynamism. As dynamic software architecture use becomes more widespread, it is important to gain a better understanding of this type of software evolutionary change and be able to classify formalisms, approaches and tools. Current evaluations in the areas of software architecture and evolutionary change have made strides in classification but are not sufficient to evaluate dynamic software architectures. A dedicated comparison of dynamic software architectures and architectural formalisms is necessary in order to gain a deeper understanding of run-time evolution. In this paper we present a set of classification criteria for the comparison of dynamic software architectures based on: change type, change process, and change infrastructure. We demonstrate the use of the criteria by classifying three types of dynamic software architectural change. In addition we survey 14 current approaches to the formal specification of dynamic software architectures based on graphs, process algebras, logic, and other formalisms. We then

Abstract Context-aware applications monitor changes in their operating environment and switch their behaviour to keep satisfying their requirements. Therefore, they must be equipped with the capability to detect variations in their operating context and to switch behaviour in response to such variations. However, specifying monitoring and switching in such applications can be difficult due to their dependence on varying contextual properties which need to be made explicit. In this paper, we present a problemoriented approach to represent and reason about contextual variability and assess its impact on requirements; to elicit and specify concerns facing monitors and switchers, such as initialisation and interference; and to specify monitoring and switching behaviours that can detect changes and adapt in response. We illustrate our approach by applying it to a published case study.

Abstract. Computers support more and more tasks in the personal and professional activities of users. Such user tasks increasingly span large periods of time and many locations across the enterprise space and beyond. Recently there has been a growing interest in developing applications that can cope with the specific environmental conditions at each location, and adapt to dynamic changes in system resources. However, in a given situation there may be many possible configuration solutions, and an awareness of the user's intent for each task is a critical element in knowing which one to pick. In this paper, we discuss the limitations of building such awareness into applications, and propose to factor the awareness of user tasks into a common software layer. That however, brings up the problem of coordinating the system-wide adaptation performed by such a layer with fine-grain adaptation performed by resource-aware applications. We summarize the main features of an architectural framework that incorporates such a layer, and distill some of the lessons learned in implementing the framework.