AspectJ2EE = AOP + J2EE

25 Pages·2004·0.21 MB·English

AspectJ2EE = AOP + J2EE
TowardsanAspectBased,ProgrammableandExtensible
MiddlewareFramework
TalCohen(cid:63)andJoseph(Yossi)Gil(cid:63)(cid:63)
{ctal, yogi}@cs.technion.ac.il
DepartmentofComputerScience
Technion—IsraelInstituteofTechnology
TechnionCity,Haifa32000,Israel
Abstract. J2EE is a middleware architecture augmented with supporting tools
fordevelopinglargescaleclient/serverandmulti-tierapplications.J2EEusesEn-
terpriseJavaBeansasitscomponentmodel.Therealizationofthesecomponents
by a J2EE application server can be conceptually decomposed into distinct as-
pectssuchaspersistence,transactionmanagement,security,andloadbalancing.
However, current servers do not employ aspect-oriented programming in their
implementation.Inthispaper,wedescribeanewaspectlanguage,AspectJ2EE,
gearedtowardsthegeneralizedimplementationofJ2EEapplicationservers,and
applicationswithinthisframework.AspectJ2EEcanbeeasilyemployedtoex-
tendthefixedsetofservicesthattheseserversprovidewithnewservicessuchas
loggingandperformancemonitoring.Eventier-cuttingconcernslikeencryption,
data compression, and memoization can be added while avoiding the drags of
cross-cuttingandscatteredcode.
AspectJ2EE is less general (and hence less complicated) than AspectJ, yet
demonstrably powerful enough for the systematic development of large scale
(anddistributed)applications.Theintroductionofparameterizedaspectsmakes
aspectsinAspectJ2EEmoreflexibleandreusablethanaspectsinAspectJ.
AspectJ2EEalsogeneralizestheprocessofbindingservicestouserapplications
in the application server into a novel deploy-time weaving of aspects. Deploy-
timeweavingissuperiortotraditionalweavingmechanisms,inthatitpreserves
theobjectmodel,hasabettermanagementofaspectscope,andpresentsamore
understandableandmaintainablesemanticmodel.
1 Introduction
Thetermenterpriseapplicationsisusedtodescribethelarge-scalesoftwareprograms
usedtooperateandmanagelargeorganizations.Theworld’slargestandmostimportant
software systems are enterprise applications; this includes the programs used to run
government organizations, banks, insurance companies, financial institutes, hospitals,
andsoforth.Enterpriseapplicationsmaketheworldgoaround.
(cid:63)Contactauthor
(cid:63)(cid:63)ResearchsupportedinpartbytheIBMfacultyaward
In many cases, enterprise applications are based on a heterogeneous platform
configuration, connecting various independent systems (called tiers) into a coherent
whole. The various tiers of an enterprise application can include, e.g., legacy main-
frame servers, dedicated database servers, personal computers, departmental servers,
andmore.
Thecorefunctionalityservedbyenterpriseapplicationsisoftenquitesimple.Itdoes
notinvolveoverlyelaboratecomputationorposecomplexalgorithmicdemands.How-
ever,developingenterpriseapplicationsisconsideredadauntingtask,duetoorthogonal
requirementspresentedbymostoftheseapplications:uncompromisingreliability,un-
yieldingsecurity,andcompletetrustworthiness.
The staggering demand for rapid development of enterprise applications initiated
a series of component-based middleware architectures. A prime example of these,
and emphasizing client/server and multi-tier structures, is Java 2, Enterprise Edition
(J2EE)[1]whichusesEnterpriseJavaBeans(EJB)[2]asitscomponentmodel.
Aspect-orientedprogramming(AOP)[3],themethodologywhichencapsulatesthe
code relevant to any distinct non-functional concern in aspect modules, can also be
thought of as answering the same demand [4,5]. As it turns out, the functionality of
J2EEapplicationserverscanbeconceptuallydecomposedintodistinctaspectssuchas
persistence,transactionmanagement,security,andloadbalancing.Theeffectivenessof
thisdecompositionisevidentfromKimandClarke’scasestudy[6],whichindicatesthat
theEJBframeworkdrasticallyreducestheneedforgenericAOPlanguageextensions
andtools.
Yet, as we shall see here, the EJB support for functional decomposition is limited
andinflexible.IncaseswherethecannedEJBsolutionisinsufficient,applicationsresort
againtoatangledandhighlyscatteredimplementationofcross-cuttingconcerns.Part
ofthereasonisthatcurrentJ2EEserversdonotemployAOPintheirimplementation,
anddonotenabledeveloperstodecomposenewnon-functionalconcernsthatshowup
duringthedevelopmentprocess.
A natural quest then is for a harmonious integration of middleware architectures
andAOP.Indeed,therewereseveralworksonanAOP-basedimplementationofJ2EE
serversandservices(seee.g.,theworkofChoi[7]).
Thenewapproachandmaincontributionofthispaperisindrawingfromthelessons
of J2EE and its implementation to design a new AOP language, AspectJ2EE, geared
towards the generalized implementation of J2EE application servers and applications
within this framework. In particular, AspectJ2EE generalizes the process of binding
services to user applications in the J2EE application server into a novel deploy-time
weaving mechanism. Deploy-time weaving is superior to traditional weaving mecha-
nisms in that it preserves the object model, has a better management of aspect scope,
andpresentsamoreunderstandableandmaintainablesemanticmodel.
Asaconsequenceofitsparticularweavingmethod,andofstayingawayfromspe-
cialized JVMs and bytecode manipulation for aspect-weaving, AspectJ2EE is similar
to, yet (slightly) less general than, the AspectJ programming language [8]. Neverthe-
less,standingontheshouldersoftheJ2EEexperience,wecanarguethatAspectJ2EE
ishighlysuitedtosystematicdevelopmentofenterpriseapplications.Perhapsthemain
limitationofAspectJ2EEwhencomparedtoApsectJisthatitdoesnotdirectlysupport
fieldreadandwritejoinpoints,andhencecannotbeemployedforlow-leveldebugging
or nit-picking logging. If however the design of a software solution is such that the
management of a certain field can be decomposed into several aspects, then this field
canberealizedasaJ2EEattribute,withjoinpointsatitsretrievalandsetting.
ThesemanticmodelofapplyinganaspecttoaclassinAspectJ2EEisshowntobe
conceptuallysimilartotheapplicationofagenerictypedefinitiontoaclass,yielding
anewtype.Thishasboththeoreticalandpracticalimplications,sincemaintainingthe
standard object model makes AspectJ2EE easier to understand and master, a crucial
consideration for the widespread adoption of any new technology in the field of en-
terprise application development1. Despite the similarities, we show that AspectJ2EE
aspects are more flexible and expressive than generics when used to extend existing
types.
AspectJ2EE also introduces parameterized aspects. These constructs, combined
with AspectJ2EE’s aspect binding language, make aspects in AspectJ2EE more
reusablethanAspectJaspects.
Westressthatunlikepreviousimplementationsofaspectswithinthestandardobject
model,AspectJ2EEdoesnotmerelysupport“before”and“after”advicesand“method
execution” join points. AspectJ2EE supports “around” advices, and a rich set of join
points,includingcontrol-flowbased,conditional,andobject-andclass-initialization.
UsingAspectJ2EE,thefixedsetofstandardJ2EEservicesisreplacedbyalibraryof
coreaspects.Theseservicescanbeaugmentedwithnewones,suchasloggingandper-
formancemonitoring.Moreover,theAspectJ2EElanguagehasspecificsupportforthe
composition of aspects that are scattered across program tiers (tier-cutting concerns),
suchasencryption,datacompression,andmemoization.
Terminology. The article assumes basic familiarity with standard AOP terms, in-
cludingjoinpoint (awell-definedpointintheprogram’sexecution),pointcut (aspec-
ification of a set of join points), advice (code that is added at specified join points),
weaving (the process of applying advices to join points), and aspect (a language con-
structcontainingadvices).
Outline. Section 2 makes the case for AspectJ2EE by explaining in greater detail
howJ2EEservicescanbethoughtofasaspects.DiscussingthebenefitsofusingAOP
for these services, we present the main points in which the design of AspectJ2EE is
differentthanstandardAOP.ThedeploytimeweavingstrategyisdiscussedinSect.3.
Section 4 shows how the AspectJ2EE approach introduces AOP into the OOP model
withoutbreakingit.Section5introducessomeofthefinepointsandinnovationsinthe
language,anddiscussesimplementationdetails.Section6listsseveralpossibleinnova-
tiveusesforAspectJ2EE,someofwhichcanleadtosubstantialperformancebenefits.
Section7concludes.
1Historically,thedevelopersofenterpriseapplicationsareslowtoadoptnewtechnologies;a
technologyhastoproveitselfagainandagain,overalongperiodoftime,beforethemain-
tainersofsuchlarge-scaleapplicationswillevenconsideradoptingitfortheirneeds.Itisnot
acoincidencethatmanylargeorganizationsstilluseandmaintainsoftwaredevelopedusing
some technologies, such as COBOL [9], that other sectors of the software industry view as
thoroughlyoutdated.
2 TheCaseforAOPinJ2EE
2.1 J2EEServicesasManagersofNon-FunctionalConcerns
Ideally, with the J2EE middleware framework (and to a lesser extent in other such
frameworks),thedeveloperonlyhastoimplementthedomain-specificbusinesslogic.
This“businesslogic”isnoneotherthanwhattheAOPcommunitycallsfunctionalcon-
cerns. The framework takes charge of issues such as security, persistence, transaction
management, and load balancing which are handled by services provided by the EJB
container [10, Chap. 2]. Again, these issues are none other than non-functional con-
cernsinAOPjargon.
Suppose for example that the programmer needs data objects whose state is mir-
roredinpersistentstorage.Thisstoragemustthenbeconstantlyupdatedastheobject
is changed during its lifetime, and vice versa. Automatic updates can be carried out
by the Container-Managed Persistence (CMP) service of the EJB container. To make
this happen, the objects should be defined as entity beans [2, Chap. 10]. Bean types
are mapped to tables in a relational database with an appropriate XML configuration
file.Thisdeploymentdescriptor filealsomapseachbeanattribute(persistentinstance
variable)toafieldofthecorrespondingtable.
AnotherstandardJ2EEserviceissecurity,usinganapproachknownasrole-based
security. Consider, for example, a financial software system with two types of users:
clientsandtellers.Aclientcanperformoperationsonhisownaccount;atellercanper-
formoperationsonanyaccount,andcreatenewaccounts.Bysettingtherelevantvalues
in the program’s deployment descriptor, we can limit the account-creation method so
thatonlyusersthatwereauthenticatedastellerswillbeabletoinvokeit.
Other services provided by the EJB container handle issues such as transaction
management and load balancing. The developer specifies which services are applied
to which EJB. Deployment descriptors are used for setup and customization of these
services.Thus,J2EEreducestheimplementationofmanynon-functionalconcernsinto
mereconfigurationdecisions;inmanyways,theyturnintonon-concerns.
And while this work focuses on EJBs, the J2EE design guideline, according to
whichthedeveloperconfiguresvariousservicesviadeploymentdescriptors,isnotlim-
ited to EJBs only. It is also used in other parts of the J2EE platform. For example,
servlets (server-side programs for web servers) also receive services such as security
from their container, and access to specific servlets can be limited using role-based
security.ThisisalsotrueforJavaServerPages(JSPs),anotherkeypartoftheJ2EEar-
chitecture.Hence,inourfinancialsoftwareexample,certainprivilegedwebpagescan
beconfiguredsothattheywillbeonlyaccessibletotellersandnottoclients.
The various issues handled by EJB container services were always a prime target
forbeingimplementedasaspectsinAOP-basedsystems[11,pp.13–14].Forexample,
Soares et. al. [4] implement distribution, persistence and transaction aspects for soft-
ware components using AspectJ. Security was implemented as an aspect by Hao et.
al. [5]. The use of aspects reduces the risk of scattered or tangled code when any of
thesenon-functionalconcernsisaddedtoasoftwareproject.
Conversely,wefindthatJ2EEdevelopers,havingthebenefitofcontainerservices,
do not require as much AOP. Indeed, Kim and Clarke [6] present a case study where
theyinvestigatetherelevanceofAOPtoJ2EEdevelopers.Thecasestudycomprisedof
ane-votingsystemwhichincludedfivenon-functionalconcerns:(1)persistentstorage
ofvotes,(2)transactionalvoteupdates,(3)securedatabaseaccess,(4)userauthentica-
tion,and(5)securecommunicationsusingapublickeyinfrastructure[6,Table1].Of
these five non-functional concerns, not one remained cross-cutting or introduced tan-
gledcode.ThefirstthreewerehandledbystandardJ2EEservices,configuredbysetting
thepropervaluesinthedeploymentdescriptors.Thelasttwowereproperlymodular-
izedintoasmallnumberofclasses(twoclassesineachcase)withnocodereplication
andnotangledcode.
TheimplementationofservicesinJ2EEalsoincludessophisticatedmechanismsfor
combiningeachoftheservices,asconfiguredbythedeploymentdescriptors,withthe
user code. We will discuss these mechanisms, which can be though of as the equiva-
lent of aspect weaving, in detail below (Sect. 3). Suffice to say at this point that the
combinationinJ2EEiscarriedoutwithoutresortingtodrasticmeanssuchasbytecode
patchingandcodepreprocessing—meanswhichmaybreaktheobjectmodel,confuse
debuggersandotherlanguagetools,andevenobfuscatethesemantics.
2.2 LimitationsoftheServices-BasedSolution
EventhoughtheJ2EEframeworkreducesthedeveloper’sneedforAOPtools,thereare
limits to such benefits. The reason is that although the EJB container is configurable,
itisneitherextensiblenorprogrammable.Pichler,Ostermann,andMezini[12]referto
thecombinationofthesetwoproblemsaslackoftailorability.
Thecontainerisnotextensibleinthesensethatthesetofservicesitoffersisfixed.
Kim and Clarke [6] explain why supporting logging in the framework would require
scatteredandtangledcode.Ingeneral,J2EElackssupportforintroducingnewservices
for non-functional concerns which are not part of its specification. Among these con-
cerns,wementionmemoization,preconditiontesting,andprofiling.
Thecontainerisnotprogrammableinthesensethattheimplementationofeachof
itsservicescannotbeeasilymodifiedbytheapplicationdeveloper.Forexample,current
implementationsofCMPrelyonarigidmodelformappingdataobjectstoarelational
database. The service is then useless in the case that data attributes of an object are
drawnfromseveraltables.Norcanitbeusedtodefineread-onlybeansthataremapped
to a database view, rather than a table. The CMP service is also of no use when the
persistentdataisnotstoredinarelationaldatabase(e.g.,whenflatXMLfilesareused).
Any variation on the functionality of CMP is therefore by re-implementation of
objectpersistence,usingwhatiscalledBean-ManagedPersistence(BMP).BMPsup-
portrequiresintroducingcallbackmethods(calledlifecyclemethodsinEJBparlance)
ineachbean.MethodejbLoad()(ejbStore())forexampleisinvokedwhenever
memory(store)shouldbeupdated.
TheimplicationisthatthepurebusinesslogicofEJBclassesiscontaminatedwith
unrelated I/O code. For example, the tutorial code of Bodoff et. al. [13, Chap. 5],
demonstrates a mixup in the same bean of SQL queries and a Java implementation
offunctionalconcern.Conversely,wefindthatthecodeinchargeofpersistenceisscat-
teredacrossallentitybeanclasses,ratherthanbeingencapsulatedinasinglecohesive
module.
Worse, BMP may lead to code tangling. Suppose for example that persistence is
optimizedbyintroducinga“dirty”flagfortheobject’sstate.Then,eachbusinesslogic
methodwhichmodifiesstateistangledwithcodetoupdatethisflag.
SimilarscatteringandtanglingissuesrisewithmodificationstoanyotherJ2EEser-
vice.Inourfinancialsoftwareexample,asecuritypolicymayrestrictaclienttotransfer
fundsonlyoutofhisownaccounts.Thefunds-transfermethod,whichisaccessiblefor
bothclientsandtellers,actsdifferentlydependingonuserauthentication.Suchapolicy
cannot be done by setting configuration options, and the method code must explicitly
refertothenon-functionalconcernofsecurity.
To summarize, whenever the canned solutions provided by the J2EE platform are
insufficient for our particular purpose, we find ourselves facing again the problems
ofscattered,tangledandcross-cuttingimplementationofnon-functionalconcerns.As
Duclos,EstublierandMorat[14]state:“clearly,the‘component’technologyintroduced
successfullybyEJBformanagingnon-functionalaspectsreachesitslimits”.
2.3 MarryingJ2EEwithAOP
HavingexposedsomeofthelimitationsofJ2EE,itisimportanttostressthattheframe-
work enjoys extensive market penetration, commanding a multi-billion dollar mar-
ket[15].
Incontrast,AOP,withitselegantsyntaxandrobustsemantics,didnotfinditsplace
yet in mainstream industrial production. It is only natural then to seek a reconcilia-
tionofthetwoapproaches,inproducinganaspectbased,programmableandextensible
middlewareframework.Indeed,Pichleret.al.callfor“amarriageofaspectsandcom-
ponents”[12,Sect.4].
Obviously,eachoftheservicesthatJ2EEprovidesshouldbeexpressedasanaspect.
Thecollectionoftheseserviceswillbethecoreaspectlibrary,whichrelyingonJ2EE
success,wouldnotonlybeprovablyuseful,butalsohighlycustomizable.Developers
willbeabletoaddtheirownaspects(e.g.,logging)ormodifyexistingones,possibly
usinginheritanceinordertore-useprovenaspectcode.
Theresultingaspectscouldthenbeviewedasstand-alonemodulesthatcanbere-
usedacrossprojects.Anotherimplicationisthatnotallaspectsmustcomefromasingle
vendor;inthecurrentJ2EEmarket,allJ2EE-standardservicesareprovidedbytheJ2EE
applicationservervendor.Ifdeveloperscanchoosewhichaspectstoapply,regardless
oftheapplicationserverused,thenaspectsimplementedbydifferentvendors(orbythe
developersthemselves)canallbeusedinthesameproject.
Choi [7] was the first to demonstrate that an EJB container can be built from the
groundupusingAOPmethodologies,whilereplacingserviceswithaspectswhichexist
independently of the container.The resulting prototype server, called AES, allowsde-
veloperstoaddandremoveaspectsfromthecontainer,changingtheruntimebehavior
ofthesystem.
Release4.0ofJBoss[16],anopen-sourceapplicationserverwhichimplementsthe
J2EEstandard,supportsaspectswithnolanguageextensions[17].Aspectsareimple-
mented as Java classes which implement a designated interface, while pointcuts are
defined in an XML syntax. These can be employed to apply new aspects to existing
beans without introducing scattered code. Standard services however are not imple-
mentedwiththisaspectsupport.
Focaltoallthispriorworkwastheattempttomakeanexistingwidespreadframe-
workmorerobustusingAOPtechniques.Inthisresearch,weproposeanewapproachto
thesuccessfulmarriageofJ2EEandAOPinwhichthedesignofanewAOPlanguage
draws from the lessons of J2EE and its programming techniques. The main issues in
whichtheAspectJ2EElanguagediffersfromAspectJare:
1. Aspecttargets.AspectJcanapplyaspectstoanyclass,whereasinAspectJ2EEas-
pects can be applied to enterprise beans only. In OOP terminology these beans
arethecoreclassesoftheapplication,eachofwhichrepresentsonecomponentof
the underlying data model. As demonstrated by the vast experience accumulated
in J2EE, aspects have great efficacy precisely with these classes. We believe that
theacceptanceofaspectsbythecommunitymaybeimprovedbynarrowingtheir
domainofapplicability,whichshouldalsobenefitunderstandabilityandmaintain-
ability.
2. Weaving method. Weaving the base class together with its aspects in AspectJ2EE
reliesonthesamemechanismsemployedbyJ2EEapplicationserverstocombine
services with the business logic of enterprise beans. This is carried out entirely
withinthedominionofobjectorientedprogramming,usingthestandardJavalan-
guage, and an unmodified Java virtual machine (JVM). In contrast, different ver-
sions of AspectJ used different weaving methods relying on preprocessing, spe-
cialized JVMs, and dedicated byte code generators, all of which deviate from the
standardobjectmodel.
3. Aspectparametrization.AspectsinAspectJ2EEcancontaintwotypesofparame-
tersthatacceptvaluesatthetimeofaspectapplication:abstractpointcutdefinitions,
and field values. Aspects that contain abstract pointcut definitions can be applied
to EJBs, by providing (in the EJBs deployment descriptor) a concrete definition
foreachsuchpointcut.Thisprovidessignificantflexibilitybyremovingundesired
cohesion between aspects and their target beans, and enables the development of
highlyreusableaspects.Itcreates,inAspectJ2EE,theequivalentofCaesar’s[18]
much-touted separation between aspect implementation and aspect binding. Field
values,theothertypeofaspectparameters,alsogreatlyincreaseaspectreusability
andbroadeneachaspect’sapplicability.
4. Supportfortier-cuttingconcerns.AspectJ2EEisuniquelypositionedtoenablethe
localization of concerns that cross not only program modules, but program tiers
as well. Such concerns include, for example, encrypting or compressing the flow
of information between the client and the server (processing the data at one end
andreversingtheprocessattheother).EvenwithAOP,thehandlingoftier-cutting
concernsrequiresscatteringcodeacrossatleasttwodistinctprogrammodules.We
show that using AspectJ2EE, many tier-cutting concerns can be localized into a
single,coherentprogrammodule.
3 DeploymentandDeploy-TimeWeaving
Weaving is the process of inserting the relevant code from various aspects into desig-
natedlocations,knownasjoinpoints,inthemainprogram.Intheiroriginalpresenta-
tionofAspectJ[8],Kiczaleset.al.enumerateanumberofweavingstrategies:“aspect
weavingcanbedonebyaspecialpre-processor,duringcompilation,byapost-compile
processor,atloadtime,aspartofthevirtualmachine,usingresidualruntimeinstruc-
tions, or using some combination of these approaches”, each of which was employed
inatleastoneaspect-orientedprogramminglanguageimplementation.
As noted before, AspectJ2EE uses its own peculiar deploy-time weaving strategy.
Inthissectionwemotivatethisstrategyandexplainitingreaterdetail.
3.1 UnboundedWeavingConsideredHarmful
All weaving strategies mentioned in the quote above transgress the boundaries of the
standard object model. Patching binaries, pre-processing, dedicated loaders or virtual
machines, will confuse language processing tools such as debuggers, and may have
otheradverseeffectsongeneralityandportability.
However,beyondtheintricaciesoftheimplementation,weavingintroducesamajor
conceptualbottleneck.Asearlyas1998,Walker,BaniassadandMurphy[19]notedthe
disconcertofprogrammerswhenrealizingthatmerelyreadingthesourceofacodeunit
isnotsufficientforunderstandingitsruntimebehavior2.
3.2 Non-IntrusiveExplicitWeaving
TheremedysuggestedbyConstantinides,Bader,andFayadintheirAspectModerator
framework [20] was restricting weaving to the dominion of the OOP model. In their
suggestedframework,aspectsandtheirweavingarerealizedusingpureobjectoriented
constructs.Thus,everyaspectorientedprogramcanbepresentedintermsofthefamil-
iarnotionsofinheritance,polymorphismanddynamicbinding.Indeed,asWalkeret.al.
conclude:“programmersmaybebetterabletounderstandanaspect-orientedprogram
whentheeffectofaspectcodehasawell-definedscope”.
Aspect Moderator relies on the PROXY design pattern [21] to create components
that can be enriched by aspects. Each core class has a proxy which manages a list of
operationstobetakenbeforeandaftereverymethodinvocation.Asaresult,joinpoints
arelimitedtomethodexecutiononly,andonlybefore()andafter()advicescan
be offered. Another notable drawback of this weaving strategy is that it is explicit, in
the sense that every advice has to be manually registeredwith the proxy. Registration
is carried out by issuing a plain Java instruction—there are no external or non-Java
elementsthatmodifytheprogram’sbehavior.Therefore,long,tiresomeanderror-prone
sequencesofregistrationinstructionsaretypicaltoAspectModeratorprograms.
2Further,Laddad[11,p.441]notesthatinAspectJtheruntimebehaviorcannotbededucedeven
byreadingallaspects,sincetheirapplicationtothemaincodeisgovernedbythecommand
bywhichthecompilerwasinvoked.
The Aspect Mediator framework, due to Cohen and Hadad [22], ameliorates the
problem by simplifying the registration process, and each of the registration instruc-
tions.Still,theirconclusionisthattheexplicitweavingcodeshouldbegeneratedbyan
automatictoolfromamoreconcisespecification.TheAspectJ2EElanguageprocessor
givesthistool,whichgeneratestheexplicitregistrationsequenceoutofanAspectJ-like
weavingspecification.
We stress that AspectJ2EE does not use any of the obtrusive weaving strategies
listedabove.TruetothespiritofAspectMediator,itemploysaweavingstrategythat
does not break the object model. Instead of modifying binaries (directly, or by pre-
processingthesourcecode),AspectJ2EEgeneratesnewclassesthatinheritfrom,rather
thanreplace,thecoreprogramclasses.Aspectapplicationiscarriedoutbysubclassing,
duringthedeploymentstage,theclassesthatcontainthebusinesslogic.
3.3 J2EEDeploymentasaWeavingProcess
Deployment is the process by which an application is installed on a J2EE application
server.Havingreceivedtheapplicationbinaries,deploymentinvolvesgenerating,com-
pilingandaddingadditionalsupportclassestotheapplication.Forexample,theserver
generatesstubandtie(skeleton)classesforallclassesthatcanberemotelyaccessed,in
amannersimilarto,orevenbasedon,theremotemethodinvocation(RMI)compiler,
rmic[23].EventhoughsomeJ2EEapplicationservers(e.g.,JBoss[16])generatesup-
portclassbinariesdirectly(withoutgoingthroughthesource),thesealwaysconformto
thestandardobjectmodel.
Figure 1 compares the developmentcycleof traditional and J2EE application. We
see in the figure that deployment is a new stage in the program development process,
whichoccursaftercompilationbutpriortoexecution.Itisuniqueinthatalthoughnew
codeisgenerated,itisnotpartofthedevelopment,butratherofuserinstallation.
(cid:17)(cid:18)(cid:19)(cid:20)(cid:1)(cid:8)(cid:21)(cid:2)(cid:3)(cid:2)(cid:6)(cid:22)(cid:8)(cid:12)(cid:11)(cid:1)(cid:6)(cid:7)(cid:1)(cid:8)(cid:9)(cid:21)(cid:4)(cid:23)(cid:4)(cid:12)(cid:6)(cid:11)(cid:9)(cid:4)(cid:22)(cid:3)(cid:24)(cid:3)(cid:4)(cid:11)(cid:24)
(cid:0)(cid:1)(cid:2)(cid:3)(cid:4) (cid:10)(cid:6)(cid:9)(cid:11)(cid:2)(cid:12)(cid:4) (cid:13)(cid:14)(cid:4)(cid:15)(cid:16)(cid:3)(cid:4)
(cid:5)(cid:1)(cid:6)(cid:7)(cid:1)(cid:8)(cid:9)
(cid:30)(cid:31) ! "#$ %&’%#" ( (cid:30))’ %&’%#" (
(cid:17)(cid:27)(cid:19)(cid:28)(cid:29)(cid:13)(cid:13)(cid:11)(cid:1)(cid:6)(cid:7)(cid:1)(cid:8)(cid:9)(cid:21)(cid:4)(cid:23)(cid:4)(cid:12)(cid:6)(cid:11)(cid:9)(cid:4)(cid:22)(cid:3)(cid:24)(cid:3)(cid:4)(cid:11)(cid:24)
(cid:0)(cid:1)(cid:2)(cid:3)(cid:4) (cid:10)(cid:6)(cid:9)(cid:11)(cid:2)(cid:12)(cid:4) (cid:25)(cid:4)(cid:11)(cid:12)(cid:6)(cid:26) (cid:13)(cid:14)(cid:4)(cid:15)(cid:16)(cid:3)(cid:4)
(cid:5)(cid:1)(cid:6)(cid:7)(cid:1)(cid:8)(cid:9)
(cid:30)(cid:31) ! "#$ %&’%#" ( (cid:30))’ %&’%#" (
Fig.1.(a)thedevelopmentstepsinatraditionalapplication,(b)thedevelopmentstepsinaJ2EE
application.
DeploymentisthemagicbywhichJ2EEservicesareweldedtoapplications.There-
fore,thegenerationofsub-andsupportclassesisgovernedbydeploymentdescriptors.
Theideabehinddeploy-timeweavingistoextendthismagic,byplacingrichAOPse-
mantics in government of this process. Naturally, this extension also complicates the
structureandinter-relationshipsbetweenthegeneratedsupportclasses.
To better understand plain deployment, consider first Figure 2, which shows the
initial hierarchy associated with an ACCOUNT CMP bean. This bean will serve as a
running example for the rest of this article. While technically, it is defined as a CMP
entity EJB, we shall see later that the use of AspectJ2EE completely blurs the lines
betweenCMPandBMPentitybeans,andbetweenentitybeansingeneralandsession
beans(bothstatefulandstateless).Thenatureofeachbeanisderivedsimplyfromthe
aspectsthatareappliedtoit.
InterfaceAccountiswrittenbythedeveloperinsupportoftheremoteinterfaceto
thebean3.Thisiswhereclient-accessiblemethodsaredeclared.
(cid:0)(cid:1)(cid:2)(cid:3)(cid:4)(cid:5)(cid:6)(cid:7)(cid:8)(cid:4)(cid:9) (cid:0)(cid:1)(cid:2)(cid:3)(cid:4)(cid:5)(cid:6)(cid:7)(cid:8)(cid:4)(cid:9) (cid:0)(cid:1)(cid:2)(cid:3)(cid:4)(cid:5)(cid:6)(cid:7)(cid:8)(cid:4)(cid:9)
(cid:10)(cid:11)(cid:12)(cid:11)(cid:13)(cid:14)(cid:15)(cid:10)(cid:16)(cid:14)(cid:17)0(cid:22)2.3(cid:15) (cid:10)(cid:11)(cid:12)(cid:11)(cid:13)(cid:14)(cid:15)(cid:10)(cid:16)(cid:14)(cid:17)(cid:18)(cid:19)(cid:20)(cid:19)(cid:21)(cid:22)(cid:15)(cid:11)(cid:18) (cid:10)(cid:11)(cid:12)(cid:11)(cid:13)(cid:14)(cid:15)(cid:10)(cid:16)(cid:14)(cid:17)0(cid:22)1(cid:16)(cid:10)(cid:15)-(cid:19)
(cid:0)(cid:1)(cid:2)(cid:3)(cid:4)(cid:5)(cid:6)(cid:7)(cid:8)(cid:4)(cid:9) ,--./(cid:18)(cid:19)(cid:22)(cid:15)(cid:11)(cid:18) (cid:0)(cid:1)(cid:2)(cid:3)(cid:4)(cid:5)(cid:6)(cid:7)(cid:8)(cid:4)(cid:9)
,--./(cid:18)(cid:19)2.3(cid:15) ,--./(cid:18)(cid:19)
(cid:23))(cid:29)!(cid:30)(cid:26)!(cid:31) *4))#5((cid:26) (cid:23)(cid:24)(cid:25)(cid:26)(cid:27)(cid:28)(cid:29)(cid:30)(cid:24)(cid:31)
(cid:23)+(cid:25)((cid:28)&67(cid:29)(cid:25)8(cid:30)(cid:29)69!6(cid:31) *4))#5((cid:26) :;(cid:1)(cid:3)<=(cid:5)(cid:7);>? (cid:23)(cid:28)!"#$(cid:25)(cid:26)(cid:31)
:=(cid:4)@AB(cid:1)(cid:3)>? (cid:23)%!(cid:26)&(cid:30)’(cid:30)()!(cid:31) *+’#(cid:30)(cid:26)
(cid:23)%!(cid:26)C(cid:28)(cid:31) *D(cid:26)(cid:29)(cid:25)(%
(cid:23)$!(cid:26)C(cid:28)(cid:31)
(cid:23)%!(cid:26)&(cid:30)’(cid:30)()!(cid:31) *+’#(cid:30)(cid:26)
(cid:23)$!(cid:26)&(cid:30)’(cid:30)()!(cid:31)
:(cid:4)EFGA(cid:7)=>?
:(cid:4)EFH(cid:3)A(cid:5)(cid:4)>?
:(cid:4)EFI(cid:5)(cid:4)(cid:7)(cid:3)(cid:4)>?
:(cid:4)EFJ(cid:8)(cid:3)(cid:1)K(cid:7)(cid:3)(cid:4)>?
:(cid:4)EFL(cid:7)BB(cid:1)K(cid:7)(cid:3)(cid:4)>?
:(cid:4)EFM(cid:4)NAK(cid:4)>?
:B(cid:4)(cid:3)O(cid:2)(cid:3)(cid:1)(cid:3)PIA(cid:2)(cid:3)(cid:4)Q(cid:3)>?
:R(cid:2)B(cid:4)(cid:3)O(cid:2)(cid:3)(cid:1)(cid:3)PIA(cid:2)(cid:3)(cid:4)Q(cid:3)>?
Fig.2.ClassescreatedbytheprogrammerfordefiningtheACCOUNTEJB.
Thedeveloper’smaineffortisincodingtheabstractclassAccountBean.Thefirst
group of methods in this class consists the implementation of business logic methods
(deposit()andwithdraw()intheexample).
Inadditiontoregularfields,anEJBhasattributes,whicharefieldsthatwillbegov-
ernedbythepersistenceserviceintheJ2EEserver.Eachattributeattrisrepresented
by abstract setter and getter methods, called setAttr() and getAttr() respec-
tively.Attributesarenotnecessarilyclientaccessible.Byexaminingthesecondgroup
ofmethodsinthisclass,weseethatACCOUNThastwoattributes:id(theprimarykey)
3Forthesakeofsimplicity,weassumethatACCOUNThasaremoteinterfaceonly,eventhough
sinceversion2.0oftheEJBspecification[2],beanscanhaveeitheralocalinterface,aremote
interface,orboth.