Maintaining Consistency in Reconfigurable Aspect-Oriented Middleware

Maintaining Consistency in Reconfigurable Aspect-

Oriented Middleware

Bholanathsingh Surajbali, Geoff Coulson and Paul Grace

Computing Department,

Lancaster University

Lancaster, UK

{b.surajbali, geoff, p.grace} @comp.lancs.ac.uk

Abstract. Aspect-oriented middleware is a promising technology for the

realisation of dynamic reconfiguration in heterogeneous distributed systems.

However, like other dynamic reconfiguration approaches, AO-middleware-

based reconfiguration requires that the consistency of the system is maintained

across reconfigurations. AO-middleware-based reconfiguration is an ongoing

research topic and several consistency approaches have been proposed.

However, most of these approaches tend to be targeted at specific narrow

contexts, whereas for heterogeneous distributed systems it is crucial to cover a

wide range of operating conditions. In this paper we propose an approach that

offers distributed dynamic reconfiguration in a consistent manner, and features

a flexible framework-based consistency management approach to cover a wide

range of operating conditions. We evaluate our approach by investigating the

flexibility, configurability and transparency of our approach and also quantify

the performance overheads of our framework.

Keywords: AO-middleware, dynamic reconfiguration, consistency, flexibility,

configurability, transparency.

1 Introduction

A key and growing challenge for distributed systems is their need to support dynamic

reconfiguration in order to maintain optimal levels of service in diverse and changing

environments. In response to this challenge, aspect-oriented middleware (AOM) has

recently emerged as a promising basis on which to build reconfigurable distributed

systems [19, 22]. The core concept of AOM systems is that of an aspect: a software

module that deals with one specific concern, and which can be changed independently

of other modules. Aspects are also associated with compositional logic (often called a

pointcut) that describes declaratively where and when the aspect should be composed.

The attraction of AOM based reconfiguration lies in the fact that aspects are

inherently orthogonal encapsulations of behaviour and pointcuts are inherently

location independent.

Maintaining consistency is a fundamental requirement in the evolution of all

dynamically reconfigurable distributed systems, including AOM systems: dynamic

reconfiguration must not leave the system in an inconsistent state that can potentially

lead to incorrect execution or even complete system failure. A commonly agreed

definition of consistency in this context has been provided by Goudarzi [13]: “a

dynamic software reconfiguration yields a correct system if after completing the

reconfiguration it meets the following three requirements: first the system must satisfy

its structural integrity requirements; secondly entities in the system are in mutual

consistent states; and thirdly the application state invariants hold”.

While this definition nicely captures the semantics of consistency, it does not draw

attention to important pragmatic perspective of what is happening at the infrastructure

level of dynamically reconfigurable systems such as AOM environments. Such

environments are always vulnerable to incidental ‘glitches’ or subtle combinations of

circumstances (e.g. temporary disconnections or race conditions) that can cause

consistency problems or threats even where a dynamic reconfiguration operation has

been perfectly well conceived and planned at the level of application specific

semantics. Furthermore, such environments are most vulnerable to such threats

precisely at the time that a dynamic reconfiguration is taking place, as so much is in

flux. This paper therefore focuses on this latter perspective: that of identifying and

mitigating the numerous incidental threats that can lead to inconsistent

reconfigurations in AOM systems.

To address this perspective we present in this paper a distributed consistency

framework for AOM environments that maximises the probability of consistent

dynamic reconfiguration in the face of incidental factors. The framework defines i) a

threat taxonomy (i.e. a rational classification of the threat types understood by the

framework), and ii) a canonical set of threat aspects that mitigate the threats found in

the taxonomy, and an associated set of join point strategies to guide the application of

the threat aspects within diverse AOM implementations. Our approach itself is highly

configurable and reconfigurable, as the framework’s mechanisms for detecting and

repairing threats are themselves composed of dynamically woven aspects. The core

goals of our framework are as follows:

• Flexibility. The consistency framework aims to be independent of any specific

middleware. The intention is that it can be applied to a range of AOM

technologies and even to non-AO reconfigurable middleware systems for which

consistency maintenance is an issue. We show in this paper that the framework

has been successfully mapped to JAC [22], DyReS [27], and AO-OpenCom [24].

• Configurability. The consistency related functionality of the framework can be

configured and reconfigured based upon the requirements and environmental

conditions. As mentioned, this is achieved by applying the aspect approach to the

realisation of the framework elements themselves.

• Transparency. Managing reconfiguration across each node is a complex and error

prone task for the application programmer. Achieving consistency must therefore

involve minimum programmer effort.

The rest of the paper is organised as follows. Section 2 provides a detailed discussion

of the various threats to consistency to which distributed applications are prone. In

Section 3 we present the distributed consistency framework (COF), which is then

applied to the above-mentioned AOM platforms in Section 4. Section 5 provides the

evaluation of COF. Finally, Section 6 discusses related work, and we offer our

conclusions in Section 7.

2 Motivating Case Study for Consistent Dynamic Reconfiguration

To motivate the need to manage consistency under dynamic reconfiguration we now

present a typical application scenario (see figure 1) which comprises a multimedia

peer to peer network in which heterogeneous peers (i.e. laptops, PCs, and PDAs)

operate in and across different network domains (Internet, Wi-Fi, ad-hoc wireless

networks). Applications stream audio and video media to be received by one or more

peers; this content is hosted on infrastructure repositories for video and audio.

Fig. 1. A reconfigurable application scenario

This scenario throws up the need for a wide range of dynamic reconfiguration

operations. For example:

1) An increase of video traffic in the network may cause the performance of the

streaming application to drop; to improve performance a caching aspect can be

woven as a remote aspect onto selected peers within the network.

