Open Aspects

Abstract

Open Aspects are our approach to face unplanned changes in systems that are based on aspect-oriented composition at runtime. They support explicit adaptation models, allowing developers to describe system change events to be observed, and corrective actions to be taken. These events and actions cover both the base system affected by aspects as well as the aspects affecting the base system themselves. The proper combination of change events and corrective actions allows for conditional just-in-time runtime re-composition. This paper offers a detailed discussion of difficulties related to change in aspect-oriented systems and a description of consistency constraints inherent to them. An implementation illustrating Open Aspects and their application is provided.

Introduction

Systems utilizing aspect-oriented programming (AOP) differ in how and when they carry out the processes of composing aspects into the base system, a process also known as weaving. There are systems that statically weave at compile or load-time. Other systems permit the composition of aspects at an application's runtime.

We usually prefer to carry out changes to our systems while they are offline so that the detection and resolution of problems that become apparent during aspects composition will not interfere with the running system. However, there are situations where such practice is not desirable, is inadvisable, or even impossible due to domain specific requirements to the system in question. In telecommunications, for instance, system downtime results in disruption of services, leading to less customer satisfaction, and because of that has to be kept to a minimum or to be avoided entirely [1], [2], [3]. Ambient and embedded computing infrastructures and environments are yet another example of systems that require online adaptations—changes to the running system. The reason for weaving in aspects dynamically results from the requirement that the system aspects to be woven are expected to change at runtime.

Recent work of the aspect-oriented software development community indicates that dynamic aspects are becoming of increased interest. Dynamic aspects offer compositions that can be made effective or revoked at runtime. Prominent activities in this research area are efforts to provide technologies for dynamic method call interception (MCI [4]) or extensions to virtual machines (VM) for enhanced method call dispatch. Systems like PROSE [5], [6], Steamloom [7], JAC [8], AspectL [9], or AspectS [10] are all concerned with hot-deployment of aspects. They employ runtime weaving to dynamically add new code, modify or remove available code or change the way the base application is interpreted. Their weaver considers the systems or code segments to be combined at one particular point in time. Pointcut expressions or predicates (both terms are used interchangeably in this text) are evaluated to compute sets of join-point shadows [11] to be instrumented, and integration steps are performed as necessary to provide the desired composed behavior. Join-point shadows are roughly correspondent locations of actual join-points in a program's representation such as the program's source or its meta structure. We consider poincut predicates to be one essential contribution of AOP to generically designate subsets of a system's computational properties. Examples for that are all accesses to an instance variable, all sends are receptions of a message, or all messages sent by a group of senders or received by a specific receiver.

Opening up systems and allowing them to be changed after their initial deployment—possibly by code providers other than the original one and probably while they are running—increases the likelihood of system changes not planned for at the beginning of their design and development. Furthermore, in such open systems the point in time changes can happen as well as their order and frequency are undetermined. Presence and characteristics of classes, instances, or methods can be revised at any instant or not at all. Furthermore, we can assume changes that not only address elements that belong to the base system, but to affect aspects themselves. Changing pointcuts and their associated sets of join-point shadows or changes to advice code is an example.

Changes like that can and will have an effect on AOP-induced invariants as mentioned above. Hence, a mechanism is needed to explicitly maintain these invariants.

As a simple illustration let us look at a system that uses classes not known at compile time but loads them dynamically on demand. New classes not known during the development and initial deployment of the original system thus appear. In such a situation the problem from the aspect-oriented point of view is that it is not clear how the system should behave. Should pointcut coverage be monitored, and, if necessary, should aspects be recomposed? Or should such changes be ignored at all? Questions like that are not addressed by current approaches and technologies.

Open Aspects is our approach to handling unplanned system changes at runtime. Open Aspects support explicit adaptation models, allowing developers to describe system change events to be observed and corrective actions to be taken in response to these events. System change events and corrective actions cover both the base system affected by aspects and the aspects themselves affecting the base system. The proper combination of change events and corrective actions allows for conditional just-in-time runtime re-composition.

Contributions of our paper include:

• A description of consistency constraints inherent to aspect-oriented systems.

• A detailed discussion of the associated change problem.

• A solution to this change problem by separating and providing an explicit adaptation model to aspect developers.

• An implementation illustrating our solution and its application.

In the next section we give a motivating example. In Section 3, we explain open aspects in general. Section 4 demonstrates how Open Aspects work in the presence of change. Section 5 describes openAspectS, our implementation of Open Aspects in AspectS. Section 6 shows an application example of OpenAspectS. After discussing related work in Section 7, we summarize our paper in Section 8 and come to a conclusion.