A Dynamic Component and Aspect-Oriented Platform · 2007-04-10 · aspect-oriented software...

ldquobxh083rdquo mdash 2005620 mdash page 401 mdash 1

copy The Author 2005 Published by Oxford University Press on behalf of The British Computer Society All rights reservedFor Permissions please email journalspermissionsoupjournalsorg

Advance Access published on May 3 2005 doi101093comjnlbxh083

A Dynamic Component andAspect-Oriented Platform

Moacutenica Pinto Lidia Fuentes and Joseacute Mariacutea Troya

Dpto de Lenguajes y Ciencias de la Computacioacuten University of MaacutelagaCampus de Teatinos sn E29071 Maacutelaga (Spain)

Email pintolfftroyalccumaes

Component-based software development (CBSD) represents a significant advance towardsassembling systems by plugging in independent and (re)usable components On the other handaspect-oriented software development (AOSD) is presently considered as a possible technology toimprove the modularity and adaptability of complex and large-scale distributed systems Bothare complementary technologies so it would be helpful to have models that combine them to takeadvantage of all their mutual benefits Thus recent research has tried to combine CBSD and AOSDby considering aspects as reusable parts that can be woven and then attached to the individualcomponents Our contribution to the integration of these technologies is CAM a new componentand aspect model that defines components and aspects as first-order entities together with a non-intrusive composition mechanism to plug aspects into components The underlying infrastructuresupporting CAM is the dynamic aspect-oriented platform (DAOP) a component and aspect platformthat provides the usual services of distributed applications as well as a composition mechanism to

perform the plugging of software aspects into components at runtime

Received 12 December 2003 revised 6 August 2004

1 INTRODUCTION

Nowadays traditional methods provided by softwareengineering are not sufficient to cope with the complexityof current distributed systems Component-based softwaredevelopment (CBSD) [1] and more recently aspect-oriented software development (AOSD) [2] have emergedfor the purpose of improving the modularity and evolutionof systems by plugging in independent and (re)usableentities

CBSD relies on achieving an accurate functionaldecomposition of a system into truly independent com-ponents sometimes produced by third parties ready tobe (re)used in different contexts The goal is the reduc-tion of development times costs and efforts while improv-ing the flexibility reliability and maintainability of the finalapplication

AOSD on the other hand is a promising disciplinethat supports the separation of crosscutting concerns byintroducing a new dimension called aspect An important aimof AOSD is to provide a solution to what has been identifiedas the code tangling problem [3] which refers to the difficultycrosscutting properties have in changing or evolvingindependently of the objects they affect In this sense inAOSD aspects usually encapsulate crosscutting properties(synchronization coordination etc) that are defined as partof several objects in a system Aspects define join pointswhich are the points in the execution of a program that canbe intercepted pointcuts which describe the objects that

aspects are applied to and advice which describes aspectbehaviour

CBSD and AOSD are complementary technologies Inthis sense AOSD can help to improve the independencereusability evolution and maintainability of componentsby extracting crosscutting concerns from components andputting them into aspects Those crosscutting concerns canthen be managed separately without affecting the evolutionof the core functionality of components Consequently itwould be helpful to have models that combine CBSD andAOSD to take advantage of all their mutual benefits In theresulting component and aspect models aspects may becomereusable parts which can be composed (woven in the AOSDterminology) and then attached to the individual componentsCurrent research about the integration of CBSD and AOSDis in its initial stages [4 5] so there is much more work tobe done in this direction as described below

Recently component models such as EJBJ2EE [6] andthe new CCMCORBA [7] have evolved to face the challengeof achieving the definition and the use of common servicesoutside component implementationmdashie consider commonplatform services as crosscutting concerns However theyhave not yet found a proper solution to this tangled codeproblem as they only separate a limited number of commonlyused services in distributed systems (eg security transactionand persistence) In order to incorporate the concept ofaspect these platforms should offer additional mechanisms toseparate any kind of crosscutting concern or replicated code

The Computer Journal Vol 48 No 4 2005


402 M Pinto L Fuentes and J M Troya

TABLE 1 Related work in CBSD approaches

CORBA CCMCORBA EJBJ2EE

Separation of crosscutting concerns Limited (interceptors) Limited (container) Limited (container)Explicit AA definition No XML assembly file (components +

connections)XML descriptors (onlycomponents)

AA use No Deployment DeploymentInterface description IDL (only provided

interface)IDL (provided + required + eventinterface)