2) Mobile users may want to switch to wireless network connectivity when their

location changes. In this situation a fragmentation aspect can be dynamically

woven into the system, whereby sending nodes fragment their video frames and

receiving nodes reassemble them.

3) At a later date, secure content may be deployed into the media servers; to support

access to this content, authentication and authorisation aspects can be deployed.

4) An increase in the sharing of copyright-infringing material may lead to the

application monitoring its usage. For this purpose a logging aspect can be

dynamically deployed at each of the peers.

5) Users wanting to share private content between themselves may deploy

encryption and decryption aspects.

Analysis. Within this scenario there are numerous potential threats to consistency

which we expand upon and resolve in the subsequent sections:

• Threats from reconfiguration requests. If a reconfiguration request is not

properly checked, it may proceed while containing errors (for example wrongly

formed declarative reconfiguration specifications) which may lead to incorrect

actions and system inconsistency when the reconfiguration is applied. Similarly, a

reconfiguration request may be unauthorised or reconfiguration messages may be

spoofed by malicious nodes in an attempt to compromise consistency. In addition,

reconfiguration requests may arise simultaneously in the system so that

reconfiguration-related messages relating to distinct requests may be interleaved

and potentially received in different orders at different nodes. For example, one

request may ask to replace the fragmentation aspect with a different algorithm,

while another asks for it to be removed. There will clearly be different outcomes

depending on the execution order of these two requests—and furthermore the

outcomes might be different at different nodes.

• Threats from the environment. The inherently unstable characteristics of the

networks and nodes employed in the scenario increase the chances that a

reconfiguration will be compromised. For example, application nodes may fail to

apply a requested reconfiguration if: i) the node is overloaded or has crashed; ii)

the node’s local policy forbids it to make the requested change; iii) aspects may

still be performing computations when an attempt is made to remove or

recompose them. Such factors can clearly lead to parts of the intended

reconfiguration not being carried out, and consequent inconsistency. Further,

aspects to be reconfigured into the system are typically stored in infrastructure

service repositories which may get congested with requests, or themselves crash,

meaning that aspects may not be available to be deployed in some cases or at

some times. Additionally, different repository instances may have different

versions of the aspects: e.g. different versions of the encryption aspects may be

produced over time, so that different nodes configure different versions and be

inconsistent with each other. Finally, if reconfiguration-related messages are lost,

re-ordered, duplicated or delayed, the consistency of the reconfiguration can be

compromised. For example, a fragmentation aspect may be deployed but not the

corresponding reassembly aspect.

• Threats from composition. Some aspects are inherently dependent on each other;

for example, a decryption aspect is dependent on the corresponding encryption

aspect. Therefore the order in which aspects are woven is crucial: e.g., encryption

must be put in place before its associated decryption. Further, ‘remote aspects’

[21] which are used by several distributed client nodes can be a source of

inconsistency; for example, if a cache implemented as a remote aspect is removed

without the consent or even the awareness of its client nodes, errors can arise

when clients attempt to communicate with the cache. Finally, semantic conflicts

can occur due to incompatibilities of the reconfigured aspect with the rest of the

system—as may arise, e.g., in the deployment of logging and privacy aspects [10].

Moreover, the composition order in which aspects are weaved can also affect their

interactions, for example, if a cache advice is executed before an authentication

advice, clients may be able to get access to resources without first authenticating

themselves.

3 The COF Consistency Framework

In this section we discuss the design of a consistency framework (COF) that is

designed to address threats to consistency such as those exemplified in Section 2. The

fundamental strategy of COF is to guard against inconsistent reconfiguration by

using:

• a threat taxonomy to identify and classify the various threats associated with

dynamic reconfiguration;

• a toolkit of solutions, made available as a set of threat resolution aspects, to

resolve inconsistencies arising from dynamic reconfigurations, together with a

set of common join points in AOM implementations at which the threat

resolution aspects are woven.

We first introduce the underlying threat taxonomy that is used by COF and then

discuss the threat resolution aspects (or ‘threat aspects’ for short) used to tackle

potential reconfiguration inconsistencies identified in the taxonomy.

3.1 The Threat Taxonomy

Based on our investigations of reconfiguration case-studies such as that outlined in

Section 2, we derive a taxonomy of threats to consistency during the reconfiguration

process. Figure 2 illustrates that the threats are classified in three orthogonal

dimensions, according to how the threat is introduced into the system:

o User-induced threats. These refer to threats introduced to the system by the

reconfiguration agent which initiates and controls reconfigurations; this can be the

system developer/administrator, or software runtime code initiated by some

authority manager (e.g. in self-managed systems).

o Operating environment induced threats. These relate to reconfiguration

inconsistencies that occur due to the instability of the underlying distributed

environment in which the reconfiguration takes place. For example, failures or

unavailability of infrastructure services and communication services during the

reconfiguration process can lead to partial or failed reconfigurations.

o Compositionally induced threats. These relate to faulty interactions, following

reconfiguration, between the newly-reconfigured entities and prior non-

reconfigured entities. The associated threats typically involve conflicts and

dependencies: conflicts are threats causing negative interactions between system

entities; while a dependency threat relates to a ‘required’ relationship that needs to

be associated with the reconfiguration for the system to operate correctly.

Fig. 2. COF’s threat taxonomy dimensions

3.2 Threat Aspects

The essence of our approach to address the threats identified in the taxonomy is

through the use of aspects. In general terms, aspects tackle interdependency issues by

focusing on the systematic identification, representation and composition of (often

crosscutting) ‘concerns’ throughout the software development process. The use of aspects

allows the weaving and unweaving of independently consistent services to the system.

