Aspects of Composition in the Reflex AOP Kernel E´ric Tanter(cid:2) DCC – University of Chile AvenidaBlanco Encalada 2120 – Santiago, Chile [email protected] Abstract. Aspectcomposition isachallengingandmulti-facetedissue, generally under-supported by current AOP languages and frameworks. ThispaperpresentsthecompositionsupportprovidedinReflex,aversa- tilekernelformulti-languageAOPinJava.ThecoreofReflexisbasedon a model of partial reflection whose central abstractions are links: bind- ingsbetweena(point)cutandanaction.Reflexsupportsthedefinitionof aspect languages through the mapping of aspects to links. We overview thewiderangeoffeaturesforlinkcompositioninReflex—whichincludes extensible operators for ordering and nesting of links, and control over the visibility of changes made by structural aspects—, illustrating how they can beused toimplement various scenarios of aspect composition. 1 Introduction Aspect-OrientedProgramming(AOP)providesmeansforpropermodularization ofcrosscutting concerns[17]. As a matter offact, in a typicalapplication,many crosscutting concerns can be identified and modularized as aspects. This raises the issue of aspect composition, which includes questions such as: how to ensure that aspects are properly composed? Furthermore, since the points where an aspectapplies(thecutoftheaspect)areusuallyspecifiedintensionally,howcan programmers know that two aspects are affecting the same program point? The issue of aspect composition was first analyzed in [6], where a classifi- cation of conflicts between aspects is proposed. Three classes of conflicts are identified: (a) inherent conflicts, related to the incompatibility of two aspects, (b) accidentalconflicts,whentwo aspectshappento apply atthe same program pointor havesemanticalconflicts,and (c) spuriousconflicts, whichareconflicts that are detected whereas they are not actual conflicts. All in all, a number of approaches to aspect composition have been proposed, usually focusing on a particular dimension of aspect composition. First of all, two aspects that apply to the same program points (text or ex- ecution) are said to interact; in other words, the intersection of their cut is not empty.Whentwoaspectsinteract,therearetwopossibilities:eitherthey arein- compatible,andhence amutual exclusionhas tobe specified[5,10,21],soasto (cid:2) E´. Tanter is partially financed by the Milenium Nucleus Center for Web Research, Grant P04-067-F, Mideplan, Chile. W.L¨oweandM.Su¨dholt(Eds.):SC2006,LNCS4089,pp.98–113,2006. (cid:2)c Springer-VerlagBerlinHeidelberg2006 Aspects of Composition in the ReflexAOPKernel 99 retractoneoftheaspects,ortoraiseanerror.Otherwise,ifbothaspectsshould be applied,their order of application mustbe specified[5,10,31].If aspectscan actaround anexecutionpoint ofa program,thenthe notionofnestingappears, typically associated with a proceed-likemechanism [20, 31]. Furthermore, one may need to define that an aspect should apply whenever anotherapplies[5,10](aka. implicit cut),orthatanaspectappliesontoanother aspect [10, 5], for instance using a logging aspect to monitor the effectiveness of a caching aspect (aka. aspects of aspects). Finally, in AOP approaches where structuralmodificationscanbedonetoabaseprogram(e.g. addingmembersto aclass),thevisibilityofthesechangestootheraspectsshouldbecontrollable[8]. Finally, the aspect composition problem can be divided in two parts: that of the detection ofaspectinteractions,andthatoftheir resolution. SOUL/Aop[5], as well as AspectJ, only address means to specify composition, while Klaeren et al. [21] focus on means to detect interactions. Concrete approaches to detec- tion all deal with conflicts of aspects over a shared program point; being able to detect semantic interactions between two aspects that do not interact from a weaving point of view is to our knowledge not addressed by any proposal, as in the general case it is undecidable. If aspects are expressed using limited ac- tion languages,static analysismay be able to detect most semantic interactions (see [15] for an effort in this direction). Using static analysis in presence of Turing-completeaspectlanguages(atleastfor the partspecifying the actionsof aspects)is anopenissue.Itis alsogenerallyadmittedthatautomaticresolution is not feasible; an exception to this is the approach of [15], where the limited expressiveness of the aspect language is used to automatically determine and resolveinteractionsbetweenaspects.Nevertheless,in ageneralsetting,unless it can be proven that the aspects commute, the resolution of their interaction has to be specified explicitly [10]. We are not aware of any proposal addressing all these dimensions. For in- stance, AspectJ [20] does not provide any support for mutual exclusion and visibility of aspectual changes, and is limited in terms of aspects of aspects and ordering/nesting of aspects. Furthermore aspect interactions are not detected. Other proposals are thoroughly discussed in Section 7. This paper presents the different mechanisms for aspect composition in Reflex1, a versatile kernel for multi-language AOP [29]2. Reflex supports: – automatic detection of aspect interactions limiting spurious conflicts; – aspect dependencies, such as implicit cut and mutual exclusion; – extensible composition operators for ordering and nesting of aspects; – control over the visibility of structural changes made by aspects; – aspects of aspects. 1 http://reflex.dcc.uchile.cl/ 2 In[29],weonlydiscusstheissueofordering/nestingofaspects,nottheotherdimen- sions.Furthermore,theparton ordering/nestingofthispaperincludesanumberof corrections and improvements overthepreviously-presented work. 100 E´. Tanter The major contributions of this work are a very flexible solution for ordering and nesting of aspects, and an initial solution for the under-explored issue of how structural changes made by aspects affect other aspects. In Section 2, we briefly explain the idea of multi-language AOP, and its incarnation in the Reflex AOP kernel for Java. We then discuss the different aspects of composition in Reflex: aspects of aspects (Sect. 3), aspect dependen- cies (Sect. 4), ordering/nesting of aspects (Sect. 5), and visibility of structural changes(Sect.6).WethenreviewinSection7theliteratureintheareaofaspect composition, highlighting the differences with our work. Section 8 concludes. 2 Multi-language AOP and Reflex This section briefly introduces the necessary background concepts on multi- language AOP and the Reflex AOP kernel. 2.1 Multi-language AOP In previous work [28, 29], we have motivated the interest of being able to define andusedifferentaspectlanguages,includingdomain-specificones,tomodularize the different concerns of a software system. We have proposed the architecture of a so-called versatile kernel for multi-language AOP, and our current Java implementation, Reflex. AnAOPkernelsupportsthe coresemanticsofvariousAOlanguagesthrough proper structural and behavioral models. Designers of aspect languages can experiment comfortably and rapidly with an AOP kernel as a back-end, as it providesahigherabstractionlevelfortransformationthanlow-leveltransforma- tion toolkits. The abstraction level provided by our kernel is a flexible model of partialbehavioralreflection[30],extendedwithstructuralabilities.Furthermore, a crucial role of an AOP kernel is that of a mediator between different coexist- ing AO approaches: detecting interactions between aspects, possibly written in different languages,and providing expressive means for their resolution. plugin architecture languages metaobject advice pointcut detection resolution composition activation condition residue behavior structure transformation hookset shadow Fig.1. Architecture of a versatile kernel Fig.2. The link model and correspon- for multi-language AOP denceto AOPconcepts The architecture of an AOP kernel consists of three layers (Fig. 1): a trans- formation layer in charge of basic weaving, supporting both structural and be- havioral modifications of the base program; a composition layer, for detection Aspects of Composition in the ReflexAOPKernel 101 and resolutionof aspect interactions;a languagelayer,for modular definition of aspect languages (as plugins). It has to be noted that the transformation layer is not necessarily implemented by a (byte)code transformation system: it can very well be integrated directly in the language interpreter (VM). As a matter of fact, the role of a versatile AOP kernel is to complement traditional proces- sors of object-oriented languages. Therefore, the fact that our implementation inJava,Reflex,isbasedoncodetransformationshouldbe seenasanimplemen- tation detail, not as a defining characteristic of the kernel approach. 2.2 Reflex in a Nutshell Reflex is a portable library that extends Java with structural and behavioral reflective facilities. Behavioral reflection follows a model of partial behavioral reflection presented in [30]: the central notion is that of explicit links binding a set of program points (a hookset) to a metaobject. A link is characterized by a numberofattributes,amongwhichthecontrolatwhichmetaobjectsact(before, after, around), and a dynamically-evaluated activation condition. Fig. 2 depicts two links, one of which is not subject to activation, along with the correspon- dence to the AOPconceptsofthe pointcut/advicemodel.Note thatourview of AOP is inherently related to metaprogramming:an aspect cut is realizedby in- trospection of a program(both structure and execution), and its action consists of behavioral/structural modifications (intercession). Reflex does not impose a specificmetaobjectprotocol(MOP),butrathermakesiteasytospecifytailored MOPs, which can coexist in a given application. This means that one can spec- ify,ona per-link basis,the exactcommunicationprotocol(which methodto call withwhicharguments)withthemetaobject.Adetailedcasestudyofsupporting the dynamic crosscutting of AspectJ in Reflex can be found in [25]. The aforementionedlinks are called behavioral links to distinguish them from structurallinks,whichareusedtoperformstructuralreflection.Astructurallink bindsasetofclassestoametaobject,whichcanbothintrospectandmodifyclass definitions via a class-objectstructuralmodel similar to that of Javassist[7]: an RPool object gives access to RClass objects, which in turn give access to their membersasRMemberobjects(eitherRField,RMethod,orRConstructor),which inturngiveaccesstotheirbodiesasRExprobjects(withaspecifictypeforeach kind of expression).These objects are causally-connectedrepresentations of the underlying bytecode, offering a source-level abstraction over bytecode. ReflexisimplementedasJava5instrumentationagentoperatingonbytecode, typically at loadtime. The transformation process consists, for each class being loaded,of(1)determiningthesetofstructurallinksthatapplytoit,andapplying them, and (2) determining the set of behavioral links and installing them. The reasonofthisorderingisdiscussedinSection6.Duringinstallationofbehavioral links, hooks are inserted in class definitions at the appropriate places in order toprovokereificationatruntime,followingthemetaobjectprotocolspecifiedfor each link. 102 E´. Tanter 2.3 From Aspects to Links As said above, Reflex relies on the notion of an explicit link binding a cut to an action. Linksarea mid-levelabstraction,in betweenhigh-levelaspects andlow- level code transformation. How aspect languages are defined and implemented over the kernel is out of the scope of this paper (preliminary elements can be found in [29]). Composition of aspects at the kernel level is expressed in terms of link composition, which is the central matter of this paper. A simple AspectJ aspect,comprisingofa singleadvice associatedto a simple pointcut (with no higher-order pointcut designator), is straightforwardly im- plemented in Reflex with a link (as in Fig. 2). However, most practical AOP languages, like AspectJ, make it possible to define aspects as modular units comprising more than one cut-action pair. In Reflex this corresponds to differ- ent links, with one action bound to each cut. Furthermore, AspectJ supports higher-order pointcut designators, like cflow. In Reflex, the implementation of such an aspect requires an extra link to expose the control flow information. There is therefore an abstractiongapbetween aspects and links: a single aspect may be implemented by severallinks. This abstraction gap is the matter of the language layer, as discussed in [29]. 3 Aspects of Aspects Defining aspects of aspects, i.e. aspects that apply to the execution of other aspects, is a feature that can be useful to handle crosscutting in aspects them- selves [5, 13, 10]. For instance, a profiling aspect monitoring the efficiency of a caching aspect. Another example is an aspect resolving an accidental se- mantical conflict between two aspects [6]. Unsurprisingly, Reflex supports as- pects of aspects, a feature supported by almost every AOP proposal (e.g. the adviceexecution pointcut descriptor of AspectJ). A link A can apply to the action of another link B by having the cut of A matching operations that oc- cur in the metaobject associated to B. Since metaobjects are standard objects, a link can apply not only on the execution of the metaobject methods (simi- larlyto adviceexecutioninAspectJ), butalsoto allotheroperationsoccuring within the metaobject: field accesses, created objects, messages sent, etc. There is indeed no difference between controlling the execution of a base application object and that of a metaobject. A distinguishing feature of aspects of aspects in Reflex comes if we con- sider aspects acting around an execution point, for instance a caching aspect. Typically, a caching aspect holds cached values, and when a cache fault occurs, the aspect invokes the original operation via proceed. Such a proceed is done in Reflex via calling the proceed method of an execution point closure (EPC) object,which a metaobjectcanrequest.If we wantto profile the cachingaspect to determine the ratio of cache hits/faults, we can define a profiling aspect that matches execution of the caching method, and separately, that of the proceed method on the EPC object. This definition is not feasible in AspectJ, because proceed is a special expression that is not visible to other aspects. Aspects of Composition in the ReflexAOPKernel 103 4 Aspect Dependencies Aspect dependencies can be of two kinds: implicit cut (“apply A whenever B applies”) andmutualexclusion(“never apply A if B applies”). Thesedependen- cies between aspects are mentioned in [5, 10, 21]. In addition, we also consider the case of forbidden interactions, an error mechanism to forbid two aspects to interact [6]. 4.1 Implicit Cut Animplicitcutisobtainedbysharingthecutspecificationbetweentwoaspects: In AspectJ, this is done by sharing pointcuts; in Reflex, by sharing hooksets (pointcutshadows)andactivations(pointcutresidues).Considerane-commerce application on which we apply a discount aspect that applies to frequent cus- tomers, implemented by link discount, and a tracing aspect implemented by the link trace. The following ensures that trace applies whenever discount does (BLink stands for behavioral link): BLink trace = Links.get(discount.getHookset(), <mo>); trace.addActivation(new SharedActivation(discount)); The first line states that trace has the same hookset than discount (<mo> standsforthe metaobjectspecification,notrelevanthere).The secondlineadds anactivationcondition,SharedActivation,whichensuresthattheactivationof trace is that of discount:even if the activation condition of discountevolves dynamically, the dependency of trace to discount is ensured. BLink trace = Links.getSameCut(discount, <mo>); The above getSameCut method is a convenience method equivalent to the pre- vious version. It just hides to programmers the way the implicit cut is realized. Finally, note that an implicit cut by definition implies that both aspects apply at the same points, therefore raising the issue of their ordering/nesting. This is addressed in Section 5. 4.2 Mutual Exclusion Mutual exclusion between two aspects is obtained in Reflex by declaring that a link should not apply if another one does. As an example, consider a bingo aspect(implementedbyabingolink)thatisusedinthesameapplicationasthe discounting aspect: every 1000 buyings, a big discount is offered. If a frequent customer happens to be the winner of the bingo, then the standard discount grantedto frequentcustomersshouldnotapply3.The followingstatementspec- ifies that discount should not apply if bingo does: Rules.declareMutex(discount, bingo); 3 This example is taken from an EAOPillustration [16, 14]. 104 E´. Tanter Following this declaration, Reflex acts differently depending on whether the de- pendent links are subject to dynamic activation or not. If both links are not activatable (i.e. no pointcut residue), the mutual exclusion dependency can be resolved at weaving time, when hooks are inserted in the code. If one of them is indeed subject to dynamic activation, then Reflex postpones the resolution of the dependency to runtime: when control flow reaches a hook shared be- tween mutually-exclusive links, the activation condition of the dominant link (here,bingo)isevaluated,andconsequently,onlyoneofthetwolinksisapplied (bingo, or discountif bingo is not active). In the face of multiple mutual exclusion dependencies, the current algorithm first sorts out all links which are only dominant and then eliminates dominated links if their dominant is always active, or adds a dynamic condition to the dominated links if their dominant is subject to dynamic activation. At each step, the set of rules that apply is reduced. For instance, if links A, B and C are interacting and the mutex relations are mutex(A,B)andmutex(B,C),the algorithmfirstputsAintheremaininglinks set, and removes B from the links to consider (supposing A is always active). Then, only C and A remain, and since no mutex is declared between both, C is added to the remaining links. The final solution is therefore A-C. Now, if A is subject to an activation condition, B is not removed: rather, it is put in the remaining links, but subject to a dynamic condition on the activation of A. At thenextstep,mutex(B,C)applies.SincetheapplicationofBdependsonthatof A,C wouldbe keptandsubject to the activationofB.Consequently,atruntime, either A-C or B result, depending on whether A is active or not. Forbidden Interactions. A particular case of mutual exclusion is when in- teraction between two aspects should be considered an error (aka. an inherent conflict[6]).Inthiscase,onedoesnotwanttospecifywhichlinktoapplyornot, but rather to raise an exception. This is done in Reflex using declareError: Rules.declareError(discount, bingo); Similarly to declareMutex, the effect of declareError can occur at weaving time if both links are not activatable, or at runtime otherwise. In both cases, a ForbiddenInteractionexception is thrown. 5 Ordering and Nesting of Aspects As previously mentioned, the Reflex AOP kernel follows the general approach advocated by Douence et al., of automatic detection and explicit resolution of aspect interactions [10]: – Thekernelensuresthatinteractionsaredetected,andreportedtousersupon under-specification (Sect. 5.1). – Thekernelprovidesexpressiveandextensiblemeanstospecifytheresolution of aspect interactions (Sect. 5.2). – From such specifications, it composes links appropriately (Sect. 5.3). Aspects of Composition in the ReflexAOPKernel 105 5.1 Interaction Detection Anaspectinteractionoccurswhenseveralaspectsaffectthesameprogrampoint (execution or structure). Two behavioral links interact statically if the intersec- tion of their hooksets is not empty. Still, the cut of an aspect may include a dynamically-evaluatedcondition(recallFig.2):wesaythattwobehaviorallinks interact dynamically if they interact statically and they are both active at the same time. Since link ordering is resolved statically (when introducing hooks) and activation conditions can be changed dynamically, Reflex adopts a defen- sive approach:any static interactionis reported,and must be consideredby the developer,so that a dynamic interactionis never under-specified.Our approach limitsthenumberofspuriousconflictsbecauseitisbasedontheweavingprocess, which occurs on a by-need basis. In the presence of open systems with dynamic classlaoding,twoaspectsthatmaytheoreticallyinteractforagiven program(as in the formal approach of [10]) but do not in a particular run of that program do not raise detected conflicts. Two structural links interact if the intersection of their class sets is not empty.We do notdiscriminate betweenstatic anddynamicinteraction,because structural links are applied directly at load time. At present our approach for structurallink interactions may reportspurious conflicts because two links may affectthesameclassorthogonally.Finer-graineddetectionofinteractionsamong structural links is left as future work. Upon interactions, Reflex notifies an interaction listener. The default inter- action listener simply issues warnings upon under-specification (see [29] for an example),informing the user that specificationshould be completed.It is possi- ble to use other listeners, e.g. for on-the-fly resolution. 5.2 Ordering and Nesting Atinteractionpoints,resolutionmustbespecified.Iflinksaremutuallyexclusive, specifyingtheirorderingisnotnecessary4.Otherwise,orderingmustbespecified; this section explains how this is done for behavioral links5. Theinteractionbetweentwobefore-afteraspectscanberesolvedintwoways: either one always applies prior to the other (both before and after), or one “surrounds” the other [5, 10], although AspectJ only supports wrapping. These alternativescanbe expressedusingcompositionoperatorsdealingwithsequenc- ing and wrapping. Considering aspects that can act around an execution point (suchasacachingaspect),thenotionofnestingasinAspectJ appears:anested 4 Wedeliberately separate theissue of dependencies from ordering/nesting, although mutual exclusion and forbidden interactions could be expressed with the operators explainedinthissection.Thereasonistwo-fold:first,itiseasierandhigher-levelfor theusertodeclaredependenciesaspresentedinSect.4.2;second,itismoreefficient for the weaver to“sort out” interacting links before tryingto order them. 5 The case of structural links is simpler because they are always applied sequentially at thetime a class is about to beloaded; no nesting is involved. 106 E´. Tanter b1 b2 b1 b1 b2 weaving b2 point op rr12 op r1 r2 op proceed op aa12 aa21 a1 a2 op oorpigeirnaatilon (a)seq(l1,l2) (b)wrap(l1,l2) (c)wrap(l1,l2) no around with around Fig.3. Orderingand nesting scenarios advice is only executed if its parent around advice invokes proceed. Around advices cannot be simply sequenced in AspectJ: they always imply nesting, and hence their execution always depends on the upper-level around advice [31]. In Reflex, link composition rules are specified using composition operators. The rule seq(l ,l ) uses the seq operator to state that l must be applied be- 1 2 1 fore l , both before and after the considered operation occurrence. The rule 2 wrap(l ,l ) means that l must be applied within l , as clarified hereafter. 1 2 2 1 Kernel operators. User composition operators are defined in terms of lower- level kernel operators not dealing with links but with link elements. A link ele- ment is a pair (link,control), where control is one of the control attributes: for instance, b (resp. a ) is the link element of l for before (resp. after) control. 1 1 1 Therearetwokerneloperators,ordandnestwhichexpressrespectivelyordering and nesting of link elements. nest only applies to around link elements: the rule nest(r,e) means that the application of the around element r nests that of the linkelemente.Theplaceofthenestingisdefinedbytheoccurrencesofproceed within r. Sequencing and wrapping can hence be defined as follows: seq(l ,l )=ord(b ,b ),ord(r ,r ),ord(a ,a ) 1 2 1 2 1 2 1 2 wrap(l ,l )=ord(b ,b ),ord(a ,a ),nest(r ,b ),nest(r ,r ),nest(r ,a ) 1 2 1 2 2 1 1 1 1 2 1 2 Fig. 3 illustrates sequencing and wrapping, showing seq(l ,l ) with all link ele- 1 2 ments (a), and the result of wrap(l ,l ) first without around link elements (b), 1 2 and then with around link elements (c). Weaving points are explained later on. Composition operators. Reflex makes it possible to define a handful of user operators for composition on top of the kernel operators.For instance, Seq and Wraparebinaryoperatorsthatimplementtheseqandwrapoperatorsasdefined above: class Seq extends CompositionOperator { void expand(Link l1, Link l2){ ord(b(l1), b(l2)); ord(r(l1), r(l2)); ord(a(l1), a(l2)); }} Aspects of Composition in the ReflexAOPKernel 107 class Wrap extends CompositionOperator { void expand(Link l1, Link l2){ ord(b(l1), b(l2)); ord(a(l2), a(l1)); nest(r(l1), b(l2)); nest(r(l1), r(l2)); nest(r(l1), a(l2)); } } The methods b (before), r (around), a (after), ord, and nest are provided by CompositionOperator.The expandmethod,evaluatedwheneveraninteraction between two links occurs, defines a user operator in terms of kernel operators. Below is an example of a composition rule declared between two interacting aspects: a timing aspect measuring method execution time, and a synchroniza- tion aspect ensuring mutual exclusion of methods. Both aspects act before and after method executions. The declared composition implies that the timing as- pect measures execution time of methods, including the synchronizationcost: BLink timer = ...; BLink synchro = ...; Rules.declare(new Wrap(timer, synchro)); Another example of composition operator is Any: this operator simply states that the order of composition of two given links does not matter (similarly to commute in [10]); the kernel is free to compose them arbitrarily. Currently, the Any operator is implemented as a Seq operator, but this is not something users should rely upon: class Any extends Seq {} Higher-level operators. Users can define higher-leveloperators based on the building blocks of Reflex. For instance, we can define a variant of Wrap that, in additiontotheWrapsemantics,specifiesthatthenestedlinkdoesnotapplyifthe wrapping link is not active. We call this operator DWrap (D for “dependency”): class DWrap extends Wrap { void expand(Link l1, Link l2){ super.expand(l1, l2); // wrap semantics l2.addActivation(new SharedActivation(l1)); // active dependency } } 5.3 Hook Generation When detecting link interactions,Reflex generatesahook skeletonbasedonthe specifiedcompositionrules,similarlytoFig.3.Thehookskeletonisthenusedfor drivingthe hookgenerationprocess:takingintoaccounthowlinkelementshave to be inserted, with the appropriate calls to metaobjects. In order to support nesting of aspects with proceed, Reflex adopts a strategy similar to that of AspectJ described in [19], based on the generation of closures. As mentioned earlier, in order to be able to do proceed, a metaobject is given an execution point closure (EPC) object, which has a proceedmethod, as well as methods for changing the actual arguments and receiver of the replaced