Java interface (only providedinterface

Regarding the different AOSD approaches many ofthem [8 9] do not treat aspects as context-independent andreusable entities This means that in addition to the aspectbehaviour aspects usually hard-code the aspect pointcutsThis prevents aspects from being reused in different contextsIn addition the join points that can be intercepted by currentAOSD approaches are not always appropriate in the contextof CBSD [9 10] Considering components as black-boxentities aspects should not intercept points that are part ofthe internal behaviour of a component Instead they shouldonly intercept the interactions among components

In this paper we propose a component and aspect model(CAM) that combines the benefits of both CBSD and AOSDdisciplines trying to solve the shortcomings presented aboveCAM defines components and aspects as first-order entitiestogether with a non-intrusive composition mechanism forplugging aspects into components These aspects may becommon services of distributed applicationsmdasheg securitypersistence or any kind of crosscutting or replicated codebut both are added to software components in a homogeneousway Therefore CAM components can be configured to usean open-ended list of crosscutting services In addition in ourmodel the aspect code does not include information about thecomponents that it crosscuts This means that the definitionof pointcuts will be separated from components and aspectsso aspects may be (re)used in different contexts

The underlying infrastructure supporting CAM is acomponent and aspect platform (DAOP a dynamic aspect-oriented platform) where the plugging of software aspectsinto components is performed at runtime Another relevantfeature of our approach is that the architectural informationabout connections between aspects and components is nothard-coded as part of component and aspect implementationsas usual it is stored within the platform Our platformcomposition mechanism consults this information at runtimeto establish the connections among components and aspectsThis is particularly useful because we make componentsand aspects much more reusable isolating the dependenciesbetween them in the platformrsquos internal structures Inaddition this information can be adapted at runtimeimproving the flexibility and adaptability of the finalapplication Other component models also describe theassembly of components explicitly for instance CCM Thedifference is that these models use the assembly descriptorfiles [7] only in the deployment phase and not at runtime

The rest of this paper is organized as follows Section 2presents a survey of current distributed component platforms

and aspect-oriented approaches CAM is presented inSection 3 and DAOP in Section 4 We use a runningexample to describe the main characteristics of both CAMand DAOP After describing the main features of DAOPin Section 5 we show the contributions of CAMDAOP toother CBSD and AOSD approaches As a proof of conceptSection 6 describes the CAMDAOP prototype which hasbeen implemented based on JavaRMI Finally Section 7draws some conclusions and outlines some further work

2 COMPONENT AND ASPECT BASEDSOFTWARE DEVELOPMENT

In this section we place our work in an appropriatecontext providing a survey of current distributed componentplatforms and AOSD approaches

21 Component platforms

In this section we present the results of a comparative studyof the best-known component platforms The criteria usedin this comparative study is related to the most significantcontributions of our work to be discussed throughout therest of the paper (see Table 1)

Software components developed using distributed plat-forms often need to use some common services such assecurity persistence transactions which have nothing to dowith the core functionality of a component and consequentlyshould live outside the component definition and implemen-tation Component platform vendors have been trying toseparate the definition and use of these common platformservices proposing different solutions

An initial solution was the CORBA interceptors [11] Aninterceptor is a hook in the CORBA object request broker(ORB) that is interposed in the invocation and response pathsbetween a client and a target object to invoke any ORBservice However there are some limitations when trying touse interceptors as aspects The most important limitationsare that it is not possible to forward the intercepted messageto a different target and that some implementations do notallow modifying the intercepted message which makes itimpossible to implement many of the essential aspects thatare required in a distributed platform such as the encryptionaspect

Later component platforms such as CCMCORBA andEJBJ2EE provided new solutions to the same problemThey offer a container programming model where thecontainer encapsulates the component implementation and



A Dynamic Component and Aspect-Oriented Platform 403

separately supplies a runtime environment that providesaccess to platform common services The main advantageof the container approach is that software developers donot have to include code for accessing these services insidethe component implementation However the use of thecontainer programming model is restricted to the list ofservices offered by the platform vendor Thus it cannot beapplied to model as separate services any other properties(eg fault-tolerance synchronization and domain-specificproperties) that may also be intermingled with the code ofthe core components

A non-standard approach that tries to overcome the compo-nent platformrsquos limitation is that components can only accessa predefined list of common services through the containeris given in [12] The approach of this work consists of sep-arating the behaviour of components in a non-limited set ofaspectual services describing them in the interfaces of com-ponents as required or provided services Although with thisapproach the evolution of extra-functional properties can beaddressed separately its main drawback is that componentshave to access the aspects directly through an aspect man-ager component making components dependent on aspectsThis proposal is implemented by extending the JViewsframework an extension of the JavaBeans components

Other criteria to compare current component platformsare the mechanisms they provide to describe explicitly theassembly of components [ie the application architecture(AA) description] and how they use this informationthroughout the whole software life cycle As mentionedearlier the AA is not explicitly stated anywhere but is usuallyspread throughout the component implementation modulesConsequently the platform has neither the information aboutthe architectural constraints nor the control to reorganizethe system in order to adapt it to different user preferencesor runtime environments It would thus be very useful tohave component platforms with the capability of interpretingarchitectural information especially at runtime Additionalbenefits of our approach with respect to this issue arepresented in the following sections

The traditional CORBA platform does not specify any-thing about how to assemble a CORBA application froma set of independent CORBA objects To address thisand other limitations the Object Management Groupdefined CCM which extends the CORBA object model tosupport components In addition to component descriptionCCMCORBA provides a way to express the architecture ofan application CCM applications are packaged in assemblyfiles which are XML documents describing components andtheir interconnections This is a significant advance althoughthis information can be used only during the deploymentphase and not at runtime

On the other hand the EJBJ2EE platform also usesXML to describe an application in terms of descriptionsof a set of enterprise beans (EJB deployment descriptors)and an assembly descriptor The assembly descriptor pro-vides configuration information common to all the beansin the application The main restriction of EJBJ2EE isthat it only describes the beans that set up an application

and not the relationships among them Similar to CCMCORBA EJBJ2EE uses the descriptor files primarily in thedeployment phase to deploy the application in the adequatecomponent servers

Finally component platforms also differ in the informationthey put in the description of the component interfacesFor instance CORBA and EJBJ2EE only describe theprovided interface of a component ie the messages thatthe component can manage This makes it difficult to (re)usecomponents in different contexts as there is no informationabout the messages andor events that a component can emitCCMCORBA tries to solve this limitation by extending thetraditional interface description language (IDL) of CORBAto include the description of all the messages and events thata component can both receive and emit

22 Aspect-oriented approaches

In existing AOSD approaches we can find differentalternatives to tackle the separation of concerns issue eventhough the final goal is always the same These approachesdiffer mainly with regard to when aspects are applied (beforeafter or around) the join points where aspects are applied (amethod invocation a field access etc) where the weavinginformation is placed (inside or outside the aspect definition)whether the weaving process is static (performed duringcompilation) or dynamic (performed at runtime) and whetherthey follow an invasive or a non-invasive model Other dif-ferences which we consider less relevant in order to comparecurrent AOSD approaches with our approach have beenomitted for the sake of clarity

The variety of AOSD approaches is so extensive that it isnot possible to cover them all in this section Consequentlywe present those that we consider more relevant with respectto our work A complete description of AOSD technologiescan be found in [2] First some works define aspect-orientedlibraries [13] which are characterized by offering staticweaving and in which the functional code must include someinformation dependent on the applied aspects

The definition of aspect-oriented languages is the mostcommon approach A broadly used aspect-oriented languageis AspectJ [10] which is a superset of Java providing a newconstruction similar to Java classes to implement aspectsIn AspectJ the aspect encapsulates advice indicating aspectbehaviour and also pointcuts indicating where aspects areapplied which drastically reduce aspects (re)use Advicesin AspectJ can be applied before after or around methodcalls field accesses and even points that occur lsquowithinrsquo amethod execution regardless of Java access modifiers Inaddition AspectJ can modify the structure and the hierarchyof Java classes adding new methods fields etc by meansof introductions Although AspectJ is very flexible since it isable to intercept all these join points it is more appropriateto use a non-invasive approach (with no access to the privatepart of an object) when aspects are applied to black-boxcomponents

Aspectual collaborations (AC) [14] is another aspect-oriented approach that tries to solve this limitation




TABLE 2 Related work in dynamic AOSD approaches

PROSE JAC AspectWerkz JAsCo Lasagne JBoss AOP CAMDAOP

CBSD concepts No No No Yes (Beans) Yes J2EE YesSeparate adviceand pointcuts

No Yes Yes Yes Yes Yes Yes

Externalconfiguration ofpointcuts

No acc or XMLfiles

XML files No Compositionpolicy file

XML files XML files

Invasive model Yes Yes Yes No No Yes NoDynamism JVM Class

LoaderWrappers +container

HotSwap Suntechnology

Traps +connectorregistry

Decorator-likewrappers

Container Middlewarelayer

providing a non-invasive model that combines modularprogramming [15] and aspect-oriented programming toobtain properties such as encapsulation hierarchicalcomposition and external assembly In AC crosscuttingconcerns are defined as a set of collaborations The mostimportant advantages of AC are that (i) only the behaviourexported in collaborationrsquos interfaces can be interceptedby ACrsquos aspectual methods (ii) the composition of a setof collaborations is performed externally to constituentcollaborations

Another feature of both AspectJ and AC is that theweaving process is static mixing the component and aspectcode at compile-time Static composition provides highperformance but separation of concerns is lost at runtimeAlthough they use introspection to provide reflectiveinformation about join points at runtime the number and typeof join points affected by an aspect cannot be modified aftercompilation Other similar approaches are given in [16 17]

Another approach is to define aspect-oriented frameworksthat provide template classes for modelling objects andaspects and a more or less dynamic composition mechanismRecently new proposals on aspect-oriented frameworks haveemerged as an alternative to aspect languages and staticweaving Dynamic weaving is much more flexible thanstatic weaving because the separation of concerns remainsat runtime enabling in some cases the late binding betweencomponents and aspects These approaches are mainly basedon a reflection mechanism that offers the ability to modify theapplication semantics while the application is running Thisadaptability is commonly achieved by implementing a metaobject protocol (MOP) as part of the language interpreterthat specifies the way a program may be modified atruntime

Table 2 compares several aspect-oriented frameworks thatprovide dynamic composition of aspects into objects orcomponents With the aim of comparing them with themain contributions of CAMDAOP later we are particularlyinterested in (i) whether these systems incorporate theCBSD concepts (ii) the separation (or not) of adviceand pointcuts in different entities (iii) the mechanismsthey provide to express pointcuts (iv) whether they definean invasive or non-invasive model (v) the mechanismsthey use to perform dynamic composition of components

(or objects) and aspects The last column of Table 2shows the contributions of our approach which will bedetailed throughout the paper

PROSE [9] is an aspect-oriented platform with dynamiccomposition that was not really developed for CBSDPROSE aspects can be applied before and after methodexecutions field accesses and modifications join pointswithin the code of methods class load etc Therefore likeAspectJ PROSE aspects can intercept points that are partof the internal behaviour of objects Its main contributionis that the platform weaves and unweaves aspects directlyin the Java Virtual Machine (JVM) This work is valuablebut has the problem that it is based on the use of the JVMdebugger interface This means that the JVM has to run indebug-mode imposing important performance restrictionson the entire application even if there is no aspect to beapplied Recently PROSErsquos authors have been working onweaving aspects and objects by inserting the aspect advicedirectly into the native code generated by the just-in-timecompiler This seems to reduce the performance overheadthat is introduced by the PROSE class-loader weaver Inaddition pointcuts and advice are implemented in PROSEin the class representing the aspect with the drawbackof reducing the (re)use of the aspect advice in differentcontexts

Another similar approach is JAC [18] an aspect-orientedframework that uses the reflexive API BCEL [19] foradding aspects Using this mechanism aspects in JAC aredynamically deployed and undeployed on top of runningapplication objects using wrappers and aspect containersA wrapper task is divided into two parts the before partand the after part (before and after a method executionapplication start etc) In contrast with PROSE and someaspect language approaches [8 10] in JAC pointcuts are notspecified as part of the aspect definition but in a third-partyentity available at runtime making aspects more reusableIn addition JAC uses AspectComponent configuration files(acc files) or XML files to configure the aspect evaluationrules (or pointcuts) externally Although JAC uses the termlsquocomponentrsquo to refer to one of the entities of the model it doesnot really define a component platform and its componentscannot be considered software components in the CBSDsense [1] In addition JAC provides special mechanisms to




implement distributed protocols that allow objects in differentcontainers to collaborate

Another aspect-oriented framework that performs dynamiccomposition of objects and aspects is AspectWerkz [8]Using the HotSwap Sun technology [20] aspects arecomposed with objects at runtime by modifying the objectsrsquobyte code after class loading This is an interesting approachthat uses XML files to define pointcuts separately from aspectimplementations However aspects in AspectWerkz areapplied to objects and not to components In addition itdefines an invasive model that makes it possible to interceptany point in the internal behaviour of an object and notonly the behaviour exposed through the explicit interfacesof Java objects Furthermore this work has been specificallydeveloped for Java systems as its weaving mechanism reliescompletely on Java technology

The following AOSD approaches focus on applying theAOSD principles to the development of component-basedsystems In this sense JAsCo [5] is an aspect-orientedimplementation language that defines a new componentmodel that is compatible with the JavaBeans componentmodel Aspects in JAsCo can be applied adapted andremoved at runtime The JAsCo language introducestwo concepts aspect beans that encapsulate advice andconnectors that define pointcuts This separation has theadvantage that both advice and pointcuts can evolveseparately increasing the reuse of advice One importantdrawback of JAsCo connectors is that they have to becompiled reducing their runtime adaptation Anywaydynamic connector loading and unloading is possible in theJAsCo connector registry The connector registry is notifiedwhen aspects have to intercept Java Beans components orwhen a connector has been loaded or unloaded Aspectsinterception is performed only before or after a methodexecution and therefore in JAsCo no join point interceptingthe internal behaviour of components is defined Inaddition an aspect can lsquoreplacersquo the normal execution ofa method

Lasagne [21] defines a platform-independent architecturefor dynamic customization of component-based distributedsystems using decorator-like wrappers The Lasagne systemmodels aspects as extensions which consist of severalwrapper definitions These wrappers have to implement theinterface of the component they decorate According toCBSD philosophy in Lasagne aspects only intercept theincoming and outgoing component messages and never theprivate state of components In Lasagne the compositionlogic responsible for integrating extensions into the corecomponents is completely separated from the code of thecomponents and of the extensions as well increasing theirreuse in different contexts This information is specified incomposition policy files that can be dynamically attachedto the system promoting the evolution of final applicationsThe main difference between Lasagne and other AOSDproposals is that they compose extensions at the instance-level instead of at the class-level This gives Lasagne aruntime performance overhead although the compositionmechanism is much more flexible

Finally the JBoss AOP framework [4] is built on top of aJ2EE application server named JBoss and tries to solve thelimitation imposed by J2EE of providing just a set of built-inservices as mentioned before Aspect advice in JBoss AOP isimplemented using interceptors which can intercept methodinvocations constructor invocations and field accesses Eventhough JBoss AOP is developed to apply aspects to JavaBeanscomponents JBoss interceptors can access fields regardlessof whether they are public or private and can even introducenew methods and fields within a class Once again thesefeatures affect the non-invasiveness required in a componentmodel The JBoss AOP framework has the advantage thatit separates advice and pointcuts in different entities wherepointcuts are configured using XML descriptor files Its mainlimitation is that currently it is not possible to add interceptorsto a class that was deployed (ie loaded by the Java classloader) without having an associated pointcut definition

3 THE COMPONENT ASPECT MODEL

The basis of our approach is the component and aspectmodel (CAM) that defines how to describe the structureof an application in terms of components aspects andcommunication mechanisms

Figure 1 shows an unified modelling language (UML)diagram with the basic entities of CAM and the relation-ships that can be established among them We considerthis diagram as the UML profile for CAM so the entitynames are UML stereotypes for modelling applications interms of CAM Figure 2 shows part of the CAM diagram ofa chat application using these stereotypes By applying theseparation of concerns principle we model the core behaviourof a chat application separated from other crosscuttingapplication requirements such as authentication persistenceor message filtering This makes it easier to (re)use the chatcomponent in applications that may or may not require theseproperties These aspectual properties can also be (re)usedin other contexts as standalone entities

The authentication aspect is applied when a user wants tojoin a chat and this implies that the user has to introducesome identification information The local chat componentinstance is created only if the user is registered in the systemIn case we want to develop a persistent chat the persistenceaspect which stores the current state of the chat componentin a data store must be applied This is useful for latecomerusers who join the application once it has been initiatedFinally sometimes we may want to apply a filter aspectto filter some messages for instance according to userpreferences (eg receive only messages from lsquopeterrsquo)

We describe the relationships among the components andaspects that appear in Figure 2 in the rest of this section Abroader description of how to generate an applicationrsquos CAMdiagram can be found in [22]

31 Components and aspects

The main entities of CAM are components and aspectsas shown in Figure 1 Although in principle there is norestriction on the granularity of these entities the distributed




FIGURE 1 The component and aspect model

FIGURE 2 The component and aspect model of a chat application




nature of the applications we want to design with CAMand the way they are composed ie components aredistributed and they interact by exchanging messages andaspects are dynamically plugged into components imposesome recommendations regarding their size and level ofencapsulation In this sense we consider both componentsand aspects as coarse-grained encapsulated entities thatcan only act as units of composition with contractuallyspecified interfaces and explicit context dependenciesThey may be deployed independently and are subject tothird-party composition (component definition by ClemensSzyperski [1])1

Since in CAM aspects are treated as a lsquospecialrsquo kindof component both components and aspects share somecommon features For instance they may have a set ofStateAttributes that represent their public state ie theinformation that should be made persistent to be able torestore the state of a component or aspect instance Thisinformation will be used to implement some properties suchas fault tolerance or persistence

In order to detach component and aspect interfaces fromtheir final implementations we assign a unique role name(in class Role of Figure 1) to identify both component andaspect classes A role name identifies a specific functionalityand will be played by a component that implements thisfunctionality These role names are architectural names thatwill be used for component and aspect composition andinteraction allowing loosely coupled communication amongthemmdashie no hard-coded references need to be used forexchanging information but just a role name identifying thetarget of a message We obtained good results with this roleconcept in previous work [23 24] considerably increasingthe reusability of components In the example in Figure 2we have a component with role name lsquochatrsquo and three aspectswith role names lsquoauthenticationrsquo lsquopersistencersquo and lsquouserfilterrsquo

However it is possible that several components play thesame role inside a distributed application (eg a user isparticipating in more than one chat at the same time) Inthis case the model distinguishes between different instancesof a role2 by the RoleInstance Figure 2 shows that thecomponent chat fulfils the lsquochatrsquo role but if the same userinitiates for example two chats each one will have differentrole instances (eg lsquochat_with_peterrsquo lsquochat_with_susanrsquo)Every chat instance has the lsquochatrsquo role name those belongingto the same chat will also share the role instance name andthose from different chats have different role instance namesMoreover each component instance is identified uniquelyby the Component IDentifier (class CID in Figure 1)

Another important goal of CAM is that aspects do nothave any information about the other aspects applied at thesame time to a component Even if there is some kind of

1Although we share the definition of component by Clemens Szyperskifor the sake of simplicity in this paper we will not distinguish betweencomponents and component instances so we use the term component tomean a set of classes assembled to be deployed together and executed as asingle software unit

2In this context we do not consider the terms lsquorolersquo and lsquorole instancersquoas equivalent to the terms lsquocomponentsrsquo and lsquocomponent instancesrsquo in [1]

dependency the aspects should not be aware of this Wecope with this problem of composition of non-orthogonalaspects by using the class Property in Figure 1 Propertiesare identified by a unique name their type and currentvalue Thus in CAM non-orthogonal aspects indirectlyinteract to resolve their dependencies by sharing proper-ties with the same name and type Then aspects thatare evaluated concurrently should not have any dependenceamong themselves and their effect on components shouldnot interfere Otherwise aspects should be evaluatedin sequence Likewise properties also help to definetruly independent components putting any kind of datadependency as a shared property

As an example of the use of properties Figure 2 shows thataspects with role name lsquoauthenticationrsquo and lsquouserfilterrsquo sharea property with name lsquousernamersquo Once the user has beenauthenticated the authentication aspect sets the value of thisproperty to the name of the user Then the filter aspect getsthe value of the property when it is needed The relevant issueis that the former aspects do not have any interaction amongthemselves since properties are stored in a third-party entity

We consider that the use CAM makes of propertiesprovides a simple but very effective solution to the problemof data dependency among model entities mainly for tworeasons

(i) By using properties CAM permits the description ofdata dependencies during the design phase Thisinformation is very useful to develop more independentand reusable entities since software developers areaware of the information that a component or an aspectshares with the environment in which they will beexecuted They also know whether the informationhas to be generated to the environment as in the caseof the authentication aspect or has to be consultedfrom the environment as is the case of the filteraspect

(ii) The information consulted by an aspect may havebeen generated not only by another aspect but alsoby a component the same occurs for componentsThis provides a homogeneous mechanism for sharinginformation not only among components and amongaspects but also between components and aspects Inour example the property called lsquousernamersquo whichis generated by the authentication aspect may alsobe consulted by the Chat component ie to show awelcome message that includes the user name

The other important feature of CAM is the way in whichthe entities of the model communicate among themselvesFollowing the standard practices of CBSD componentsinteract by exchanging Messages and by throwing EventsWe understand the meaning of messages and events in theCBSD sense messages are sent to a specific target entityand events are messages with no information about the targetcomponent

In this sense we describe the class Message in Figure 1as a composition of a MessageHeader class which identifiesthe source and the target of the message and a Body class




which contains the message information On the otherhand the Event class contains the body of the event andan EventHeader that only identifies the source componentCID omitting the destination component(s) The handlingof events is resolved at runtime by a coordination aspect(class CoordinationAspect in Figure 1) that encapsulates acomponent interaction protocol that will decide which are thetarget components of a given event at runtime More detailsabout this and other functionalities of the coordination aspectcan be found in [25] The different mechanisms defined byCAM to address the target component(s) of a message aredescribed in Section 32

In CAM we consider that aspects are applied to black-box components Therefore in our model we intentionallyavoid the definition of join points that intercept the internalbehaviour of a component as we only have access to acomponent through its public interface Thus CAM aspectscan be applied before and after (incoming and outgoing)messages and events and also before and after the creationand destruction of component instances as shown in thedifferent lsquoapplies torsquo relationships for aspects in Figure 1

In our example components with the role name lsquochatrsquocommunicate by sending the lsquosendTextrsquo message whichupdates the state of the chat component for all users Thismessage is received by components that also have therole name lsquochatrsquo and role instance name lsquochat_with_peterrsquoAspects are applied to the send and receive UML associationsbetween the Component and the Communication classesas established in CAM (Figure 1) Figure 2 shows thatthe aspect lsquopersistencersquo is applied when a component lsquochatrsquosends the message sendText(lsquotextrsquo) making the lsquotextrsquo valuepersistent This aspect should also be applied to the creationof components with the role name lsquochatrsquo to restore the laststate of the component We have omitted it in our examplefor the sake of simplicity The lsquouserfilterrsquo aspect is appliedbefore the previous message arrives at the target componentand a decision is made regarding whether this messageis to be sent or filtered In addition the lsquoauthenticationrsquoaspect is applied to the creation of components with therole name lsquochatrsquo to check if the user is registered in theapplication

Similar to other component models we describe theinterfaces of components and aspects using an IDLA componentrsquos IDL describes not only the services thecomponent provides to the environment as is usual incomponent platforms (the provided interface) but also thoseservices it requires in its interaction with other components(the required interface) How to evaluate aspects is describedin an evaluated interface instead of a provided interfaceas for components that includes the join points (messagesevents creation and finalization of components) that anaspect is able to intercept and evaluate By aspect evaluationwe mean the execution of the corresponding aspect advice(specific details for the aspect evaluation process are givenin Section 423) If an aspect is general enough to beable to evaluate any intercepted join point this interfacecan be omitted A log aspect is a good example of thisbecause it normally intercepts all the messages to or from

a component storing this information in a file In additionwhen an coordination aspect is being evaluated it can alsointeract with the components it coordinates This means thatcoordination aspects also have a required interface describingthe output messages Context dependencies are also specifiedas part of the component and aspect IDLs

In CAM these IDLs are part of an XML-based architecturaldescription language (DAOP-ADL) [26] used to describecomponents and aspects together with the composition rulesthat govern the weaving of components and aspects Usingthis language the applicationrsquos CAM (eg what Figure 2shows) can be transformed to a set of XML documents thatcan be easily interpreted by a runtime environmentmdashie byour DAOP as we will show later The complete descriptionof the language is beyond the scope of this paper and can befound in [26]

Figure 3 shows the XML document that represents theCAM of the chat application shown in Figure 2 This XMLdocument describes the interfaces of all components andaspects in the application (the lsquoprovidedInterfacersquo lsquorequired-Interfacersquo and lsquoevaluatedInterfacersquo shown in Figure 3) theproperties used by components and aspects (the lsquopropertyrsquoXML element) and the aspect composition rules that statehow to plug aspects into components (the lsquoaspectCompo-sitionRulesrsquo XML element) In this example no messagesare sent by aspects Had they been sent the required inter-face for aspects would be the same as that for componentsBy showing this figure here we want to emphasize that theapplicationrsquos CAM (Figure 2) is equivalent to the XML doc-ument (Figure 3) which is directly interpretable at runtimeThe composition rules element of the DAOP-ADL whichdefines how to compose components among them and howto compose aspects with components will be treated in depthin Section 411

Here we want to highlight that describing the aspectcomposition rules (equivalent to the aspect pointcuts inAspectJ) outside the component and aspect definition wedetach components from aspects and aspects from otheraspects avoiding that they share any kind of knowledgeComponents are not aware of aspects since they have noinformation about the number and type of aspects they areaffected by or even if they are affected by any aspectat all This provides enough flexibility to apply differentaspects depending on the context in which the componentis being used

For instance going back to our example if laterwe want the chat to be non-persistent we just need toremove from the XML document the aspect composi-tion rule associated with the component having the rolename lsquochatrsquo that describes the application of the pers-istence aspect (〈BEFORE_SEND〉〈messages〉 sendText〈messages〉〈aspectList〉 persistence 〈aspectList〉〈BEFORE_SEND〉) Neither the component nor theaspect are affected at all In addition avoiding explicitpointcuts in the aspect definition CAM promotes aspectreuse Thus aspects are also independent of the componentsthey affect and can then be applied to different componentsat different times The aspect composition rules shown in




FIGURE 3 The DAOP-ADL description of the CAM for the chat application




Figure 3 are only an example and more complex rulesconsidering wildcards and connectives to specify pointcutscan be defined

32 Component-addressing mechanisms

Although an important issue in CBSD is to make the entitiesof the system as independent as possible components finallyinteract with other components In this sense a componentneeds to put a target component address as part of an outputmessage but this establishes a dependency between both ofthem In our model we try to reduce these dependencies byproviding a mechanism to discover the components that playa certain role at runtime We use the concept of role nameto identify the target component(s) of an output messageWe never use the component interface or implementationclass names to reference components This means thatcomponents do not maintain hard-coded references to othercomponents

As mentioned before a CAM component has a role namea role instance name and a CID Thus CAM offers a total ofthree kinds of component-addressing mechanisms alwaysavoiding the use of direct references among componentsthe role-based invocation the role instance-based invocationand the identifier-based invocation

The role-based invocation mechanism is the mostimportant one Using it a component is addressed bymeans of a string that identifies the role that the componentplays in the system (eg components with role nameslsquovideoconferencersquo lsquochatrsquo) However as mentioned beforesometimes an application has more than one componentplaying the same role In this case the role instance nameallows discriminating between different component instanceswith the same role name The role instance-based invocationmechanism is then used to identify different instances ofthe same resource (eg among all the components playingthe role name lsquochatrsquo only those that additionally have therole instance name lsquochat_with_peterrsquo lsquochat_with_susanrsquo)

Finally the identifier-based invocation addresses acomponent by means of its CID As mentioned before eachcomponent has its own CID As the CID of a component canonly be known if a message from that component has beenreceived before it is normally used in response messagesThis kind of component-addressing mechanism is specifiedas part of the MessageHeader class in Figure 1

The use of these component-addressing mechanismsprovides a powerful and very flexible mechanism for latebinding of components Note that if during componentcommunication component binding is performed usingthe interface name of the target component as CORBA doesie referring to the class name that contains the componentinterface this forces the target component to implement theinterface with this name However by using the role namethe role instance name or CID we only assume that the targetcomponent is able to manage the message or event involvedin a specific interaction

These addressing mechanisms rely on a communicationservicersquos ability to resolve for each role name which

component implementation will receive a message or eventThis communication service is part of the DAOP describedin Section 4

4 THE DYNAMIC ASPECT-ORIENTEDPLATFORM

DAOP is a distributed component and aspect middlewareplatform for running applications conforming to CAMDAOP is considered to be a global configuration entitythat performs the runtime composition of components andaspects

Figure 4 shows the architecture of the DAOP middlewareplatform which contains information about the services andfacilities the platform offers to components and aspects (theelements that appear above the DAOP Platform class inFigure 4) together with the information the platform storesto provide such services (classes below the DAOP Platformclass in Figure 4) In the rest of this section we first describethe infrastructure of DAOP and afterwards the main servicesoffered by the platform

41 Infrastructure of DAOP

In this section we explain the internal structure of DAOPWe want to point out that DAOP was designed to beindependent from any supporting language and distributedobject platform similar to Lasagne and contrary to otherapproaches such as JAsCo or JBossAOP that rely on Javaand the EJB model Basically DAOP arranges its internalinformation in two objects The ApplicationArchitectureobject that stores the architectural description of theapplication and the ApplicationContext object that holdsthe current list of component instances aspect instancesand property instances The information contained in theseobjects is used to implement the services offered by DAOP

411 The application architectureAs mentioned in the introduction an important feature ofour approach is that DAOP stores a description of theAA which can be consulted by the platform to performcomponent and aspect instantiation and composition Thisinformation was specified using the XML-based ADL(DAOP-ADL) [26] as shown in Section 3 XML documentswritten using DAOP-ADL represent AA instances (theexample in Figure 3) describing concrete applications (theCAM of a chat application in Figure 2) During the executionwhen an instance of DAOP is created the XML documentis parsed and the structure of the CAM application is storedin the ApplicationArchitecture class (see Figure 4)

In our approach the AA is described in terms of a set ofcomponent and aspect definitions (the EntityInfo EntitySpecComponentSpec AspectSpec CoordinationAspectSpec andEntityImpl classes) and the connections between them (theCompositionRule class) Component and aspect connectionsare described by means of a set of component compositionrules (the CompCompositionRule class) which define how toglue software components and a set of aspect composition




FIG

UR

E4

The

DA

OP

arch

itect

ure




rules (the AspectCompositionRule class) the pointcutsin AspectJ terminology According to our CAM theinformation about the data shared among several componentsand aspects ie properties are also defined as part of theAA specification (in the PropertyInfo class) where propertiesare described by a name a type and a value Finally theInitialContext class identifies by their role names the list ofcomponents that will be instantiated

Observe that there is a correspondence between the XMLelements in Figure 3 (component aspect compositionRulecompCompositionRule aspectCompositionRule and prop-erty) and the classes mentioned above This means that theinformation used at runtime by DAOP to instantiate com-ponents and aspects and to perform their composition isexactly the same architectural information generated in XMLfrom the UML diagram of the CAM application With thisapproach we close the usual lsquogaprsquo or loss of informationbetween the design and the implementation levelsmdashthe infor-mation about the software architecture of an application isusually lost at the implementation level Furthermore DAOPeven uses this information at runtime thereby ensuring thatconnections established at runtime are exactly those definedin design As mentioned in Section 21 current platformssuch as CCM use this kind of information only for deploy-ment purposes

Component and aspect descriptionsAccording to CAMcomponents and aspects are identified by their role names(the roleName attribute in class EntityInfo) Observe that theclass EntityInfo and the class PropertyInfo contain informationabout the CAM elements shown in Figure 1 (the Entity andthe Property classes respectively) A CAM entity (an aspector a component) is described by an interface specification anda list of implementation classes that realize that interface Anentityrsquos interface specification (the EntitySpec class) containsinformation common to both components and aspects ie thelist of properties an entity can get or set the list of their stateattributes and some deployment information

The component specification is completed with thedescription of the provided interface and the requiredinterface (see ComponentSpec class) By defining not onlythe provided interface but the required interface as wellDAOP encourages the (re)use of DAOP-based COTScomponents which can be inserted in an applicationconsidering only the interface description in DAOP-ADLIn addition the aspect evaluated interface in the classAspectSpec completes the aspect specification and the aspectrequired interface in the class CoordinationAspectSpec storesthe required interface of coordination aspects

The deployment information is also described in XMLusing the DAOP-ADL language Components can be local orremote Local components are created in the local instanceof DAOP Remote components are instantiated in a specificDAOPrsquos URL

Regarding the number of aspect instances the aspectdeployment information describes whether DAOP creates(i) only one instance of an aspect shared by allDAOP instances connected to the same application (an

environment-oriented aspect) providing a centralized aspect(ii) one instance of the aspect for each instance of a DAOP (auser-oriented aspect) providing a distributed aspect (iii) anaspect instance that is shared by all components playing thesame role (a role-oriented instance) Consider a collaborativeshared environment that in addition to the chat componentswith the role name lsquochatrsquo can create components modellingwhiteboard tools with the role name lsquowhiteboardrsquo If apersistence aspect is defined as a role-oriented aspect chatcomponents may use a LDAP-based implementation of thepersistence aspect while whiteboard components may usean ORACLE-based implementation (iv) an aspect instancefor all the components sharing the same role and the samerole instance name (a roleinstance-oriented aspect) In thiscase different chats with different role instance names canbe initiated as part of the collaborative shared environmentmentioned above and each of them may use a differentimplementation of the persistence aspect

This variety of aspect instantiation modes provides greatflexibility to final applications and are particularly suitablein those applications that require a lot of adaptability andconfigurability as in the case of the previously mentionedexamples Otherwise the software architect can simplychoose between environment-oriented and user-orientedaspects which cover the needs of most applications

The other deployment information for aspect is lsquocritical-ityrsquo Aspects are classified as critical aspects and non-criticalaspects depending on how important the result of the evalu-ation of that aspect is to continue or not the application exe-cution For critical aspects if the evaluation of the aspect isnot successful the execution does not continue For instancethe authentication aspect should always be critical to ensurethat if the evaluation of the aspect fails the chat componentwill not be created On the other hand if the aspect is anon-critical aspect the invocation will proceed although theaspect evaluation failed An example of a non-critical aspectmay be the persistence aspect Even though making persis-tent the messages that are interchanged by users in a chatapplication may be a desired property this is not a require-ment for the application to function Deploying the aspectas a non-critical aspect the execution will continue even ifthe database shuts down though with no persistence

By expressing the criticality of aspects as part of thedeployment information our approach increases once againthe flexibility of final applications Thus during thedeployment of the application the software architect decideshow the result of aspect evaluation affects the executionof a specific application independently of how aspectswere implemented This information can be adapted andconfigured to easily generate different versions of anapplication with the same AA but different behaviourFurthermore these modifications can even be carried out atruntime

The information about the properties used by componentsand aspects is also specified as part of the componentsand aspects descriptions in order to make their context-dependencies explicit The listOfProperties attributes inthe ComponentSpec and AspectSpec classes contain the




names of the properties used by the component or theaspect The information about these properties is describedin the PropertyInfo object as mentioned before Propertydeployment information describes properties as userSite ifthere is a property instance for each DAOP instance (egthe case of the lsquousernamersquo property of our example) orserverSite when all DAOP instances share the same propertyinstance (eg a property that contains the URL of the userpreferences store)

Finally one or more classes providing different implemen-tations for a component or an aspect (stored in the EntityImplclass in Figure 4) must comply with the specifications forthat component or aspect stored in the ComponentSpec andAspectSpec classes Each EntityImpl contains the name of animplementation class and whether that implementation hasbeen selected as the current implementation

Component and aspect composition rulesThe last butmost important subclasses of the ApplicationArchitectureobject are the CompCompositionRule and the AspectCompo-sitionRule objects These objects store component and aspectcomposition rules which describe the relationships amongcomponents and aspects and some information for adaptingmismatched interfaces We illustrate the runtime composi-tion mechanism of DAOP by showing how it composes twochat components instances with the lsquopersistencersquo and lsquouserfil-terrsquo aspects using the architectural information stored in theAA and application context objects (see Figure 5) Figure 5also depicts some implementation code in Java althoughDAOP can be implemented in other languages

As explained above components and aspects use rolenames in the implementation code to send messages (seelines 12 and 14 of code in the implementation of the chatcomponent in Figure 5) Since component connectionsare established by mapping component role names everyrole name assigned to components in the AA (actualrole names) has to match the role names hard-coded incomponents (formal role names) The adaptation if neededwill be performed at runtime by the platform using a setof component composition rules (lsquoCompCompositionRulersquoobject)

Going back to our example in Figure 5 the programmerhard-coded the lsquocollabApplrsquo role name to identify the targetcomponent of the message sendText(lsquotextrsquo) (see line 12 inFigure 5 again) However the software architect usedthe role name lsquochatrsquo to identify this component in thedescription of the AA (see Figure 3 in XML) This rolemismatching is resolved at runtime using the componentcomposition rule shown in Figure 5 Of course during thedescription of the AA the software architect will have tovalidate that the message lsquosendTextrsquo which is sent to thecomponent with the formal role name lsquocollabApplrsquo is part ofthe provided interface of the component with the actual rolename lsquochatrsquo

On the other hand aspect composition rules define whenand how to apply aspects to components They are expressedin terms of five elements as shown in the lsquoAspectComposi-tionRulersquo class in Figure 4 The lsquosourceCompRolersquo (sRole

in Figure 5) and the lsquotargetCompRolersquo attributes (tRole inFigure 5) identify by their role names the source and targetcomponents that are affected by a rule The lsquomessageNamersquoattribute specifies the message the rule is applied to ThelsquoaspectRolersquo attribute is a list that specifies the role namesof the aspects that will be evaluated This list is imple-mented using a bi-dimensional array of strings with the for-mat A1 A2 A3 A4 where every Ai is an aspect rolename This bi-dimensional structure allows us to specify twokinds of aspect evaluation sequential evaluation and paral-lel evaluation Aspects enclosed in the outer brackets forinstance A1 and A2 are evaluated sequentially On the otherhand aspects in the inner brackets for instance A3 and A4will be evaluated concurrently

We encourage defining composition rules for all thepossible components and aspects that may be instantiatedduring the execution of the application so user customizationof an application may imply deleting and later adding anaspect This is a relevant feature of our platform because thenumber and type of aspects applied to the running applicationcan be adapted at lsquoruntimersquo without code recompilation andnot at lsquoloadrsquo time as usual [4 18] Later in Section 426we describe the AA configuration service offered by DAOPused to adapt the AA at runtime

Finally an aspect evaluation rule specifies the moment atwhich aspects are applied (the lsquowhenrsquo attribute) The availablejoin points are enumerated in the object AspectJoinPoint andare BEFORE_SEND AFTER_SEND BEFORE_RECEIVEand AFTER_RECEIVE to apply aspects before and aftersending and receiving a message or an event andBEFORE_NEW AFTER_NEW BEFORE_DESTROY andAFTER_DESTROY to apply aspects before and aftercreating or destroying a component instance We want tohighlight that although we define lsquobeforersquo and lsquoafterrsquo rulesCAM aspects can also be applied lsquoaroundrsquo a join point asother approaches do [9 10 18] Since CAM aspects cansend messages to components they can replace or modifycomponent interactions forwarding messages to a differenttarget and even running additional code

Consequently once again one of the most relevant advan-tages of our platform is that the moment of the evaluation(when creatingdestroying components and when sendingandor receiving messages and events) the kind of evaluation(sequential or parallel) and the information about which andhow components are affected by aspects is not hard-coded aspart of the component or aspect implementations increasingtheir reuse Instead as shown in this section this informa-tion is taken out of components and aspects and stored ina third entity ie the ApplicationArchitecture class insideDAOP achieving the component and aspect independencethat we claimed in previous sections

412 The application contextDAOP stores the references of all the componentsaspects and properties currently instantiated for a specificapplication in the ApplicationContext object DAOPmaintains information about component aspect and propertydefinitions inside the ApplicationArchitecture class but




FIGURE 5 A snapshot of a running DAOP

references to their local or remote instances are in theapplication context Thus the ApplicationContext class is likea name service that links component and aspect instances withtheir role names and likewise property instances with theirpropertyrsquos name

Before component aspect or property creation DAOPconsults the information about these entities stored inthe ApplicationArchitecture class uses this information toinstantiate the corresponding entity and finally stores thenew instance in the ApplicationContext class Then theplatform resolves at runtime which instance is associated

with the specified role name by simply consulting thisobject

42 Services of DAOP

Similar to other component platforms DAOP provides aset of common services to develop distributed applicationssuch as the instantiation of components the communicationof components the evaluation of aspects the storageof properties the persistence service and the dynamicadaptation of the AA DAOP uses the information stored in




the ApplicationArchitecture object and the ApplicationContextdescribed above to implement all these services

421 Component and aspect instantiationDAOP components and aspects can create or destroyother components using the corresponding methods of theComponentFactory interface (see Figure 4) The syntax ofthese methods are createComponent(String rolename Stringroleinstancename) and destroyComponent(String rolenameString roleinstancename) Note that components areidentified by a role and a role instance name Thus a softwarecomponent just needs to specify strings with the role nameand the instance name and never its implementation classLikewise aspects are also created or destroyed but onlyby the platform using a similar interface that also identifiesaspects by their role name This interface is not shown inFigure 4 because aspects in our approach are created byDAOP when needed and not directly by applications Asstated before DAOP stores the names of the component andaspect implementation classes in the EntityImpl object as partof the application architectural information described in theApplicationArchitecture object

From the point of view of the software developer theimplementation of a component or an aspect in our approachis extremely simple compared with other componentplatforms In DAOP software developers do not have tomanage any matter related to the implementation of remoteobjects such as the definition of remote interfaces andimplementations generation and distribution of stubs andskeletons For instance in the current implementation of ourmodel DAOP components and aspects are implemented assimple Java objects

Again refer back to Figure 5 which shows theimplementation of the chat component and the persistenceaspect A DAOP component implementation must include(i) the definition of a CID attribute to store the componentidentifier (ii) a reference to the DAOP and (iii) a constructormethod with two parameters that are the CID and areference to DAOP This constructor is not directly invokedby components Instead when a component uses theComponentFactory service to instantiate a new componentit is DAOP that invokes this constructor setting its referenceand the CID inside the component

The implementation of an aspect basically consists ofproviding the behaviour of the eval() method In additionthe aspect programmer must provide the following code(i) a variable to hold a reference to the platform and (ii) aconstructor method with one parameter that is a referenceto the platform As for components DAOP will invoke thisconstructor to create the aspect setting its reference insidethe aspect Using this reference aspects can access some ofthe services offered by the platform such as the propertiesstorage or the persistence service

422 Component communication and coordinationservice

DAOP also offers a set of component communicationprimitives As in other component platforms (eg

CORBA) DAOP allows components to send synchronousand asynchronous messages as well as to broadcast amessage to several targets DAOP also allows componentsto throw events to other components

DAOP implements four primitives in order to send mes-sages and events between components (see the Communica-tionService interface and all its subinterfaces in Figure 4)

(i) execute(Message m) This method performs thedelivery of asynchronous messages addressing thetarget component by using any of the mechanismsdescribed in Section 32

(ii) broadcast(Message m) This method broadcastsasynchronously the same message to all componentsaddressed as target components It can be used forinstance to send the same message to all componentswith the same role name (line 14 of Figure 5)

(iii) execmi(Message m) This method behaves the sameway as execute but the invocation is synchronous

(iv) event(Event e) Using this method components canthrow events to other components Communication byevents is very useful to decouple components and isspecially suited to enable (re)use Components throwevents to notify to the environment that somethinghappened in its internal state By intercepting thethrowing of events DAOP provides a join point thatoccurs within the execution of a component methodsimilar to other approaches like AspectJ or PROSEThe difference with these white-box approaches isthat DAOP can only intercept the points that thecomponent makes visible throughout the throwing ofevents considering it a black-box component

As explained earlier the handling of events is resolved atruntime by a coordination aspect By applying the separationof concern principle to separate coordination we do not forcethe use for instance of a publish and subscribe mechanismas other platforms do Instead the coordination aspect mayimplement this mechanism but it may also contain rules suchas lsquoif an event e is intercepted and the source componenthas the role name source_crole then a message msg is sentto the target component(s) with the role name target_crolersquoWe want to highlight that this information is described inXML and is loaded into the coordination aspect when it isinstantiated (more information in [25])

Going back to our example in Figure 5 let us only considerthe communication between the two chat componentspostponing the aspect evaluation to the next section Thiscommunication is performed through DAOP by invokingthe broadcast communication primitive (step 1) DAOPchecks the CompCompositionRule classes to see if it has toadapt the role name of the target component (step 2) ThenDAOP obtains the reference of the component(s) with the rolename lsquochatrsquo from the ApplicationContext object (step 5) andfinally will invoke the lsquosendTextrsquo method on these componentobjects (step 7)

We want to point out that using CAMDAOP developerscan build component-based applications without consideringaspects This is possible because there are no direct




references between components and aspects and alsobecause the component composition mechanism presentedin this section is independent of aspect evaluation

423 Aspect evaluationThe component composition mechanism described aboveis extended in DAOP to incorporate dynamic evaluationof aspects When a component creates or finalizes othercomponents or sends a message or an event using any DAOPcommunication primitives DAOP intercepts it and evaluatesthe corresponding aspects

DAOP aspects should implement the AspectEvaluation-Service interface This is mandatory since the platform willinvoke the eval(Message m) or the eval(Event e) methods toevaluate an aspect This is the only requirement an aspectmust fulfil to be recognized by the platform as a valid DAOPaspect implementation The eval() method contains the aspectfunctionality or aspect advice in AspectJ terminology

Going back to Figure 5 take a look at the aspect evaluationrules stored in the AspectCompositionRules object (step 3)Rule number 2 states that before sending the sendText(lsquotextrsquo)message DAOP has to evaluate the lsquopersistencersquo aspect(step 4) Then once the message has reached the targetDAOP(s) and before the target component receives themessage rule number 3 indicates the evaluation of thelsquouserfilterrsquo aspect (step 6) Finally if all aspects areevaluated successfully the message is received by the targetcomponent(s) (step 7) If an error occurs the other aspectsare not evaluated and the message does not reach its targetDAOP throws an exception indicating that something wrongoccurred during message delivery although no informationabout the aspect that caused the problem is sent since thecomponent is not aware of aspects

424 Property storageIn Section 3 we discussed the benefits of defining componentand aspect properties to solve data dependencies betweenentities of CAM During execution a producer entity willset the value of a property with the setProperty(StringpropertynameObject value) method of the PropertyServiceinterface in Figure 4 and later the consumer entity of thatproperty will get its current value with the getProperty(Stringpropertyname) method Property instances are stored in theApplicationContext object of DAOP

425 PersistenceThe PersistenceService interface provides the functionalityrequired to store and retrieve the current state of componentsThis service may be used to implement a persistence aspectthat simply has to invoke the storeComponent(CID compo-nent) and retrieveComponent(CID component) methods Theimplementation of these methods serializes or de-serializesthe attributes that are part of the state of a component (see theState class of CAM in Figure 1) and then stores or retrievesthem in a data repository of DAOP

Note that in Figure 5 the implementation of the persistenceaspect (see line 13) uses this service to store the state of the

source component identified by its CID This information isextracted from the class Message

426 AA configurationThe AAConfigurationService interface provides a set ofmethods to modify at runtime the software architecture ofthe application which is stored in the ApplicationArchitectureobject as described before It is possible to add modify orremove the description of components aspects propertiesor even composition rules using the corresponding methodsof the AAConfigurationService interface The informationprovided with these methods is used to modify or adaptthe architectural information contained in the EntityInfoPropertyInfo and CompositionRule classes of the AA (lowerside of Figure 4) This service is very useful to configurethe application dynamically adapting it according to theuser preferences or to any necessity of the current executionenvironment The correctness of the resulting AA is checkedafter a modification request

A few examples of the adaptations that can be performedin our chat application and the information that has tobe added or modified in the ApplicationArchitecture objectof Figure 4 are as follows (i) replace the implementationof the chat component by an improved one This onlyrequires selecting the new implementation as the currentimplementation (see the current attribute in the EntityImplclass in Figure 4) (ii) convert the chat application into a free-access application by removing the aspect evaluation rule thatapplies the aspect with the role name lsquoauthenticationrsquo (iii) adda new aspect andor component into the application by addingits description to the AA and by modifying the currentaspect evaluation rules to include it in the proper place

By using this service software developers can easily plugand unplug aspects into applications even at runtime Forinstance we may trace the connection of users into thechat application modifying the aspect composition rules foradding a trace aspect after the creation of the chat component

5 RELATED WORK

After comparing our model with CORBA and the containerprogramming model of EJBJ2EE and CCMCORBA wehave found basic differences regarding (i) the mechanismsthey provide to cope with the separation of crosscuttingconcerns (ii) the mechanisms they use to addresscomponents and services (iii) the composition mechanismsbetween components and services (iv) the description anduse of the software architecture of applications includingcomponent interfaces

The number and kind of crosscutting properties that can bemanaged as independent services are broader in our approachWhereas CORBA EJB and CCM offer a concrete number ofservices that cannot be extended by users (eg transactionsecurity persistence and notification) in our approach it ispossible to separate any crosscutting property for instancecoordination trace code fault tolerance distribution Thedifference can be found in how both approaches manage theseproperties While in CORBA CCMCORBA and EJBJ2EE




the provision of these services relies on the platform providercomponents and aspects in CAM are first-class entities thatcoexist at the application level Consequently CAMDAOPprovides applicationsrsquo developers with adequate mechanismsto divide the application functionality into components andcrosscutting properties modelled as aspects

The addressing mechanisms of components and aspects (orservices) also differ with respect to CORBA CCMCORBAand EJBJ2EE During interactions components need toreference other components Using J2EE and the staticinvocation mechanism of CORBA the client obtains thereference to a component and then communicates directlywith it This implies that the client code hard-codes thereference of the target component The main problem isthat this creates undesirable dependencies that reduce the(re)use of single components in different contexts In ourapproach we try to reduce the dependencies of a componentwith the environment by defining role names which avoidshaving hard-coded references in the component code Thedynamic invocation mechanism of CORBA also decouplescomponents from the interactions in which they participateresolving the target component at runtime However unlikeDAOP with CORBA the applications themselves and notthe CORBA ORB are the ones which have to include themechanisms to decide at runtime the target componentrsquosIDL This makes the implementation of dynamic CORBAapplications much more complicated than those using staticinvocation [27]

In addition in our approach aspect composition rules arestored inside DAOP and are consulted during componentcommunication so we never include this information as partof component or aspect references This is an importantdifference with other interception mechanisms such asCORBA interceptors CORBA hard-codes informationabout the interceptors that have to be applied to a specificobject as part of the objectrsquos reference making it impossibleto modify this information once the object reference has beencreated

Another important difference is the way in which theinformation about the AA is managed Comparing ourapproach with current component platforms CCMCORBAalso provides information about the AA in XML HoweverCCMCORBA only uses that information during theapplication deployment and not at runtime as DAOP doesTherefore the kind of services that can be added to acomponent are established during the instantiation of thecontainer in a static way and they cannot be adapted atruntime as DAOP does which we showed in the previoussection EJBJ2EE only describes components but not theircomposition rules and CORBA only describes object IDLsIn DAOP the information about AA can be modified atruntime it is not necessary to shut down and recompile theapplication to change its behaviour increasing the flexibilityand adaptability of final applications

Regarding AOSD approaches we compare them withCAMDAOP according to the same criteria used inSection 22 In this sense PROSE JAC and AspectWerkzdiffer from CAMDAOP in that they do not apply aspects

to components but to objects The other difference betweenPROSE and CAMDAOP is that PROSE does not separateadvice and pointcuts in different entities reducing thereusability of aspects in different contexts Also contrary toCAMDAOP which postpones the weaving of componentsand aspects until runtime PROSE binds aspects into objectsat load time it being impossible to change the number andkind of aspects applied to an object after the object class hasbeen loaded by the JVM Class Loader

Although JAC aspects separate advice and pointcuts intotwo different entities and additionally JAC pointcuts areexternally configured using XML files there is an importantdifference between JAC and CAMDAOP Our approach isneither a clientserver approach nor does it follow a containermodel as JAC Instead DAOP is a distributed platform thatdoes not need to define extra mechanisms such as JACdistributed protocols to distribute aspects in different hostsAn application in DAOP is distributed among different hostswhere a local instance of DAOP is running These DAOPinstances communicate among themselves it being possiblefor all the components and aspects in a DAOP application tocommunicate and collaborate among themselves The aspectinstantiation mode described in Section 411 determines thenumber of instances that DAOP creates for each aspect andhow they are distributed

CAMDAOP and AspectWerkz have some similaritiessince both approaches perform the weaving of aspects atruntime and both separate pointcuts definition and adviceinto two different entities using XML files to declarepointcuts However there are also important differencesamong them The most important one is that AspectWerkzhas been developed specially for Java while CAMDAOP istechnology-independent In addition CAMDAOP definesa distributed model for the development of component-and aspect-based application while AspectWerkz appliesonly to objects Furthermore even if AspectWerkz offersthe possibility of applying remote aspects following aclientndashserver approach it does not explicitly support thedevelopment of peer-to-peer distributed applications asCAMDAOP does

Focusing now on those approaches that provide a CAMwe compare CAMDAOP with Lasagne JAsCo and JBossJAsCo and JBoss both provide a component-aspect modelthat is an extension of the EJB component model Lasagneon the other hand defines its own architecture based on adynamic decorator-like wrapper mechanism that is highlysuitable for supporting different client-specific views on thecore components which is an important aim in LasagneHowever regarding the reusability of aspects in differentcontexts the main drawback of Lasagne is that aspects arealways dependent on the components they decorate as theyhave to implement the component interface reducing aspectreusability enormously

On the other hand the most important differencebetween JBoss and CAMDAOP is that while JBoss bindscomponents and aspects at load time DAOP componentsand aspects remain separate even at runtime Consequentlyin CAMDAOP Java classes do not need to be reloaded




in case the aspect composition rules change as in JBossAOP Another important difference is that JBoss AOP aspectscan intercept private parts of a component which may beconsidered as not being very legal

Finally JAsCo provides a solution that is very similar toour approach where the JAsCo connector registry plays thesame role as our DAOP platform and aspects are also attachedto components at runtime The main difference is that ourapproach is more flexible to changes than JAsCo for twomain reasons First although both separate aspect advice andpointcuts into two different entities JAsCorsquos pointcuts are notdescribed using a declarative language so after changing apointcut the connector needs to be (re)compiled SecondCAMDAOP aspects are more adaptable at runtime thanJAsCo aspects The reason is that JAsCo connectors onlyprovide information about pointcuts but the informationabout when the aspect is applied (before or after the executionof the intercepted join point) is hard-coded as part of theaspect behaviour In CAMDAOP both kinds of informationare described externally to aspects using DAOP-ADL andboth can be adapted at runtime

6 CAMDAOP PROTOTYPE

As a proof of concept CAMDAOP has been implementedbased on JavaRMI as the base communication mechanismand the Java reflective package for dynamic compositionUsers initiate CAMDAOP applications by downloading anapplication applet through a DAOP Application DirectoryAn instance of the distributed DAOP is created at each usersite during applet downloading

We want to point out that the ApplicationContext and theApplicationArchitecture objects in DAOP (see Figure 4) maybe implemented either following a centralized or a distributedapproach In our prototype we have implemented them asdistributed entities This means that the ApplicationContextobject is present along the different instances of DAOPeach one containing the components and aspects locallyinstantiated This is transparent to components and aspectswhich rely on DAOP to localize the rest of the componentsand aspects in the application

Regarding the ApplicationArchitecture object the applica-tion architectural information is replicated in each instanceof DAOP During the application registration the documentdescribing the AA (using DAOP-ADL) is parsed and theobjects that compose the ApplicationArchitecture are filledand finally serialized Once a user joins an applicationthe AA information is downloaded as part of the applicationspecific applet is de-serialized at the user site and the infor-mation is stored in the platform The platform assures thatthis information remains consistent if changes are performedby some other user

Our prototype also supports the use of DAOP-ADL todescribe the architecture of applications The processof describing and validating the AA in our approach issemiautomatic as we provide a set of tools that supportthe software architectrsquos task [26] In addition to integrateDAOP-ADL into the platform we are currently developing

tools that automatically generate DAOP-ADL descriptionsof components and aspects by binary code inspection Usingthis tool we simplify the software developerrsquos task by makingit easier to plug components and aspects into an application

Using this implementation we have mainly developedcollaborative applications [28] These applications likegroup games (eg the Pictionary game) or collaborativespaces (eg a Virtual Office) are dynamic and distributedapplications that are characterized by high runtimeinteraction among the users connected to the application andhigh requirements of dynamic adaptability and reusabilitytherefore they are good candidates to test our approach

Currently we have a virtual office application (seehttp15021410846CoopTEL) and after one year ofevaluation we can state that the performance is satisfactoryEven when Java poses significant drawbacks related toefficiency we find that the overload of dynamic evaluationof aspects is not so critical in distributed systems based onJava For instance component and aspect creation throughthe platform takes 30 ms and the time to incorporate theevaluation of the aspect at runtime is insignificant (around20 ms) Comparing this evaluation time with the time spentloading a web page from the same host they are insignificantNevertheless the advantages of CAMDAOP do not dependon Java limitations because the model is independent ofspecific programming languages or component platforms

7 CONCLUSIONS AND FUTURE WORK

In this paper we have presented CAMDAOP a newcomponent and aspect model that combines CBSD andAOSD disciplines By defining this model we have triedto overcome some restrictions of both component platformsand AOSD approaches that make it difficult to develop finalapplications as a set of independent and reusable softwarecomponents and aspects

The main contributions of CAMDAOP are the followingFirst it separates components and aspects into two first-order entities that are composed by DAOP at runtime Dueto the application of the separation of concerns principleand in particular due to the composition mechanism definedby the model the reusability of components increases anddevelopers are able to build complete applications in a shorttime

Second the architectural information is explicitly storedin the platform As the connections between componentsand aspects are clearly specified in the AA designers andprogrammers are able to comprehend the structure of anyin-house or third-party application This issue greatlyfacilitates the understanding and evolution of the finalapplication

Third we achieve a high degree of independence betweencomponents and aspects which makes them more reusablein different contexts (i) CAM entities both componentsand aspects are independent regarding communication dueto the role name concept which avoids having hard-codedreferences among them (ii) they are also independentregarding shared data due to the definition of properties




(iii) aspects are independent from components as pointcutsare described in DAOP-ADL making aspects more reusablein different contexts

Finally since DAOP-ADL can express the applicationrsquosCAM in XML which later is interpreted by DAOP we bridgethe gap between design and implementation

As might be expected static composition is faster andtherefore offers better performance than dynamic weavingTherefore the main limitation of CAMDAOP may be thatthe use of reflection and the dynamic composition mechanismintroduces some overhead at runtime

In order to cope with the overhead introduced by dynamiccomposition and taking into account that there are aspectsthat might not need to be adapted at runtime we aredeveloping a static composition mechanism using the JavaBCEL API Extending DAOP-ADL to specify whetheran aspect must be woven into components statically ordynamically this tool will manipulate component class filesto weave static aspects at compile time Following thisapproach aspects that are composed dynamically at runtimewill not invade the component code while aspects that arecomposed statically will be part of the component codeNevertheless even with this extension we continue to claimthe non-invasiveness of our model at design phase Oneof the goals of this extension is to be able to study theruntime overheads of our approach to check how we are ableto reduce the runtime overheads of dynamic compositionin some situations In addition we are working on newimplementations of CAMDAOP in CORBA CCMCORBAand NET

ACKNOWLEDGEMENTS

This research was funded in part by the MCYT under grantTIC2002-04309-C02-02

REFERENCES

[1] Szyperski C (2002) Component Software Beyond Object-Oriented Programming(2nd edn) Addison-Wesley

[2] Aspect-oriented software development websitehttpaosdnet

[3] Kiczales G et al (1997) Aspect-oriented programming InProc ECOOPrsquo97 Finland June 9ndash13 Lecture Notes inComputer Science 1241 pp 220ndash242 Springer-Verlag

[4] The aspect oriented programming and jboss tutorial httpwwwonjavacompubaonjava20030528aop_jbosshtml

[5] Suveacutee D Vanderperren W and Jonckers V (2003) JAsCoan aspect-oriented approach tailored for component basedsoftware development In Proc Second Int Conf on AOSDBoston MA March 17ndash21 pp 21ndash29 ACM Press

[6] Blevins D (2001) Overview of the enterprise javabeanscomponent model In Heineman G and Council W (eds)Component-Based Software Engineering Putting the PiecesTogether pp 589ndash606 Addison-Wesley

[7] OMG (1999) The CORBA component model httpwwwomgorgdocsformal02-06-65pdf

[8] AspectWerkz web page httpaspectwerkzcodehausorg[9] Popovici A Gross T and Alonso G (2002) Dynamic

weaving for aspect-oriented programming In Proc First Int

Conf on AOSD Enschede The Netherlands April 22ndash26pp 141ndash147 ACM Press

[10] Kiczales G Hilsdale E Hugunin J Kersten M Palm Jand Griswold W G (2001) An overview of AspectJ In Procof ECOOPrsquo01 Budapest Hungary June 18ndash22 Lecture Notesin Computer Science 2072 pp 327ndash355 Springer-Verlag

[11] OMG (2002) CORBA 30mdashportable interceptors chapterhttpwwwomgorgdocsformal02-06-57pdf

[12] Grundy J (2000) Multi-perspective specification design andimplementation of software components using aspects Int JSoftw Eng Know 10 713ndash734

[13] Lieberherr K Orleans D and Ovlinger J (2001) Aspect-oriented programming with adaptive methods CommunACM 44 39ndash41

[14] Lieberherr K Lorenz D H and Ovlinger J (2003)Aspectual collaborations combining modules and aspectsComp J 46 542ndash565

[15] Parnas D (1972) On the criteria to be used in decomposingsystems into modules Commun ACM 15 1053ndash1058

[16] Ossher H and Tarr P (2001) Multi-dimensional separationof concerns and the hyperspace approach In Aksit M (ed)Software Architectures and Component Technology KluwerAcademic Publishers

[17] Wichman K (1999) ComposeJ The Development of aPreprocessor to Facilitate Composition Filters in the JavaLanguage Masterrsquos thesis Department of ComputerScience University of Twente httptresecsutwentenlpublicationspaperinfo

[18] Pawlack R Seinturier L Duchien L and Florin G (2001)JAC a flexible and efficient framework for AOP in JavaIn Proc Reflectionrsquo01 Kyoto Japon September 25ndash28Springer-Verlag pp 1ndash24

[19] Byte code engieering library web page httpjakartaapacheorgbcel

[20] Dmitriev M (2001) Towards flexible and safe technology forruntime evolution of java language applications In ProcWorkshop on Engineering Complex Object-Oriented Systemsfor Evolution in association with OOPSLA 2001 Int ConfTampa Bay FL October 15

[21] Truyen E Vanhaute B Joosen W Verbaeten P andJoergensen B N (2001) Dynamic and selective combinationof extensions in component-based applications In Proc23rd Int Conf on Software Engineering Toronto CanadaMay 12ndash19 pp 233ndash242 IEEE Computer Society

[22] Fuentes L Pinto M and Vallecillo A (2003) How MDA canhelp designing component- and aspect-based applications InProc 7th IEEE Int Enterprise Distributed Object ComputingConf (EDOC 2003) Brisbane Australia September 16ndash19pp 124ndash135 IEEE Computer Society Press

[23] Fuentes L and Troya J M (1999) A java framework forweb-based multimedia and collaborative applications IEEEInternet Comput 3 55ndash64

[24] Fuentes L and Troya J M (2001) Coordinating distributedcomponents on the web an integrated developmentenvironment Software Pract Exper 31 209ndash233

[25] Pinto M Fuentes L Fayad M and Troya J M (2002)Separation of coordination in a dynamic aspect-orientedframework In Proc First Int Conf on AOSD EnschedeThe Netherlands April 22ndash26 pp 134ndash140 ACM Press

[26] Pinto M Fuentes L and Troya J M (2003) DAOP-ADL an architecture description language for dynamiccomponent and aspect-based development In Pfenning F




and Smaragdakis Y (eds) Proc Second Int Conf onGPCE Erfurt Germany September 22ndash25 Lecture Notes inComputer Science 2830 pp 118ndash137 Springer-Verlag

[27] Henning M and Vinoski S (1999) Advanced CORBAProgramming with C++ Addison-Wesley

[28] Pinto M Amor M Fuentes L and Troya J M (2001)Collaborative virtual environment development an aspect-oriented approach In Int Workshop on Distributed DynamicMultiservice Architectures (DDMArsquo01) Arizona April 16ndash19pp 97ndash102 IEEE Computer Society Press




TABLE 1 Related work in CBSD approaches

CORBA CCMCORBA EJBJ2EE

Separation of crosscutting concerns Limited (interceptors) Limited (container) Limited (container)Explicit AA definition No XML assembly file (components +

connections)XML descriptors (onlycomponents)

AA use No Deployment DeploymentInterface description IDL (only provided

interface)IDL (provided + required + eventinterface)

Java interface (only providedinterface

Regarding the different AOSD approaches many ofthem [8 9] do not treat aspects as context-independent andreusable entities This means that in addition to the aspectbehaviour aspects usually hard-code the aspect pointcutsThis prevents aspects from being reused in different contextsIn addition the join points that can be intercepted by currentAOSD approaches are not always appropriate in the contextof CBSD [9 10] Considering components as black-boxentities aspects should not intercept points that are part ofthe internal behaviour of a component Instead they shouldonly intercept the interactions among components

In this paper we propose a component and aspect model(CAM) that combines the benefits of both CBSD and AOSDdisciplines trying to solve the shortcomings presented aboveCAM defines components and aspects as first-order entitiestogether with a non-intrusive composition mechanism forplugging aspects into components These aspects may becommon services of distributed applicationsmdasheg securitypersistence or any kind of crosscutting or replicated codebut both are added to software components in a homogeneousway Therefore CAM components can be configured to usean open-ended list of crosscutting services In addition in ourmodel the aspect code does not include information about thecomponents that it crosscuts This means that the definitionof pointcuts will be separated from components and aspectsso aspects may be (re)used in different contexts

The underlying infrastructure supporting CAM is acomponent and aspect platform (DAOP a dynamic aspect-oriented platform) where the plugging of software aspectsinto components is performed at runtime Another relevantfeature of our approach is that the architectural informationabout connections between aspects and components is nothard-coded as part of component and aspect implementationsas usual it is stored within the platform Our platformcomposition mechanism consults this information at runtimeto establish the connections among components and aspectsThis is particularly useful because we make componentsand aspects much more reusable isolating the dependenciesbetween them in the platformrsquos internal structures Inaddition this information can be adapted at runtimeimproving the flexibility and adaptability of the finalapplication Other component models also describe theassembly of components explicitly for instance CCM Thedifference is that these models use the assembly descriptorfiles [7] only in the deployment phase and not at runtime

The rest of this paper is organized as follows Section 2presents a survey of current distributed component platforms

and aspect-oriented approaches CAM is presented inSection 3 and DAOP in Section 4 We use a runningexample to describe the main characteristics of both CAMand DAOP After describing the main features of DAOPin Section 5 we show the contributions of CAMDAOP toother CBSD and AOSD approaches As a proof of conceptSection 6 describes the CAMDAOP prototype which hasbeen implemented based on JavaRMI Finally Section 7draws some conclusions and outlines some further work

2 COMPONENT AND ASPECT BASEDSOFTWARE DEVELOPMENT

In this section we place our work in an appropriatecontext providing a survey of current distributed componentplatforms and AOSD approaches

21 Component platforms

In this section we present the results of a comparative studyof the best-known component platforms The criteria usedin this comparative study is related to the most significantcontributions of our work to be discussed throughout therest of the paper (see Table 1)

Software components developed using distributed plat-forms often need to use some common services such assecurity persistence transactions which have nothing to dowith the core functionality of a component and consequentlyshould live outside the component definition and implemen-tation Component platform vendors have been trying toseparate the definition and use of these common platformservices proposing different solutions

An initial solution was the CORBA interceptors [11] Aninterceptor is a hook in the CORBA object request broker(ORB) that is interposed in the invocation and response pathsbetween a client and a target object to invoke any ORBservice However there are some limitations when trying touse interceptors as aspects The most important limitationsare that it is not possible to forward the intercepted messageto a different target and that some implementations do notallow modifying the intercepted message which makes itimpossible to implement many of the essential aspects thatare required in a distributed platform such as the encryptionaspect

Later component platforms such as CCMCORBA andEJBJ2EE provided new solutions to the same problemThey offer a container programming model where thecontainer encapsulates the component implementation and
























No acc or XMLfiles


XML files XML files

























































































FIG

UR

E4

The

DA

OP

arch

itect

ure




































42 Services of DAOP



































5 RELATED WORK





















6 CAMDAOP PROTOTYPE




















ACKNOWLEDGEMENTS


REFERENCES

























































No acc or XMLfiles


XML files XML files

























































































FIG

UR

E4

The

DA

OP

arch

itect

ure




































42 Services of DAOP



































5 RELATED WORK





















6 CAMDAOP PROTOTYPE




















ACKNOWLEDGEMENTS


REFERENCES













































































































FIG

UR

E4

The

DA

OP

arch

itect

ure




































42 Services of DAOP



































5 RELATED WORK





















6 CAMDAOP PROTOTYPE




















ACKNOWLEDGEMENTS


REFERENCES





































































42 Services of DAOP



































5 RELATED WORK





















6 CAMDAOP PROTOTYPE




















ACKNOWLEDGEMENTS


REFERENCES



































































5 RELATED WORK





















6 CAMDAOP PROTOTYPE




















ACKNOWLEDGEMENTS


REFERENCES




















































6 CAMDAOP PROTOTYPE




















ACKNOWLEDGEMENTS


REFERENCES









































ACKNOWLEDGEMENTS


REFERENCES



































A Dynamic Component and Aspect-Oriented Platform · 2007-04-10 · aspect-oriented software...

Documents

Transcript of A Dynamic Component and Aspect-Oriented Platform · 2007-04-10 · aspect-oriented software...