In our case, therefore, consistency threats are resolved by weaving a set of ‘threat

aspects’ into AOM platforms. Figure 3 presents a generalised model of an AOM

platform and identifies a set of core join points at which COF threat aspects may be

woven (examples are given later in this section). The figure demonstrates that threat

aspect composition is performed mainly at the “bottom” (at join points 4 and 5 in

Figure 3) or the “top” (at join point 1) of the AOM architecture. While this approach

appears simple, we believe it allows COF to be flexibly applied to a range of

middleware technologies, as illustrated in section 4.

Attached to each deployed threat aspect is meta-data that describes and explains its

functionality. This is used to inform the selection and deployment of the threat

aspect—e.g. to help manage compositional and dependency conflicts (again,

examples follow later). Importantly, threat aspects are configured into a given system

based upon currently-applying consistency requirements and environmental

conditions; their configuration can easily be changed if requirements and conditions

change. Hence, the approach is highly flexible and extensible.

We next return to the most important threats identified across the three dimensions

of the threat taxonomy, and illustrate how threat aspects can be devised and deployed

to resolve these problems. While we do not claim this to be an exhaustive list, we

believe it to be strongly indicative of the challenges that must be addressed.

Fig.3. Generalised COF join point model for AOM platforms

3.2.1 User Induced Threats

As described in section 2, important examples of the user induced threats are: (i)

badly formed requests, (ii) unauthorised requests, and (iii) simultaneous requests.

To resolve badly formed requests a reconfiguration validator aspect is woven as a

before advice at the AOM platform’s reconfiguration interface (join point 1 in Figure

3); this validates the reconfiguration script against policies to ascertain the correctness

of the reconfiguration operation. Reconfiguration scripts are normally either XML

based or programmable [19]. Hence, there will be different versions of the aspect:

XML schemas can be used to check if XML scripts are well-formed [12];

programmable scripts are verified using policies [10]. The aspect causes bad requests

to raise an exception to the reconfiguration agent and allows only valid requests to

proceed.

Unauthorised reconfigurations can be addressed by deploying an authentication

aspect as before advice at the AOM platform’s communication interface (join point

4); this ensures only authentic users can adapt the system. In an untrusted

environment, additional encryption and decryption aspects can be woven at the

communication interfaces of the sender and receiver (for example, public or private

cryptography algorithms can be used).

Lastly, to prevent inconsistencies arising from simultaneous reconfigurations a

distributed concurrency aspect can be deployed as an around advice at join point 1

and 4 so that each reconfiguration request is isolated within a critical section. The

‘before’ part of the advice allows the request to proceed if there are no active requests

and locks the critical section; concurrent requests are then blocked until the ‘after’

section of the advice releases the lock.

3.2.2 Operating Environment Induced Threats

As discussed above, operating environment induced threats to distributed

reconfiguration consistency can arise from a number of different sources, for example

in terms of: (i) application node failures, (ii) infrastructure server failures, and (iii)

communication failures. The various threat aspects solutions are discussed below.

To handle application node failures a transaction aspect can be woven at the

communication interface (join point 5) to detect local node disruptions and provide

consensual decision making on what to do when these occur (e.g. accept the partial

failure or roll back). Based on application requirements and environmental conditions,

several variations of this threat aspect can be employed. For example a traditional

two-phase commit protocol implementation can support all-or-nothing behaviour

across all involved nodes, but its weakness is that it is prone to the failure of its

‘coordinator’ node (the node initiating reconfiguration). Such a failure may mean that

locks applied to other nodes may never be released. To avoid this eventuality, a three-

phase commit protocol implementation could be applied which employs multiple

coordinators (e.g., elected by the initiator node) and thus avoids coordinator failure

with a high degree of confidence. However, three-phase commit is vulnerable to the

threat of network partition (i.e. one set of nodes might apply the reconfiguration while

another might roll back). To avoid this, other protocols such as Paxos [29] or

Chandra-Toueg [6] can be applied—but with greater messaging overheads.

Infrastructure service failures can be resolved by deploying monitoring aspects

to monitor the liveliness of infrastructure repositories, and to employ replication and

load balancing strategies [20] to minimise the likelihood of inconsistencies. These

threat aspects would again be woven at the interface to the infrastructure services

(join point 3). Note again that there is a trade-off here between consistency and

incurred overhead. In particular, a number of replication algorithms encapsulated as

threat aspects could be used to ensure maximum aspect availability and consistency

during updates—e.g. the Coda [23] or Bayou [8] algorithms or more advanced

algorithms which consider specific application and context requirements (e.g.

Beloued [3]).

To handle Communication failures a reliability threat aspect can be woven at join

points 4 and 5 to create a reliable communication service; this could be composed of

two advices and a ‘message store’. The first advice—a ‘before’ advice at joint point 4

could have the task of piggybacking reliability information to the message before it is

sent. The second advice—a ‘before’ advice at join point 5—could monitor incoming

messages (and cache them in the message store), and detect any losses within the

transmission sequence, asking for the lost messages to be resent.

3.2.3 Compositionally Induced Threats

The most common compositionally induced threats are in terms of (i) dependency

inconsistencies, (ii) unsynchronised binding of distributed aspects, and (iii) semantic

conflicts and ordering inconsistencies. Typical threat aspects that can be applied in

this dimension are discussed below.

To address dependency inconsistencies a transaction aspect can be applied.

Dependent aspects are serialised as sub-transactions such that dependees are woven

first in one sub-transaction, followed by further sub-transactions in which the

dependents are woven.

Unsynchronised unbinding of distributed aspects can be addressed by

introducing a caretaker aspect that proxies the aspect being reconfigured; on

receiving a message from a client, the caretaker would tell the client that the aspect

