=Paper=
{{Paper
|id=None
|storemode=property
|title=ReCycle: Resolving Cyclic Dependencies in Dynamically Reconfigurable Aspect Oriented Middleware.
|pdfUrl=https://ceur-ws.org/Vol-564/compositionvariability2010_submission_5.pdf
|volume=Vol-564
}}
==ReCycle: Resolving Cyclic Dependencies in Dynamically Reconfigurable Aspect Oriented Middleware.==
https://ceur-ws.org/Vol-564/compositionvariability2010_submission_5.pdf
ReCycle: Resolving Cyclic Dependencies in Dynamically
Reconfigurable Aspect Oriented Middleware
Bholanathsingh Surajbali, Paul Grace and Geoff Coulson
Computing Department,
Lancaster University
Lancaster, UK
{b.surajbali, p.grace geoff} @comp.lancs.ac.uk
ABSTRACT invasively at their connector (between the required and provided
In aspect-oriented middleware systems, the aspect modules are interfaces of the base software components) in advice chains with
typically composed as chains of aspects within the connectors (or the aspect reference stored in the advice chain. Then, the aspects
bindings) that join the base software components. However, this are invoked from the connector chain when a call or execution
approach can lose or hide information about the dependencies occurs from the call or execution of the provided or required
between multiple aspects in the chain; this is particularly interface.
important when dynamically reconfiguring such a system at run- Unlike components, the dependency of an aspect to another
time. Without knowledge of these dependencies the system could aspect is not explicitly defined, such that an aspect within a chain
reconfigure a new aspect with a dependency to a prior aspect in may have a dependency with another aspect located earlier in the
the chain resulting in a cyclic dependency and subsequent chain, and cause a cyclic dependency while performing
deadlock. Furthermore, the problem is harder to detect with the reconfiguration. The potential problem of cyclic dependency is
presence of remote aspects within the connectors as their that it may cause the running system to enter into a deadlock after
dependencies are hidden across address spaces. To resolve cyclic performing reconfiguration, when an invocation occurs at the join
dependencies that may occur when reconfiguring both local and point. The cyclic dependency problem is hard to detect since an
remote aspects we propose the use of a reconfiguration cyclic AO-Connector, maintains both local and remote advices. For an
dependency resolution (ReCycle) model. This approach can be AO-Connector containing solely local advices, inspection of the
employed generally in dynamic AOP middleware platforms, and AO-Connector can reveal the possibility of cyclic dependencies.
in this paper we evaluate it within the AO-OpenCom middleware. However, this is non-trivial when the AO-Connector contains
both local and remote advices, since for remote advices the
visibility of the methods invoked by remote advices is located in
Categories and Subject Descriptors the remote address space from where the AO-Connector is.
D.2.11 [Software Engineering]: D.2.11 Software Architectures In this paper, we present a reconfiguration cyclic dependency
– Languages (interconnection), Patterns. resolution (ReCycle) model for dynamic aspect-oriented,
component-based middleware; this provides the capability to
General Terms describe the various kinds of built-in dependency inconsistencies
Design, Management that affect aspect configuration and reconfiguration at runtime.
This is coupled with a graph-based tool which detects and
resolves cyclic dependency inconsistencies at run-time while
Keywords reconfiguration is performed.
Middleware, dependency, aspect, dynamic reconfiguration. We evaluate our approach within the AO-OpenCom platform
for developing dynamic reconfigurable middleware solutions; this
1. INTRODUCTION demonstrates the following contributions of our approach:
Aspect-oriented middleware platforms provide solutions to create • Resolution of reconfiguration cyclic dependency. We show
distributed component-based systems into which aspect modules that cyclic dependency inconsistencies can be resolved for one
representing cross-cutting concerns can be woven. Aspects are case-study with minimal performance overhead.
made up of individual code elements that implement the concern
(advices), which are deployed at multiple positions in a • Transparency. We apply consistent reconfiguration with
distributed system (join points) that are expressed by pointcuts—a minimal developer effort or change to the underlying
particular form of composition language. AO-OpenCom[11], component model.
AspectOpenCom[4] ,CAM/DAOP [3], FAC [9], FuseJ [13],
DyMAC [5], and DyReS [14] are examples of aspect-oriented • Flexibility. New dependency consistency can be described
middleware which allow aspects to be composed and adapted at dynamically to evolve with the running application or domain
runtime. The aspect runtime composition of aspects in such AO context without breaking the implementation details of the
middleware platforms differs from the standard component to instantiated aspect. Moreover, the approach can be applied in
component binding (where there is a direct reference from the different compositions approaches and tools; for example we
provided interface to the required interface). In these AO show how both node-local and distributed reconfiguration
middleware aspects are advice components which are woven non- cyclic dependency consistency can be avoided in this paper.
The remainder of this paper is organised as follows. Section 2 ii.) Selection of the transportation. Transport selection creates a
examines the types of aspect reconfiguration cyclic dependency transport listener and transport request and binds them to a
that may occur. Then, section 3 describes the design of our socket.
ReCycle model, followed by section 4 which validates the iii.) Deployment handler for the message transfer. The
proposed ReCycle model. Finally we describe related work in deployment handler creates the skeleton and binding for the
section 5 and offer our conclusions in section 6. message transfer as well extracting the object name in the
URI to lookup the correct instance in case of a normal
2. ASPECT RECONFIGURATION method call.
In aspect-component middleware, aspects (which are themselves
implemented as component modules) are composed with the base
components (hereafter termed components) using AO-Connectors
[4, 8, 11, 12, 14]. AO-Connectors are the architectural element
offering aspectual composition (weaving) of aspects between a
receptacle and a provided interface of components. AO-
Connectors maintain the meta-data containing references to
aspects instances in an advice chain. For example, it maintains
details of all advised aspects and their types and allows these to be Figure 2: Distribution Stack AO Composition scenario
queried to determine the operations they support and the aspects
currently advising them. It also supports the runtime manipulation Whenever, the Message Handler component calls the
of the chain to add a new advice, or remove or reorder aspects in Communication Module, the list of advices within AO-Connector
the chain of advices. chain gets invoked and executed in the following order:
Format Selection Aspect → Transport Selection Aspect →
Deployment Handler Aspect.
2.2 Cyclic Dependency Occurrence
To cope with the application and environmental demand the
following two dynamic (re)configurations may be required: (i)
new users with limited bandwidth may join, requiring a
Compression aspect to be configured to split data before being
sent; (ii) data may be required to be encrypted using a Security
aspect to protect the users’ privacy.
Figure 1: Aspect-Component Model
A list of advices is attached to the connector between the required
and the provided interface. This capability is illustrated in Figure
1, which shows a caller component connected to a callee
component, and an AO-Connector containing a list of aspects that
get called. Where a call comes from the caller component (arrows
marked CR) then the aspects in the chain are executed first or
otherwise in case an execution is triggered from the Callee
component, the aspect chain is executed in the reverse order, as
highlighted with arrows marked CE) in Figure 1.
We now identify and classify the types of dependency
inconsistencies that can occur in the aspect-component model. Figure 3: Reconfiguration with Cyclic Dependency
Occurrence
2.1 Use case scenario The reconfiguration proceeds by weaving the Compression Aspect
To motivate the requirement to resolve cyclic dependency for AO after the Deployment Handler Aspect in the AO Connector chain
reconfiguration we present its occurrence within the distribution and the Security Aspect woven after the compression aspect in the
framework stack. The AO composition is as follows (see Figure chain, as illustrated in Figure 3. However, both the Compression
2): when the message handler is called on the communication aspect and the Security Aspect may have a dependency on the
module, the following aspects are enforced, before the execution Format Selection aspect prior to the reconfiguration, causing
of the communication module operation: cyclic dependencies to occur at the AO Connector such that calls
i.) Selecting the format of transportation. Format selection may not return back to the Security Aspect, causing a deadlock to
handles the formatting of the message such that it can be occur if the reconfiguration is allowed to proceed. The cyclic call
serialised and deserialised for remote invocations and replies. dependency for Figure 3 when called proceeds as follows:
Format Selection Aspect → Transport Selection Aspect → The aspect-instance defines the aspect-component instance aspect
Deployment Handler Aspect → Compression Aspect → Format scope, list of aspect required interfaces of the aspect-component
Selection Aspect. instance and list of provided interfaces for the aspect-component.
Aspect-dependency defines the list of aspect-instance aspect-
A more complicated cyclic dependency occurrence is when
type to which the aspect is dependent on as well as the AO-
remote aspects are attached to the AO-Connector. In the case of
connector to which it is currently bound with.
remote aspects, they may have dependencies with other aspects
The aspect scope refers to the aspect-component instance of
located on different address spaces, causing the dependency to be
whether it is deployed on the local host, or is remote.
unnoticed while performing reconfiguration.
The AO-Connectors tag refers to the list of connectors to
which the aspect-component instance or type is bound with. This
2.3 Analysis
can be zero in case there is no connection dependency for the
An aspect represents a crosscutting functionality that may be
aspect-component.
referenced and shared by other software modules in a running
system. That is AO middleware typically just add/reconfigure at 3.2 Attaching Metadata
runtime without knowledge of the chain or taking into
As described in our previous work in [12] tagged metadata needs
consideration the existing aspects dependencies that may already
to be kept separate from the main source functionality. This is
be present. So doing, as described above, can potentially lead to
because:
cyclic dependencies. Furthermore, creating two versions of the
1. aspect-components are considered as black-boxes which
aspect by replicating the aspect functionality is not a feasible
provide advices in the form of operations within the provided
solution either and can potentially result in an exponential growth
interface (but hide their implementation);
in versions of the same aspect. To solve the above problems, we
2. aspects represent crosscutting functionality such that adding
propose the ReCycle model.
descriptions by extending the implementation, e.g. through a
new interface, will restrict its applicability to different
3. ReCycle: RECONFIGURAION CYCLIC applications and domains because it couples the consistency
DEPENDENCY RESOLUTION MODEL checking with the aspect-component functionality.
In this section we describe our ReCycle model to support the Keeping metadata separate allows both the core functionality and
detection of cyclic dependencies that may result in the metadata to be reconfigured independently and transparently from
configuration and reconfiguration of aspects as well as its each other.
resolution by supporting the following dimensions: (i) describing Metadata is attached to the aspect-component interfaces and
aspect dependency; (ii) attaching metadata to entities in the receptacles at load-time, as they are the only access points
aspect-component model; (iii) using graph based detection with a available to other aspect-components to be inspected and inform
resolution engine capable of parsing the AO-Connector to detect runtime decisions. Then to provide for runtime reconfiguration,
the occurrence of any cyclic dependency inconsistencies. Each of since aspect-components are invoked through their operations,
the dimensions is now examined in turn. aspect-component operations also need to be annotated. This is
because when reconfiguration is performed at runtime, already
woven aspect metadata might be required to detect cyclic
3.1 Aspect Dependency Metadata dependencies at the join point the aspect is accessed via its
In order to detect cyclic dependencies each aspect-component is operations.
attached with metadata that describes and explains its
functionality as well as the dependency they may have on other 3.3 ReCycle Model
aspect-components. This is used to inform the deployment of the A ReCycle model provides the tool to query and reason about the
aspect—i.e. to help manage compositional and reconfiguration annotated aspect-components; and resolve possible sources of
cyclic detection between aspect-components in the aspect- cyclic inconsistency that may result from a dynamic
component model as illustrated. These descriptions are written by reconfiguration. The latter retrieves the associated aspect-
the AO middleware developer in the format as illustrated in the component metadata as illustrated in Figure 5, by getting the
BNF form of Figure 4. annotation file path from the aspect-component and parsing the
Aspect Metadata file (retrieved from the Aspect Metadata
Repository) to extract respective dependencies tags for the aspect-
component (structured as described by the BNF Cycle Metadata
representation from Figure 4). Then, the ReCycle model builds a
graph using the aspect-component instance and its dependencies if
they are connected for the corresponding AO-Connector involved
with the reconfiguration. After the graph is built, the graph is
traversed from the root, the aspect-component contained in the
first-order to the end of the graph.
In case the validation is successful the reconfigured AO-
Connector, chain list is first stored in a reconfiguration repository
having transactional capabilities and the reconfiguration is then
allowed to proceed. However, in case of any cyclic dependency
Figure 4: ReCycle Model BNF Metadata representation issue found, based on the composition policy, two alternative
remedy actions can be taken by the ReCycle model in terms of:
either the ReCycle Configurator stopping reconfiguration from The Configurator manages the other components in the
proceeding by calling the rollback operation to drive the system to framework as it is responsible for accepting and handling
the state prior to when the reconfiguration started by restoring the (re)configuration requests that will apply to a set of hosts. The
AO-Connector chain from the reconfiguration repository; or if Configurator also caches join point information it receives from
appropriate resolution policies are specified these can be deployed Pointcut-Evaluators in case similar behaviour needs be applied in
by the ReCycle model and the reconfiguration can proceed (e.g. the future. The Aspect-Repository holds a set of instantiable
removing the cyclic connector or adding a null binder to return aspect-components e.g. the cache aspect, encryption aspect, etc.
the call and exiting the cyclic loop). If a connector is removed or The Pointcut-Evaluator evaluates the pointcuts provided by
updated, the associated AO-Connector meta data is updated for the Configurator and returns a list of the matching join points
the respective aspect-component (by updating the aspect found within the local address space. Finally, the Aspect-Handler
component associated AO-Connector tag meta data). acts on instructions from the Configurator to weave advices at
Moreover, to avoid the potential occurrence of semantic join points as well as supporting the invocation of remote aspects.
interactions, the Semantic Resolution model from [12] may be The main API provided by an AO-OpenCom-enabled instance
called by the ReCycle model to reason about the resolved for AO (re)configuration is as follows:
reconfiguration interaction. In case a semantic conflict is detected Configurator.reconfigure(pc, command, aspect);
and no policies are defined, the reconfiguration gets aborted by
calling the rollback operation. Otherwise if appropriate resolution The pc argument specifies a pointcut that picks out the join
is defined, the semantic valid reconfiguration is allowed to points in the target nodes at which the desired reconfiguration
proceed while ensuring with the ReCycle model it does not result should occur. The command argument offers options for the
in any cyclic dependencies. action to be taken at the indentified join points: the ‘add’ action is
used to weave the specified aspect at the join points; ‘remove’ is
used to remove it, and ‘replace’ is used to add the specified aspect
after removing an existing aspect of the same type that is assumed
to be already there. The aspect argument can be a direct reference
to a local aspect-component, or an indirect reference to an aspect
stored in an Aspect-Repository, or a reference to an already-
instantiated remotely-accessible singleton aspect. The aspect
weaving order and the type of aspect in terms of (before, after,
around) are also specified in the aspect argument.
Figure 5: ReCycle model to resolve Cyclic Dependency
Figure 6: AO-OpenCom platform Architecture
4. VALIDATION 4.2 Applying the ReCycle Model to AO-
In this section we validate our approach using AO-OpenCom
[11]. We first provide some background on AO-OpenCom and OpenCom
then validate the extent to which our ReCycle model achieves the To ensure semantic consistency, the ReCycle model and the
stated goals of cyclic dependency resolution, transparency and Composition-Policy modules are both encapsulated as aspects and
flexibility. Finally we measured the performance and resource woven at the AO-connector component join point connecting the
overhead of deploying the ReCycle model. Configurator and the pointcut evaluator component as an ‘after’
advice in the AO-OpenCom platform. Moreover, the Aspect
4.1 AO-OpenCom Metadata file of the ReCycle model is implemented in an XML
The purpose of AO-OpenCom is to build on OpenCom and its file with each aspect annotated with the path to the XML metadata
associated reflective meta-models and component frameworks file.1
architectures [2], to provide a distributed AO composition service,
and to allow aspectual compositions to be dynamically 4.3 Qualitative Validation
reconfigured. The programming model employs components to To illustrate the ReCycle model preserving reconfiguration
play the role of aspects—i.e. an aspect is simply an OpenCom consistency, we consider the use case scenario reconfiguration. To
component. The AO-OpenCom aspect framework comprises a set
of components that are instantiated across each host. The set of 1
Since AO-OpenCom also supports remote aspects [11], the respective URL path to
components is as follows (see Figure 6): the XML file Annotation Metadata Repository is provided for remote aspects.
perform the reconfiguration outlined in Section 2.1, the
application developer would provide a reconfiguration request by
writing code as shown in Figure 7 (the code is simplified for
presentational purposes).
The Configurator.reconfigure() call takes the given pointcut
and aspect specifications and also specifies that the specified
aspect should be added. This reconfiguration specification
however fails to capture the cyclic dependency by adding the two
aspects at the AO Connector as shown in Figure 3.
Figure 8: Composition Policy Example
4.3.2 Transparency
The approach naturally supports a selectively transparent
Figure 7: Aspect Reconfiguration specification example
approach as the ReCycle aspect and the Composition-Policy
aspect can be pre-configured at application start-up time so that
4.3.1 Resolution the application developer who wishes to initiate a run-time
The Security and Compression aspects in the AO-OpenCom reconfiguration needs only to make the appropriate call to
Application Repository is tagged with appropriate metadata Configurator.reconfigure(). This achieves complete transparency
describing its dependencies on other aspect-components, that is: of consistency-related mechanisms from the code to invoke a
the Security and Compression aspects interface is tagged with the reconfiguration. At the other extreme, the developer can be
location path of the xml file containing the metadata having the explicit specifying the ReCycle and Composition-Policy aspects
aspect-dependency tags specifying a corresponding Compression should be put in place for each reconfiguration. In this case, both
and Security aspects each have a dependency with the Format aspects are woven on-the-fly (if they are not already present)
Selection aspect and with an active AO-connector. before proceeding to perform the requested reconfiguration. Note
When Configurator.reconfigure() is called on the that this extreme is still partially transparent as the developer is
Configurator of one of the nodes (referred as the ‘initiator’), the protected from the low level details of actually weaving ReCycle.
latter calls the Pointcut-Evaluator to locate all the target join
points. On returning the located join points, the ReCycle aspect 4.3.3 Flexibility
gets invoked. The latter evaluates the AO-Connector to build a The use of a separate Aspect Metadata file to attach dependencies
aspect dependency graph and using the annotation metadata from of the aspect-components allows new metadata updates to be
the Format Selection aspect, the graph is updated to detect any applied without having to recompile existing source-code.
cyclic dependencies that may occur. Moreover, our approach adds the ReCycle as an independently-
In this case, a cyclic dependency is detected such that the deployable service which can be used for both local and
Cyclic Resolution Dependency Engine checks with the distributed reconfiguration. This means that ReCycle imposes no
Composition Policy or any ‘condition-action’ policies to resolve overhead when it not used, and can be dynamically
such a cyclic dependency. woven/unwoven where and when required. We also believe that
The Composition-Policy aspect, as illustrated in Figure 8 the approach, being based upon applying metadata and behaviour
specifies the ‘condition-action’ rules in terms if a cyclic at common architectural elements (i.e. interfaces), can be applied
dependency is located and aspect-instance is Security aspect, and generally to other AOM not just AO-OpenCom; indeed we see
the latter aspect has a dependency connection with a Format important future work in the deployment of our model in a wider
Selection aspect, then the connection needs to be removed, as the range of systems.
messages format are already set. (Otherwise if the connector
cannot be removed based on the Composition-Policy specification 4.4 Overhead of ReCycle
then the reconfiguration is aborted to avoid the occurrence of We next evaluate the overheads incurred by ReCycle to perform
cyclic dependency.) dynamic reconfiguration. The baseline for our experiments is as
The Cyclic Resolution Dependency Engine aspect then follows; we reconfigure aspects at one join point using AO-
instructs the AdviceHandler to remove the AO-Connector OpenCom without ReCycle (in this case there are no cyclic
connecting the Security with the Format Selection aspect, thus dependencies to detect). This was performed as follows:
resolving any potential cyclic dependencies issue for this • the compression aspect and security aspect both instantiated
reconfiguration scenario. In case remedy policies were not on a local aspect repository;
specified, the reconfiguration would be aborted with the rollback
• the compression aspect instantiated on the same local node as
operation deployed for any changes.
the join point (AO-Connector) and the security aspect
instantiated on a remote node;
• both the compression aspect and security aspect instantiated aspect could be in mutually exclusive of another. ReDac [10] uses
on separate remote nodes from the join point. a configuration framework to detect cyclic dependencies while
composing components. The configuration framework works for
Each node ran on a separate Core Duo 2 processor 1.8 GHz PC multi-threaded component. However, the approach does not
with 2GB RAM, using the Java-based version of the AO- detect cyclic dependencies in the connector component.
OpenCom platform. Each measurement was repeated ten times With respect to AOM platforms: CAM/DAOP [3], FAC [9],
and the mean value was calculated to discount anomalous results. FuseJ [13], DyMAC [5], and DyReS [14] none of the existing
The cyclic dependency algorithm used is the single-source platforms provide mechanisms to detect the occurrence of cyclic
negative-weighted acyclic-graph shortest-path algorithm [6] and dependency while composing and reconfiguring the platforms.
the results of the experiment are shown in Table 1.
It can be observed that on a single node the use of ReCycle
added an average overhead of 5.6% when no conflicts where 6. CONCLUSION AND FUTURE WORK
managed; there was an extra 8 % when aspects with a cyclic were In this paper we have demonstrated the need to consider the
woven on the node. The overhead of the ReCycle is mainly occurrence of cyclic dependencies in aspect chains to better
attributed to the use of XML and the parsing of the file structure support and ensure consistent reconfiguration in dynamic AO
before the proper metadata are retrieved, which accounts for the middleware. We have illustrated the ReCycle model, a general
extra overhead of using ReCycle when detecting cyclic approach for validating distributed dynamic reconfiguration,
dependency. catering for potential cyclic dependencies following a dynamic
distributed reconfiguration. Moreover, our solution does not
Table 1. Overhead of using ReCycle in AO-OpenCom change the implementation of the aspect-component, which would
Reconfiguration Time in (ms) result in breaking the encapsulation of its functionality; this
allows aspects dependencies to be dynamically evolving without
Reconfiguration: Setup A Setup B Setup C changing the source-code of running aspects. The essence of our
approach is that ReCycle can be encapsulated as an aspect to
Without ReCycle 390 1356 2651 resolve any occurrence of cyclic dependency at configuration and
With ReCycle with no 411 1432 2810 reconfiguration. This means that ReCycle model can be
cyclic dependency independently woven and unwoven as required. We believe this
With ReCycle with cyclic 442 1541 3024 gives the approach strong flexibility and generality that will allow
dependency it to be deployed in a number of AO-Middleware platforms not
just AO-OpenCom.
Setup A – Security and Compression Aspect woven locally. Turning to future work, we first plan to investigate extending
Setup B – Security as remote aspect and compression as local our approach to cover cyclic dependency in multi-threaded
aspect. aspects environments. Then, we also plan to integrate our
semantic resolution model [12] and the ReCycle model to ensure
Setup C – Both Security and Compression woven as remote
consistent aspect reconfiguration when building large-scale
aspects.
distributed middleware applications.
A final point to note is that overhead of the ReCycle is determined
by the cyclic graph detection algorithm. An optimised algorithm 7. REFERENCES
detection could be used to reduce the induced overhead of [1] Apel, S., Kastner, C., Batory, D. 2008. Program refactoring
ReCycle in detecting cyclic dependency. using functional aspects. In Proc. 7th Conference. on
Generative programming and component engineering. ACM
Press, New York, 161-170.
5. RELATED WORK
There are several cyclic dependency algorithms developed to [2] Coulson, G., Blair, G., Grace, P., et al. 2008. A Generic
detect cyclic cycles among software modules at runtime. JooJ [7] Component Model for Building Systems Software. In ACM
checks source code of java classes to detect for cyclic Transactions on Computer Systems, Volume 26, Issue 1,
dependencies among java classes. However, JooJ requires the February 2008. ACM Press, New York, Article 1.
developer intervention to resolve the occurrence of any detected [3] Fuentes, L., Pinto, M., Troya. J.M.. 2007. Supporting the
cyclic dependencies. Our approach differs from Jool in that the Development of CAM/DAOP Applications. In Journal
reconfiguration is entirely managed by the ReCycle Configurator Software Practice & Experience John Wiley, Vol. 37. 21-
and in case of cyclic dependencies based on the attached metadata 64.
the Configurator can apply appropriate resolution or rollback from
invalid reconfiguration without the developer assistance. [4] Grace, P., Lagaisse, B., et al. “A Reflective Framework for
ByeCycle [15] is a tool that is very similar to JooJ in that it Fine-Grained Adaptation of Aspect-Oriented
checks for cycles among java packages. As a result only packages Compositions”. In Proceedings of 7th Software
on which classes depend on are analysed to detect cyclic Composition, 2008.
dependencies, such that internal invocations occurring within
[5] Lagaisse, B. and Joosen, W. 2006. True and Transparent
classes are not detected. AOR [1] tackles cyclic referential
Distributed Composition of Aspect-Component. In
dependencies by reverting the dependency between modules such
Proceeding Middleware Conference. ACM Press, New
that the references points in one direction only. However, this can
York, NY, 42-61.
potentially lead to semantic interactions concerns, whereby one
[6] Lingas, A., Lundel, E., Efficient approximation algorithms
for shortest cycles in undirected graphs. In Elsevier
Publications Volume 109, Issue 10, 30 April 2009, 493-
498.
[7] Melton, H., Tempero, E., 2007. JooJ: real-time support for
avoiding cyclic dependencies. In Proc. conference on
Computer science. Vol. 62. ACM Press, New York, 87-95.
[8] Pawlak, R., Duchien, G., et al. 2004. JAC: an aspect-based
distributed dynamic framework. In Journal Software
Practice, Volume 34, Issue 12, 1119 - 1148.
[9] Pessemier, N., et al., “Component-based and Aspect-
oriented Systems”. In Proc. Software Composition, 2006.
[10] Rasche, A., Polze, A. ReDAC Dynamic Reconfiguration of
Distributed Component-Based Applications with Cyclic
Dependencies. In Proc. IEEE on OO Real-Time Distributed
Computing, 2008.
[11] Surajbali, B., Coulson, G., Greenwood, P., and Grace, P.
2007. Augmenting reflective middleware with an aspect
orientation support layer. In Proc. 6th Int. workshop
Adaptive and Reflective Middleware, ACM Press, Article 1.
[12] Surajbali, B., Grace, P and Coulson. G. 2009. Surajbali, B.,
Grace, P and Coulson. G. 2009. A Semantic Composition
Model to Preserve (Re) configuration Consistency in Aspect
Oriented Middleware. In Proc.8th International workshop
Adaptive and Reflective Middleware, ACM Press, Article 6.
[13] Suvee, D., et al., “A Symmetric and Unified Approach
Towards Combining Aspect-Oriented and Component-
Based Software Development”. In Proc. 9th International
SIGSOFT Symposium on CBSE, 2006.
[14] Truyen, E., Janssens, N, Sanen, F., et al., 2008. Support for
distributed adaptations in AOM. In Proc. of the 7th
Conference AOSD. ACM Press, New York, 120-131.
[15] Wuestefeld K., Rodrigo Oliveira, B., Beck, K.,
“ByeCycle”, http://byecycle.sourceforge.net/.