has been removed. Subsequently the client can remove the referenced aspect so that it

does not attempt to invoke the aspect in the future.

Finally, to resolve semantic conflicts between aspects a semantic reasoning and

resolution aspect (e.g. [10]) can be applied at join points 1 and 4. This would work by

holding application-specific metadata about which aspect-related actions (e.g. in

terms of addition and removal of aspects) are allowed and not allowed when

reconfiguration is performed. Using reflection, this aspect would identify the aspect(s)

woven at a given join point and determine if adding or removing the aspect will cause

inconsistency. For detected conflicts an exception would be raised and the

reconfiguration aborted.

4 Applying the Consistency Framework to Real AOM Platforms

In this section, we describe how COF can be applied to three representative AOM

platforms—specifically, AO-OpenCom [24], JAC [22] and DyReS [27]. The three

platforms constitute a spectrum of types of AOM as classified by the AO Middleware

Reference Architecture [14] along the dimension of richness of distributed

compositionality. In particular, AO-OpenCom offers composition with remote

advices and pointcuts; JAC uses distributed composition through remote pointcuts

only; and DyReS offers no support for distributed composition.

In each case, we first provide a brief description of relevant elements of the

platform; then we assess the platform’s native support for consistency in the face of

dynamic reconfigurations as measured against COF; and finally we show how we

have applied COF to the framework in question to enhance its consistency.

4.1 AO-OpenCom

AO-OpenCom is an AOM platform that builds on the OpenCom component model

[7]. Aspect composition in AO-OpenCom employs components to play the role of

aspects—i.e. an aspect is simply an OpenCom component1. Aspects are composed at

1 Hereafter we use the term aspect-component when referring to an OpenCom component that

is playing the role of an aspect.

run-time using so-called interceptor-connectors, which are specialised OpenCom

connectors2 that support the dynamic insertion of aspect-components. OpenCom is

programming language independent, so AO-OpenCom employs a language-

independent XML-based point cut language. An early version of AO-OpenCom was

the subject of a prior paper [24].

Fig. 4. The AO-OpenCom AOM platform architecture

Dynamic reconfiguration in AO-OpenCom works by submitting a request, in the form

of an aspect specification(s) and associated a point cut, to a run-time Configurator

service, an instance of which runs on every node in a distributed AO-OpenCom

instance. The Configurator then talks to its peer Configurators on other nodes to

realise the requested reconfiguration by adding, removing and replacing aspects. A

pluggable per-node Distribution Framework is used to distribute requests among

participating nodes (it is also used to distribute meta-data such as node membership

data). Figure 4 illustrates the per-node machinery used by AO-OpenCom. As can be

seen, each Configurator interacts with its local Pointcut Evaluator and Advice

Handler to carry out the requested reconfiguration on its local node. The Aspect

Repository holds a set of instantiable aspect-components; this is itself a ‘component

framework’ (CF) [7] which supports a front-end Proxy Gateway component and a

back-end Database component3. Finally, the Pointcut Evaluator evaluates pointcuts

and returns a list of matching join points within the local node; and the Aspect

Handler actually weaves advices at specified join points.

Consistency Management in AO-OpenCom. In the absence of COF, AO-

OpenCom only undertakes to ensure that relevant parts of the system are made

quiescent [17] before weaving is initiated—i.e. it ensures that the weaving/unweaving

of aspects is not carried out while affected component/aspect-components/connectors

are actively processing calls. Because of the strictly stylised composition approach

offered by aspect-orientation, achieving quiescence is a relatively straightforward task

compared to non-AO-based systems. More specifically, quiescence is achieved

simply by freezing the start of the chain of interceptors in an interceptor-connector

(i.e. the interceptors that correspond to the advices of the to-be-(un)woven aspects) to

2 In OpenCom ‘connectors’ are used to bind together the required and provided interfaces of

interacting components. 3 This sub-CF architecture enables a wide range of configuration options: for example,

different front-ends can apply different load balancing strategies; or some Database

components can be proxies to other front-ends.

prevent new threads entering, and then waiting for any currently-executing threads to

drain from the interceptor chain. Apart from this mechanism, there is no further

support for consistency in the ‘basic’ AO-OpenCom platform.

Applying COF to AO-OpenCom. COF is applied to AO-OpenCom by weaving

a COF Manager component with the Configurator so that whenever a reconfiguration

operation is submitted, the COF Manager can check what threats (if any) the

application wants to guard against and can ensure that the appropriate machinery (in

terms of threat aspects) is in place and applied. We have implemented a

comprehensive set of threat aspects for AO-OpenCom along the lines of the example

threat aspects discussed in Section 3. We now discuss the specifics of our

implementations of these and how they are applied within AO-OpenCom:

• User-induced threat aspects: Our script validator aspect ensures that

reconfiguration requests are internally self-consistent; it is woven at join points4 1

and 4 as ‘before’ advice. At join point 1 we can intercept reconfiguration requests

coming from the local node, and at join point 4 we can intercept requests coming

from peer Configurators across the network. Our authorisation and encryption

security aspects prevent unauthorised remote nodes from initiating reconfiguration

requests and to ensure confidentiality. The weaving order of these aspects is

crucial: authentication should come before confidentiality. The authorisation

aspect is woven as a ‘before’ advice at join points 4 and 5 (i.e. at the top of the

communications stack, at which level authorisation information can be inserted in

outgoing packets and is available in incoming packets). We also use a

confidentiality aspect that encrypts the arguments of method calls as they are

passed through the communication stack. This is achieved by weaving an

encryption advice as a ‘before’ advice at join point 5 and a decryption advice at

join point 4, also as a ‘before’ advice. Finally, our distributed read/write

concurrency aspect ensures that simultaneous reconfiguration requests do not

interfere with each another; this is woven at join point 1 so that requests from the

local node can be held back while remotely-initiated requests are being processed;

and at joint point 4 to hold back further remotely-initiated requests when one is

already being processed.

• Operating environment induced threat aspects: Our consensus threat aspect

ensures that local node failures or communication disruptions do not compromise

the consistency of the system. It uses a two-phase commit protocol and is again

woven at the top of the communications stack (join points 4 and 5). Our

replication aspect ensures the liveliness of the Aspect Repository infrastructure

service; this is woven at join point 3 as ‘around’ advice so as to be capable of

replicating and redirecting calls made to the Aspect Repository. We also provide

two auxiliary threat aspects for use in conjunction with this: a load balancer

aspect guards against individual replicants being overloaded (this is woven at join

point 3 as a ‘before’ advice as it only needs to catch calls, not returns); and a

concurrency management aspect that prevents version-conflict inconsistencies

across replicants (this is woven as a ‘before’ advice at join point 7 to intercept

calls on the Aspect Repository instance’s internal database). Finally, our reliability

4 When discussing this weaving, the following paragraphs refer to the numbered join points, 1-

8, within the AO-OpenCom CF that were illustrated in Figure 4.

aspect ensures that reconfiguration messages are not lost by using a wireless-

friendly retransmission strategy. This is once more woven at the top of the

communications stack.

• Compositional induced threat aspects: Our transaction management concurrency

aspect, used to preserve compositional dependencies, employs the Saga

transaction model [11] and is again woven as a ‘before’ advice at the top of the

communications stack. It allows dependent aspects to be divided into a sequence

of sub-transactional aspects, each of which manages an associated compensating

sub-transaction that can be triggered to undo the effects of the committed sub-

transaction aspect in case one fails. Our proxy caretaker aspect to take the case of

orphaned remote aspects (again, refer to Section 3); this is woven in front of

proxies to remote aspects. When a remote client (connector) attempts to invoke

this removed aspect, the proxy caretaker aspect is invoked instead which redirects

and informs the remote connector that the referenced aspect has been removed. To

avoid the connector from invoking the aspect in the future, it removes the remote

aspect reference from its interceptor chain when it receives the ‘remove reference’

message. And finally, our policy semantic aspect, woven at join points 1 and 4,

detects semantic inconsistencies using reflection. It identifies aspect(s) woven at a

target join point and determines if adding or removing the aspect will cause any

inconsistencies. For detected conflicts an exception is raised and the

reconfiguration is aborted.

4.2 Java Aspect Components (JAC)

JAC is a Java-based AOM platform that uses aspects to implement distribution

services. It supports a notion of ‘distributed aspects’ by replicating local aspects

across sets of hosts and ensuring that the states of these are kept synchronised. That is,

it does not support true remote aspects as AO-OpenCom does.

To initiate a dynamic reconfiguration, the JAC programmer provides an XML-

based application descriptor file and an aspect configuration file to the Parser module

(see Figure 5). This is somewhat similar to the mechanisms described above for AO-

OpenCom. The application description contains a reconfiguration script, while the

aspect configuration file provides necessary information to support the instantiation of

aspects obtained from the Aspect Repository. Reconfiguration is different depending

on whether local or distributed reconfiguration is requested. If the reconfiguration is

local, newly-instantiated aspects are passed to the AC-Manager. Otherwise, for

distributed reconfiguration, the request is first passed through the Deployment Aspect

which forwards it to the AC-Manager to perform the local part of the reconfiguration,

and to the Distributed Protocol aspect for the reconfiguration to be replicated across

nodes. Each replicated node contains an instance of the AC-Manager, which uses the

Java class Loader (BCEL) to retrieve base object classes; and uses byte-code

rewriting to insert hooks to base objects (to enable the AC-Manager to attach aspect-

components to the hook).

Fig. 5. The JAC AOM platform architecture

Consistency Management in JAC. The existing JAC framework offers two

consistency mechanisms natively. First the framework ensures mirrored aspect copies

are kept synchronised using the Distributed Protocol aspect. The other mechanism is

through the use of a composition aspect, ensuring inter-aspect global ordering of

aspects. The global aspect ordering semantic ensures whenever an aspect position is

changed in the chain in one node, the same order position is replicated across nodes.

Applying COF to JAC. To provide consistent reconfiguration, COF is applied in

a similar manner to that already shown for AO-OpenCom. A notable difference

between JAC and AO-OpenCom exists, however, in the aspect-composition model. In

JAC, the reconfigured entity is a set of Java objects that require byte-code

manipulation before the aspects can be woven in the runtime. Weaving is performed

on a per-class basis, hence the time that objects are not able to serve requests is longer

compared to blocking an interceptor chain in AO-OpenCom. Moreover, JAC offers

no quiescence mechanism, therefore our COF implementation implements suitable

locking operations over aspects, objects or classes that need to be reconfigured.

Another limitation of JAC is that the aspect model does not provide around advices.

Despite the above differences in the JAC platform all of the above-identified COF

threat aspects have been successfully deployed in JAC with the exception of the

caretaker aspect. This is not required as JAC does not support remote aspect

weaving/unweaving.

4.3 DyReS

DyReS is an AOM platform that can be deployed on top of two alternative lower

layers: the JBOSS dynamic AOP [5] and Spring AOP [2]. The key contribution of

DyReS is to offer coordinated dynamic reconfiguration on top of these platforms

through the use of the NeCoMan coordination protocol [16], which aims to provide a

degree of consistency management The DyReS architecture is illustrated in Figure 6.

To start a distributed reconfiguration, reconfiguration scripts are sent to all nodes

involved in the reconfiguration. At each node, the DyReS Facade accepts instances of

this script and forwards them to the Script Interpreter which parses the script and

delegates reconfiguration sub-operations to the Reconfigurator. This latter contains

AO-framework-specific implementations of lower-level reconfiguration APIs’

operations. For instance, for Spring AOP, Spring’s XMLBeanFactory API is used;

and for JBOSS AOP the AspectManager API is used with the associated predefined

hooks in the frameworks. The Reconfigurator supports nine reconfiguration

operations and two synchronisation primitives: wait and notify. Wait blocks the

ongoing reconfiguration process until ‘notify’ messages are received from specified

nodes to certify that the to-be-reconfigured aspects on those nodes are in a quiescent

state; and notify sends a synchronisation message to a specified node to allow

reconfiguration on that node to proceed. The details of the reconfiguration operations

are based on Kramer and Magee’s approach and are discussed in more detail in [27].

Fig. 6. The DyReS AOM platform architecture

Consistency Management in DyReS. DyReS tackles dependency threats within

the compositionally-induced threat dimension; however, semantic and ordering

threats are not addressed. Moreover, threats in both the user induced and operating

environment induced dimensions are not addressed by the framework.

Applying COF to DyReS. To provide consistent reconfiguration in DyReS we

have woven the COF Manager with the DyReS Reconfigurator as shown in Figure 6.

In DyReS the middleware architecture is tightly bound to the different AO framework

specific implementations, such that the join point model is determined by the

underlying AO framework. We have implemented the COF Manager in DyReS

similar to our AO-OpenCom implementation but with the following key differences.

First, our DyReS implementation does not use an equivalent of AO-OpenCom’s

transaction management concurrency aspect; this is because DyReS already uses the

NeCoMan coordination protocol by default to preserve the compositional dependency

threat. Second, DyReS does not offer infrastructures services and remote aspect

bindings; hence the COF Manager does not deploy threat aspects to address these

particular threats. Finally, in DyReS the programmer is responsible for providing a

reconfiguration script to each node involved in the reconfiguration. Hence, because

scripts are not sent across the network, the authentication aspect is not applicable.

5 Evaluation

5.1 Qualitative Evaluation

On the basis of our experience of implementing COF in AO-OpenCom, JAC and

DyReS, we now evaluate it against the three criteria outlined in the introduction: i.e.,

flexibility, configurability and transparency. In terms of flexibility, we have

demonstrated that COF can address a wide range of consistency threats in a cross-

platform manner—i.e. by implementing a representative set of threat aspects over

three different AOM platforms. In all three cases the set of join points proved to be

straightforward to identify, based on COF’s generic join point identification heuristic,

thus confirming that the design of the threat aspects is largely independent of any

particular middleware architecture. Furthermore, although we clearly do not claim

that exactly the same threat aspect implementations can be used unchanged in all

three cases, there is equally clearly a high degree of architectural uniformity. Also, it

is possible in many cases to implement the threat aspects so that platform

dependencies are isolated and minimised. For example, the authorisation threat aspect

can be separated into a platform-specific packet inspection/insertion part, and a

generic authorisation part.

In terms of configurability, our general approach benefits from the high degree of

orthogonality of the identified threat aspects. This means that arbitrary subsets of the

threat aspects can be deployed as required (e.g., as we have shown, some threat

aspects are not needed in JAC and DyReS as the associated consistency threats are

natively covered by the platform), and that the set of deployed threat aspects can be

dynamically updated (e.g. if application needs change, or the environment becomes

less or more stable). In addition, the approach to configuration can vary from a

statically pre-configured approach to a totally dynamic ‘on-demand’ approach.

However, the threat aspects are not completely orthogonal—in particular, the order in

which they are composed is still important, and executing aspects at some common

join point in a ‘wrong’ order could lead to problems (e.g. situations in which a

message needing to be processed by a particular aspect has already been consumed by

another). This ordering issue is particularly important for join points at the top of the

communication stack at which point numerous aspects are woven; for example, where

both the consensus and reliability threat aspects are woven, the reliability aspect

should come first to ensure that the consensus protocol used a reliable

communications service. In general, COF mandates a particular order for the weaving

of the threat aspects and enforces this order using attributes attached to each aspect.

Finally, in terms of transparency, COF naturally supports a selectively transparent

approach to consistency management. At one extreme, COF-based systems can be

configured so that the application programmer who wishes to initiate a run-time

reconfiguration need only to make the appropriate reconfiguration call and the COF

Manager will itself decide which threat aspects to consider, based on system policies.

This achieves complete transparency of consistency-related mechanisms. At the other

extreme, the programmer can be explicit about which threat aspects should be used

for each reconfiguration. Note that this extreme is still partially transparent as the

programmer continues to be protected by the COF Manager from the low level details

of actually managing and weaving the threat aspects.

5.2 Performance

We now assess the performance characteristics of COF in the three AOM platforms

we have considered (i.e. AO-OpenCom, JAC, and the JBOSS AOP version of

DyReS). For this we use an experimental setup based on the scenario from Section 2

(see Figure 7a). More specifically, we employ four nodes as follows: A is a server

node that streams media content to client nodes B and C; and there is also a media

repository on node D. Each node is a Core Duo 2 processor 1.8 GHz PC with 2GB

RAM and running Windows. When COF is configured, it employs the threat aspects

listed in Figure 7b, which are woven at the join points shown (see earlier for more

detail on the join points used in the three platforms). In cases where the target

platform already covers an area of consistency provision, this is omitted from the

COF deployment (see Sections 4.2 and 4.3). Based on this setup, the reconfiguration

we perform is to dynamically weave an AES [1] encryption/decryption aspect into

the application at nodes A, B and C. The assumption is that the reconfiguration is

initiated by an agent on node A.

Fig. 7. Experimental setup to evaluate COF overhead

Given this experimental setup, we carried out two experiments. The aim of the first

experiment was to assess the typical overhead of COF in performing consistent

reconfiguration. This was achieved by measuring the time taken to perform the above-

described reconfiguration in two cases—with COF and without COF—under each of

the three AOM platforms. The results5 are shown in the left-hand side of Table 1. We

can see that the base time to perform the reconfiguration without COF varies

considerably across the three platforms: AO-OpenCom is fastest, with DyReS taking

2.66 times longer, and JAC taking 4.9 times longer. The longer time taken by DyReS

over AO-OpenCom is attributed mainly to the former’s use of the NeCoMan

coordination protocol, which seems to incur a high degree of inter-node chattiness.

The significantly longer time taken by JAC appears to be as a result of its approach of

replicating aspect instances across all nodes (as discussed in Section 4.2), which again

leads to chattiness. In terms of the COF-induced overheads, AO-OpenCom, JAC and

DyReS respectively take 1.25, 1.43, and 1.36 times longer than their respective

without-COF baselines, indicating that the overheads of COF are stable across all

three implementations. Furthermore, the fact that the with-COF case for AO-

OpenCom takes less time than the without-COF case for the other two platforms, and

the fact that the with-COF case for DyReS takes less time than the without-COF case

for JAC, indicate that COF overheads seem to be well within acceptable ranges.

The aim of the second experiment was to evaluate the impact of COF on the

‘steady state’ operation of a typical application—i.e. at times when no

reconfigurations are taking place. In our case, the applicable metric is the average

latency of media stream packet transfers between nodes A and B (or C). We can see

5 We do not claim that these results are in any sense definitive. Rather, they are indicative of

the order of magnitude of overhead to be expected of COF deployments. In particular, the

numbers are specific to our implementations of the various threat aspects, and will clearly

vary with other implementations.

from the results (shown in the right-hand side of Table 1) that zero steady state

overhead was incurred for AO-OpenCom, whereas small overheads were measured

for the other two platforms (0.48% for JAC; and 0.14% for DyReS). The slight

overheads in the cases of JAC and DyReS seem to result from those threat aspects

that are woven into the communication stack: the multiplexed stack architecture used

by both of these platforms necessitates placing the communication-oriented threat

aspects on the same path as application communications6. In AO-OpenCom this does

not occur as the architecture allows us to instantiate a separate stack for COF

communications. The main point, however, is that in all three cases the overheads are

negligible, and that the results justify a conclusion that COF incurs insignificant

overheads when reconfigurations are not taking place.

Table 1. Overhead of using COF in AOM platforms

Reconfiguration Time in (ms) Steady State Latency Time (ms)

AO-OpenCom JAC DyReS AO-OpenCom JAC DyReS

Without COF 1994 9821 5311 1724 10381 5852

With COF 2495 14128 7241 1724 10431 5860

Overall, based on our experiments, we can conclude that the runtime overhead of

COF is perfectly acceptable. Furthermore, we have clarified that much of the (small)

overhead is caused by two main factors. From the first experiment we can see that

reconfiguration overhead is as much a function of the reconfiguration algorithm used

as of COF itself. And from the second experiment, we can see that the ‘steady state’

overhead of COF in significantly influenced by the underlying AOM architecture: for

COF to have a zero impact on steady state application operation, the middleware

communication stack should be separate from the application communication stack,

and/or it should be possible to remove/insert interceptor hooks at runtime.

6 Related Work

Few AOM platforms have addressed the challenges of performing consistent dynamic

reconfiguration. Damon [21] is a distributed AOM offering dynamic reconfiguration

with remote point cut and remote advice capabilities similar to AO-OpenCom.

However, the approach does not provide any consistency mechanisms for use during

reconfiguration. Similar to JAC, AWED [4] and ReflexD [25] supports dynamic

weaving/unweaving of mirrored aspects. Both AWED and ReflexD use a consistency

protocol to ensure that whenever an aspect is woven at a specific host, mirrors are

also woven at other involved hosts. However, they do not consider any other

consistency threats as discussed in the threat taxonomy. Lasagne [26] offers semantic

6 In the case of JAC, there is an additional overhead of total hook weaving, which is not

present in either AO-OpenCom or DyReS, and which means that every potential join point in

JAC is instrumented regardless of whether an aspect is currently woven into it. It is also

worth noting that both DyReS and AO-OpenCom permit interceptors to be dynamically

added/removed. This means that, if required, the overhead in the DyReS case could also be

reduced to zero by removing COF-related interceptors between reconfigurations.

consistency support to prevent dangerous combinations of aspects, and offers atomic

weaving of aspects. It also checks for unauthorised clients requesting aspect

composition. However, it does not offer solutions for operating-environment induced

threats and several other threats discussed in this paper.

We now turn to work on consistency in non-AO environments—specifically in the

space of component-based systems. Leger et al., [18] addresses the reliability threat in

such systems using a transactional ACID based approach. However the approach does

not cover other operating environment induced threats or any threats from the other

dimensions. Other prominent works in the component-based domain are OpenRec

[15], Draco [28] and K-Components [9]. OpenRec and Draco address only the

compositionally induced threat dimension, with the OpenRec framework offering a

flexible way of modifying reconfiguration algorithms at runtime. K-Component offers

a decentralised coordination reconfiguration, allowing reconfiguration to take place

on each local node based on the operating environment; however, it does not consider

threats occurring from the compositional induced threat dimension.

7 Conclusions

In this paper we have presented a framework-based approach to consistency

maintenance over dynamic reconfiguration operations in AOM platforms. Our COF

framework classifies important consistency threats in three orthogonal dimensions,

and identifies a range of problems and solutions in each of these dimensions. We

believe that our threat taxonomy is representative of the type of threats that should be

considered by all dynamic AOP platforms. Importantly, COF applies an aspect-

oriented approach to consistency management, so the solutions it identifies are

described in terms of ‘threat aspects’ and can be applied using the native

compositional model of the target AOM platform. The framework also offers

heuristic principles that guide the selection of join points at which threat aspects

should be woven in a range of AOM platforms.

We claim that COF has the following important benefits. First, COF is flexible in

being applicable to a range of AOM platforms, as we have demonstrated for AO-

OpenCom, JAC and DyReS. We also believe that there is considerable potential for

applying COF to non-AO dynamically reconfigurable middleware environments.

Second, COF is configurable in that appropriate threat aspects can be dynamically

woven and unwoven according to the types of threat and environmental conditions

currently pertaining. Furthermore, because the threat classification results in the

identification of inherently orthogonal threat aspects, we believe that the approach

should be relatively straightforward to extend with new, currently unforeseen, threat

aspects. And, third, COF is transparent in that consistency maintenance issues can be

hidden from the application programmer. In addition we have shown, for realistic

deployments in our three example AOM environments, that COF imposes very

reasonable overheads in terms of the time taken to carry out a given reconfiguration;

and that it incurs little or zero overhead on steady state application execution when no

reconfigurations are taking place. In future work, there are two main research

directions that we would like to investigate. First, we plan to investigate embedding

our approach in a self-managing, autonomic environment in which reconfiguration

requests are initiated by the platform itself as opposed to the user. Second, we plan to

integrate COF with modelling tools that can support the developer in designing,

evaluating and validating the consistency implications of complex aspect

reconfigurations before they are deployed in a system.

References

1. AES Encryption, http://en.wikipedia.org/wiki/Advanced_Encryption_Standard.

2. Spring website. http://www.springframework.org/.

3. Beloued, A., et al., “Dynamic data replication and consistency in mobile environments”,

Proceedings of the 2nd international doctoral symposium on Middleware, ACM, 2005.

4. Benavides, et al., “Explicitly distributed AOP using AWED”, AOSD, Germany, 2006.

5. Burke, B., “JBoss AOP Tutorial”, 3rd Conference on AOSD, Lancaster UK, 2004.

6. Chandra, T., “Unreliable Failure Detectors for Reliable Distributed Systems”, ACM, 1985.

7. Coulson, G., et al., “A Generic Component Model for Building Systems Software”, ACM

Transactions on Computer Systems, February 2008.

8. Demers, A., et al., “The bayou architecture: Support for data sharing among mobile users.”

In Proceedings IEEE Workshop on Mobile Computing, pages 2-7, 1994.

9. Dowling, J., “The Decentralised Coordination of Self-Adaptive Components for

Autonomic Distributed Systems”. PhD Thesis, Trinity College Dublin, 2004.

10. Durr, P., et al., “Reasoning About Semantic Conflicts between Aspects”. IWSA, 2005.

11. Garcia, H., Salem, K., “Sagas”, ACM Conference on Management of Data, 1987.

12. Gomes, A.T., et al., “Architecting Dynamic Reconfiguration in Dependable Systems”,

Architecting Dependable Systems IV”, LNCS 2007.

13. Goudarzi., M., “Consistency preserving dynamic reconfiguration of distributed systems.”

PhD. thesis, Imperial College, London, March 1999.

14. Greenwood, P., et al., “Reference Architecture V3”. AOSD-Europe Deliverable D106, '08.

15. Hillman, J., et al., “An Open Framework for Dynamic Reconfiguration”. ICSE, 2004.

16. Janssens, N., et al., “NeCoMan: middleware for safe distributed-service adaptation in

programmable networks”, Distributed Systems Online, IEEE 2005.

17. Kramer, .J, “The evolving philosophers problem”, IEEE Transactions Sofware Eng., 1990.

18. Leger, M., et al., “Reliable dynamic reconfigurations in the fractal component model”.

Proceedings of the 6th international workshop on ARM, 2007.

19. Loughran, L., et al, “Survey of Aspect-Oriented Middleware”, AOSD-Europe Deliverable

D8, June 2005.

20. Minson, R., “Adaptive Support of Range Queries via Push-Pull Algorithms”, ADS, 2007.

21. Mondejar, R. “Designing a distributed AOP runtime composition model”, ACM

symposium on Applied Computing, 2009.

22. Pawlak, R., et al., “JAC: A Flexible Solution for AOP in Java”. In Proc. Reflection, 2001.

23. Satyanarayanan, M., “Coda: A highly available system for a distributed workstation

environment.” IEEE Trans. Computing, 39(4) pg. 447-459, 1990.

24. Surajbali, B., Coulson, C., Greenwood, P., and Grace, P. “Augmenting reflective

middleware with an aspect orientation support layer. 6th Workshop ARM, 2007.

25. Tanter, E., Toledo, R., “A Versatile Kernel for Distributed AOP”. DAIS, June 2006.

26. Truyen, E., Wouter, J., "Run-time and Atomic Weaving of Distributed Aspects", In

Transactions on AOSD Vol II, Lecture Notes in Computer Science, 2006.

27. Truyen, E., et al., “Support for distributed adaptations in AOM”, AOSD, April 2008.

28. Vandewoude, Y., “An alternative to Quiescence: Tranquillity”, Software Maintenance,'06.

29. Zielinski, P., “Paxos at war”. Technical Report, University of Cambridge, 2004.