IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED … · 2003-11-03 · Refactoring Middleware with...

Refactoring Middleware with AspectsCharles Zhang and Hans-Arno Jacobsen, Member, IEEE

Abstract—Middleware platforms, such as Web services, J2EE, CORBA, and DCOM, have become increasingly popular during the

last decade. They have been very successful in solving distributed computing problems for a large family of application domains. The

architecture of middleware systems have gone through many significant cycles of evolution, both in terms of the completeness of

functionality and the range of adoptions for different types of platforms. However, at the same time, it is getting increasingly difficult to

achieve and to maintain a high level of adaptability and configurability because the structure of the middleware architecture is

becoming overly complicated and rigid. We attribute that problem to the limitations of traditional software decomposition methods.

Aspect-oriented programming, on the contrary, has introduced new design perspectives that permit the superimpositions of different

abstraction models on top of one another. This is a very powerful technique for separating and simplifying design concerns. In our effort

of applying principles of aspect orientation to the middleware architecture, we first pragmatically analyze the use of aspects in the

middleware architecture. We then show that aspects are the correct remedy for the above outlined middleware problems by quantifying

crosscutting concerns in the legacy implementations of several prominent middleware systems. Our aspect analysis results strongly

indicate that modularity of middleware architecture is greatly hindered by the wide existence of tangled logic. To go one step further, we

factor out a number of crosscutting concerns identified in the mining process and reimplement them with aspects, superimposed on the

existing middleware architecture. This allows us to use a set of software engineering metrics to quantify the refactorization in terms of

changes in the structural complexity, modularity, and performance of the resulting system. This aspect-oriented refactoring proves that

aspect orientation is capable of composing orthogonal design requirements. The final ”woven” system is able to correctly provide both

the fundamental functionality and the “aspectized” functionality with negligible overhead and an overall leaner architecture.

Furthermore, the ”aspectized” feature can be configured in and out during compile-time, which greatly enhances the configurability of

the architecture.

Index Terms—Aspect-oriented programming, aspects, middleware, aspect analysis, refactoring.

�

1 INTRODUCTION

IN recent years, middleware systems, such as Webservices, .NET, J2EE, and CORBA, have been widely

adopted, not only on traditional enterprise computingplatforms, but also in a very large family of emergingapplication domains, such as control platforms, smartdevices, and networking equipment. Many of these do-mains exhibit a broad spectrum of characteristics, such asspecialized runtime requirements, real-time constraints,stringent resource requirements, high availability, and highperformance.

The most prominent problem in today’s middlewaresystems is that their architecture constantly strugglesbetween generality and specialization. That is to say, onone hand, vendors want to support many applicationdomains with their middleware products that provide arelatively complete set of features. However, these systemsusually require large memory space and abundant comput-ing resources. On the other hand, architects often want tooptimize the architecture to support particular domainswith specialized runtime requirements, such as real-time,embedding, and high availability. As a result of that, for thesame technology, there often exists multiple specifications,various branches of code bases, and different implementa-tions. Each requires a tremendous amount of effort in order

to maintain the conformity of services, which middleware issupposed to provide.

Recent approaches, such as OpenCOM [1] and Dyna-micTAO [2], address these issues by introducing newsoftware engineering techniques like a component-basedarchitecture and reflection to enable adaptations of themiddleware architecture to specific platforms and deploy-ment instances. On the module level, these approaches aredesigned with conventional modularization techniques andincapable of modularizing crosscutting design concerns,which can cause a considerable amount of logic tangling inthe code.

We recognize that one of the fundamental causes of theseproblems is that middleware systems have to support manydistinct computational requirements, in addition to addres-sing distributed computing concerns. We define theseadditional computational requirements as orthogonal de-sign requirements with respect to the fundamental func-tionality of middleware systems. Traditional top-downdecomposition processes produces one decompositionmodel. That means the abstractions of orthogonal designrequirements need to be permanently imprinted into themodel at some stages of the decomposition process.Consequently, the logic of orthogonal implementations areintermingled with each other and with that of the primaryfunctionality. It is impossible, by using traditional methods,to completely decouple them from one another.

We think that the phenomenon of handling multipleorthogonal design requirements are in the category ofcrosscutting concerns, which are well addressed by aspect-oriented programming techniques (AoP). Hence, we believethat middleware architecture is one of the ideal placeswhere we can apply AoP methods to obtain a modularity

IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS, VOL. 14, NO. 11, NOVEMBER 2003 1

. The authors are with the Department of Electrical and ComputerEngineering and the Department of Computer Science, University ofToronto, 10 King’s College Road, Toronto, Ontario, Canada, M5S 3G4.E-mail: {czhang, jacobsen}@eecg.toronto.ca.

Manuscript received 8 Dec. 2002; revised 6 Aug. 2003; accepted 9 Aug. 2003.For information on obtaining reprints of this article, please send e-mail to:[email protected], and reference IEEECS Log Number 118745.

1045-9219/03/$17.00 � 2003 IEEE Published by the IEEE Computer Society

level that we cannot obtain via traditional programmingtechniques. To follow that theoretical conjecture, it isnecessary to identify and to analyze these crosscuttingphenomena in existing middleware implementations.Furthermore, by using aspect-oriented languages, weshould be able to resolve concern crosscutting and yield amiddleware architecture that is more logically coherent. It isthen possible to quantify and to closely approximate thebenefit of AoP in its applications to the middlewarearchitecture design methodology. This paper contributesto the aspect-oriented analysis and design of middlewarearchitecture in the following ways:

1. We show that middleware architectures inherentlysuffer from coordinating crosscutting concerns byperforming a quantitative aspect analysis, whichreports the degree of crosscutting of various aspectsidentified.

2. Our aspect analysis is based on an aspect miningapproach.Wedevelop anaspectminingmethodologyand a software tool to exercise this methodology.

3. Through rigorous aspect mining, we report severalnew aspects that are specific to the platforms chosen.

4. We are the first to perform aspect-oriented refactor-ization ofmiddleware platforms. AoP-based refactor-ization is a process of separating certain orthogonalfeatures out, composing them in aspectprograms, andweaving them back into the platform based on anexisting implementation.

5. We quantify the benefits of the AoP-based refactor-ization by applying a set of software engineeringmetrics to the original and the refactored implemen-tation. From this evaluation, we show that aspect-oriented technology lowers the complexity of thearchitecture, increases modularity, and preserves theoriginal design requirements, and maintains theperformance of the overall system as compared tothe original implementation.

The rest of this paper is organized as follows: Section 2constitutes a more detailed discussion of middlewareproblems. Section 3 presents a brief overview of aspect-oriented programming that will help to better understandour approach. Section 4 presents the aspect analysis results.Section 5 presents the refactorization of aspects usingAspectJ. Related approaches are discussed in Section 6.Section 7 concludes the paper and outlines future work.

2 PROBLEMS WITH TODAY’s MIDDLEWARE

ARCHITECTURES

Generally speaking, middleware systems can be defined asa set of services that facilitates the development ofdistributed applications in heterogeneous computing en-vironments. Prominent examples of middleware systemsinclude CORBA, DCOM, the Java suite of protocols, andJava RMI and, most recently, Web services. In this section,we briefly summarize a few observations in the evolution ofmiddleware, motivate the use of aspect-oriented techniquesfor designing middleware architectures, and outline thechoice of our case study platform underlying this work.

2.1 Middleware Architecture Evolution

A striking change in the evolution of middleware systems isthat, in recent years, the target platforms are not limited to

traditional enterprise systems and desktop machines. Newplatforms include mobile devices, network devices, controlsystems, safety critical systems, and many more. Thecharacteristics of these platforms differ from each other insignificant ways. These platforms are referred to as theemerging application domains of middleware. For example,middleware systems are used on the Cisco ONS 15454optical transport platform to deal with hardware customi-zations and the communications between managementsoftware and hardware drivers [3]. Middleware systemsare also adopted by the US Navy as the software bus forsubunits in the submarine combat control systems [4]. Thewidening of the application spectrum has dramaticallystretched the capability of middleware systems. However,the limitations of the traditional middleware architecturehas also been becoming increasingly eminent. Theselimitations include the following:

1. One size fits all: Many middleware implementationsare collections of many features in order to support alarge diversity of target platforms. However, inpractice, for a particular instance of deployment in aparticular domain, many of these features are notneeded all the time. Some are not needed at allduring an application’s lifetime. Current middle-ware architectures lack of methods to tailor thearchitecture at deployment time or at runtime.

2. Evolving too fast: Although the networking commu-nication model is relatively stable (consider TCP/IPstack implementation), models or abstractions inmiddleware systems rarely stay the same. That isbecause the middleware architecture needs to con-stantly accommodate new computational character-istics of target domains. For example, the objectadapter is a key component in CORBA [5] platforms.Even though the role of the object adapter has notchanged significantly since the dawn of CORBA, itsarchitecture has gone through a series of evolutionsfrom the basic object adapter to object adapterssupporting portability, interception, and multiplethreads. The evolution of middleware abstractionmodels is necessary and unavoidable. But, at thesame time, it is also essential to maintain backwardcompatibility with applications developed on top ofthe older models.

3. Same technology, multiple flavors: Another problem isthat there has been a proliferation of middlewarespecifications to accommodate different require-ments that stem from many application domains.For instance, the Object Management Group (OMG),in addition to defining CORBA standards, alsodefines the Real-Time CORBA specification in orderto address execution predictability, Fault TolerantCORBA to address high availability, High Perfor-mance CORBA to address data and computeintensive applications, and Minimum CORBA forembedded platforms. Java platform exhibits thesame syndrome by having different types of JVMsfor different platforms. The former DCOM architec-ture and the new Microsoft .NET platform isfollowing similar trends. These tendencies causechallenges to vendors, who must rearchitect thesystem differently according to a particular specifi-

2 IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS, VOL. 14, NO. 11, NOVEMBER 2003

cation, as well as to the adopters who, at the sametime, find the platform very complex to comprehendand to use.

2.2 Applying AoP to MiddlewareArchitecture Design

Zhang and Jacobsen [6] have established that one of thefundamental causes for the problems in today’s middle-ware architecture is that the software decomposition modelobtained using vertical decomposition (i.e., designs basedon functional or object oriented decomposition) is incapableof simultaneously modularizing coexisting orthogonal de-sign requirements.

Aspect-oriented programming, on the contrary, allows usto decompose software systems in different dimensions. Wecan use a vertical decomposition process to establish theprimary decomposition model of the architecture. We thenuse aspect-oriented techniques to ”horizontally” compose orto ”superimpose” the implementation for orthogonal designrequirements onto theprimarymodel,withoutmodifying theexisting architecture. We refer to that decomposition processas the horizontal decomposition. For a more detaileddiscussion, refer to Zhang and Jacobsen [6].

There are many limitations of applying a verticaldecomposition process to the design of software architec-ture, in general, and middleware architecture, in particular.The object-oriented paradigm and design patterns facilitatepowerful decomposition of software, such as levels ofabstraction and advanced modeling methods, as found inthe MDA.1 However, it is still difficult and sometimesinfeasible to apply these if the abstractions at higher levelsneed to be modified. In the middleware domain whererequirements are constantly changing, it is extremely hardto get the initial abstraction correct. Another limitation isdue to the presence of orthogonal design requirements. Twodesign requirements are orthogonal to each other if one canbe implemented without coordinating with the other, suchas in the case of the requirements for efficiency and therequirements for location transparency. Since each of theorthogonal requirements must have its own most appro-priate decomposition model, the vertical decompositionprocess, which generates one decomposition model, maynot be an optimized solution for both requirements. In fact,it generates a model with tangled logic, as indicated byGregor Kiczales et al. [7].

We think horizontal decomposition is a logical approachbased on the assumption that vertical decompositionunavoidably causes concern crosscutting in the decom-posed model. To confirm that and to further understandorthogonal design requirements in middleware systems, weneed to open up existing legacy implementations to conductquantitative analysis of the tangling phenomenon. Themethod we have employed to perform such tasks is calledaspect mining. We explain our aspect mining methodologyin the following section.

2.3 CORBA as Case Study

We have chosen CORBA implementations as case study forthe following reasons: CORBA has been addressing middle-ware concerns formore than adecade. Its architecture reflectsdistinct evolution cycles in the domain of middleware andcan be treated as an excellent case study of the traditionalfunctional decomposition approach. CORBA is an open

standard by which we are able to achieve a better under-standing of its behavior. There are many open sourceimplementations available for CORBA. All conform to thesame OMG standard. That allows us to cross-analyze ourresults. The core of the CORBA middleware is the objectrequest broker (ORB). The ORB provides a standardizedmiddleware platform to allow transparently locating objectsand to invoke methods on these objects. The distributedobjects can be specified using the interface definitionlanguage (IDL). The IDL compiler converts these definitionsto a specific language, such as C++ or Java, according to thestandardized IDL languagemapping specifications. TheORBuses the portable object adapter, the interface of which is alsostandardized, to process invocation requests. The ORB usesthe interorb protocol (IOP) as the communicationmechanismon the network to transfer information about the distributeddata and operations with other ORBs. The omg:CORBA:ORBinterface is a standardized facade [8] for providing abstrac-tions of complicated broker functionalities.

3 ASPECT-ORIENTED PROGRAMMING

Aspect-oriented programming offers an alternative para-digm for software development [7]. It aims at achieving ahigh degree of separation of concerns. Examples of aspectsinclude security, reliability, manageability, and furthernonfunctional requirements, often simply referred to as asystem’s “ilities” [9]. The existence of aspects is attributed tohandling crosscutting concerns in software developmentusing the traditional “vertical” decomposition paradigm.AOP overcomes the limitations of traditional programmingparadigms by providing language level support to mod-ularize these systematic properties as separate developmentactivities. The final system results by merging the aspectmodules and the primary functionalities together. Thisdevelopment process is commonly supported by a compo-nent language, such as Java or C, to implement the primarydecomposition of a system, an aspect language to modularizecrosscutting concerns as aspects, and the aspect weaver(also known as aspect complier) that instruments thecomponent program with aspect programs to produce thefinal system. Representative aspect languages are AspectJ2

and Hyper/J.3 In addition to conventional Java languagefeatures, AspectJ defines a set of new language constructs tomodel the aspects. A joinpoint represents an interceptionpoint in the execution flow of the component program. Forconvenience and elegance, a pointcut construct can beused to denote a collection of joinpoints. Actions can betriggered before, after, or in place of the program executionwhen a joinpoint is reached. These actions are defined usingAspectJ specific constructs before, after, and around.These constructs are called advices. An aspect module inAspectJ contains pointcuts and the associated advices.It also contains intertype declarations which are reused todeclare new members (fields, methods, and constructors) inother types.

4 QUANTIFYING ASPECTS IN MIDDLEWARE

In aspect-unaware legacy implementations, it is difficult toreason about aspects due to the code scattering problem.That is because the particular aspect is not localized at one

ZHANG AND JACOBSEN: REFACTORING MIDDLEWARE WITH ASPECTS 3

1. Model Driven Architecture, http://www.omg.org/mda.2. AspectJ, http://www.eclipse.org/aspectj.3. Hyper/J, http://www.alphaworks.ibm.com/tech/hyperj.

point in the code, but rather, distributed all over the code.However, if the scattering phenomena can be captured in away to allow observation and quantification, effectivemeans to identify aspects for particular application domainsbecome possible. From the identification and quantificationof high degrees of code scattering, we infer the existence ofaspects, however, the reverse inference is not alwayspossible. This will become obvious in the analysis below,where architecture crosscutting concerns are identified asaspects that do not give rise to high degrees of scattering.

Aspect analysis consists of the activities that aim atcapturing and analyzing the scattering phenomenon inlegacy implementations. To correctly perform aspect dis-covery, it is very important to identify the roles involved inthe logical tangling. We consider the concept of the aspectas a relative term with respect to the primary functionalityor, equivalently speaking, the primary decompositionmodel. Therefore, in order to analyze the scatteringproblems in middleware systems, we need to first of alldefine a decomposition model, which represents the mostfundamental properties of the middleware substrate. Weare then able to identify aspects by using that model as thereference point to think about tangling in terms of code andorthogonality in terms of design requirements. We refer tothis process as aspect orientation.

4.1 Primary Decomposition of aMiddleware Architecture

We think that the fundamental functionality of a middle-ware system, supporting remote invocations, mainly con-sists of the following major architectural elements:

1. a standardized programming model or API with theassociated skeletons and stubs that allows applica-tions to make abstractions of the distributed objectsor services,

2. the mechanism of publishing the representation ofan object or a service to peers,

3. the dispatching mechanism that forwards the re-quests associated with the published representationto its concrete instance, and

4. the commonly agreed representation of data andoperations on the network layer with their asso-ciated interpretation mechanisms in order to ex-change information with its remote counterparts.

To be more specific, Table 1 shows the architecturalelements that fall into the categories listed above from thepopular middleware platforms, CORBA, DCOM, Java RMI,and .NET.

Having identified the primary architecture of a middle-ware system, we now define aspects of middleware systems asconcerns which can be decomposed independently and yethave to be addressed in the lines of the primary architecture.

More specifically, middleware aspects are abstractions orimplementations that crosscut any of thesemajor architectur-al components enumerated above.

4.2 Extended Aspect Mining Tool

The aspect mining tool (AMT) [10] is designed to capturethe code scattering problem on the source code level. It wasdeveloped at the University of British Columbia and basedon the AspectJ compiler. AMT emphasizes on visualizingperspective aspects in program code and is therefore well-suited to study aspects in small software projects. AMTallows one to inspect the code scattering phenomenon byperforming type and textual analysis in building a collec-tion of all the types used in the program in combinationwith the entire source code space. We have built theextended aspect mining tool (AMTEX) [11] to overcome thelimitation of visualization-based mining and scale themining process to software systems with thousands ofclasses. The extended mining tool provides much largerflexibility in terms of composing mining activities, mana-ging mining tasks, and cross analyzing mining results. It isdesigned to fit the needs of mining very large softwaresystems that consist of thousands of classes with millions oflines of code.4

4.3 Mining Methodology

We have taken the following approaches to best utilize theanalysis capability of the extended mining tool in order toidentify aspects in middleware systems:

1. We first inspect well-known aspects that have beenpreviously identified in other software systems, suchas logging, synchronization, and others. We areinterested in finding the corresponding codingrepresentations in middleware systems and identi-fying whether these aspects are also present.

2. We then apply our understanding of the function-ality of middleware to analyze if some of the featuresin middleware systems are orthogonal to theprimary functionality. To confirm our analysis, weuse AMTEX to capture the corresponding cross-cutting structures.

3. We use the ranking feature of AMTEX to makesensible guesses. AMTEX is able to rank thepopularities of all class types used in the system.Types that are used relatively widely in the codespace are able to provide good hints of potentialaspects.


4. The reference to “mining” in AMT and in AMTEX is somewhatmisleading, since patterns are not autonomously discovered by the tool.Both tools perform an analysis, which with the user interaction may giverise to aspect discover.

TABLE 1Middleware Architecture Elements Overview

The aspect mining process is guided by a human minerwho knows or suspects the existance of aspects in the codeand guides the discovery process. The human miner beginsthis process with the initial description of the crosscuttingstructure of an aspect. This structure can be described, eitherin succinct lexical and type patterns, or gradually in severalsteps. We refer to such a description as the characterization.

As described in [10], the use of lexical and type-basedaspect mining works effectively with programs that havewell-defined naming conventions and follow a consistentcoding style. This method is appropriate for discoveringcrosscutting structures at the granularity of statementsinside method bodies. For example, code such as log ortrace and types such as Logger or Tracer are fairlyaccurate in describing the crosscutting of the aspects loggingand tracing. We use this method primarily to locate well-known aspects such as logging, tracing, synchronization,and others.

For aspects that have no statement-level crosscuttingstructures but domain-specific semantics, it is difficult tocharacterize the aspect without a good understanding of thesemantics of the program. We use a feedback-directedapproach to find a good characterization of this type ofaspects in several steps of refinements. That is, a lexicalpattern can be used to describe the miner’s intuition of whatthe crosscutting structure might be. Matching resultsdiscovered in this step serve as feedback and assist theminer to refine the characterization. We use this approachto locate middleware specific aspects such as type Any, forexample.

This is assisted by the type ranking feature of AMTEX,which allows to rank the usage popularities of all classtypes in the system. Types that are used relatively widely inthe code space provide good hints of potential aspects. Forexample, AMTEX shows that the class type Assert is themost used type in the ORBacus code. We then use this classtype and quantify the aspect of pre/postcondition checkingas further explained below.

Another type of crosscutting structure is the additionalcontrol flow incurred in the code through the coordinationwith an orthogonal concern. We can inspect the valuesinvolved in conditional branches and trace all the codeinvolved in accessing these values through assignments,method parameter passing, and accessor methods. Weessentially compute code slices based on the conditionalstatements. If these slices are not localized, we haveidentified very good candidates of crosscutting concerns.A tool can use this technique and evaluate all conditionalstatements in the system to find nonlocalized slices.Currently, we perform this technique manually by brows-ing through the source code with the help of Eclipse andFeat [12]. Our ongoing PRISM project [13] will support thisfunctionality. With this technique, we were able to findaspects such as oneway invocation, which produces a largenumber of conditional statements for deciding if a onewayinvocation is occurring or not. Later sections present detailsabout such an aspect.

4.4 Mining Results

In this section, we present the mining results for a numberof aspects in CORBA implementations, including aspectsdefined prior to this work, such as logging, synchroniza-tion, exception handling, and pre/postcondition checking.We also present aspects that are discovered through miningwith respect to the CORBA platforms. These aspects include

the dynamic programming interface and support forportable interceptors. For each aspect, we report how itcrosscuts the primary model in the following format:

1. Definition: Explains the context and the definition ofthe aspect.

2. Logic Tangling: Discusses the cause for the aspect byidentifying orthogonal design concerns.

3. Characterization: The orthogonality of design require-ments causes the scattering of their implementationson the code level. In these situations, one imple-mentation can be characterized by a few class typesor special textual expressions. This section lists typesand expressions that are used to represent thetangling logic in different implementations.

4. Mining Results: If the aspect can be characterized by aset of types and textual expressions, we can use theextended aspect mining tool to quantify the usage ofthese types and expressions. This is expressed byAMTEX as the degree of scattering of the aspect in boththeVendorCodeSpace (VCS)5andtheCompleteCodeSpace (CCS). The degree of scattering is a measure ofthe percentage of the usage of the characterization setthroughout the source code. AMTEX counts the totalnumber of classes in an application and the number ofclasses that contain any class type from the character-izationset.Theratioof these twonumbers is thedegreeof scattering. All our mining results are expressed asthis ratio.

5. Result Analysis: This section provides a brief analysisof the mining data.

6. AoP Benefit: This section explains how AoP cantheoretically help improve modularity, adaptability,and performance of middleware platforms bycomposing the feature as aspect programs.

The mining data is collected over three open sourceCORBA implementations: ORBacus, a commercial ORBfrom IONA Technologies;6 JacOrb,7 an open source ORB,commercially supported by OCI; and OpenOrb,8 a commu-nity open source project. All three implementations complywith the CORBA 2.0 specification defined by the OMG. Thesizes of these CORBA implementations, in terms of numberof classes in VCS and CCS, are listed in Table 2.

4.4.1 Dynamic Programming Model

Definition: A dynamic programming model allows anapplication to be designed without prior knowledge of theinterface definitions of the invoked objects. Instead,invocations on an interface can be composed duringruntime.


5. Classes defined and implemented by the vendor, other than thosespecified by OMG.

6. ORBacus, http://www.iona.com.7. JacOrb, http://www.jacorb.org.8. http://openorb.sourceforge.net.

TABLE 2Sizes of Code Spaces (in Number of Classes)

Characterization: In CORBA, the OMG defined objectsthat handle DSI/DII are the following classes in terms ofthe Java language mapping: org.omg.CORBA.Any, or

g.omg.CORBA.NamedValue, org.omg.CORBA.NVList,org.omg.CORBA.Request, and org.omg.CORBA.Ser

verRequest.Logic tangling: The dynamic programming model (DII/

DSI) crosscuts the ORB functionality in the following ways:

1. All Helper and holder classes9 contain operations toallow transformation and manipulation of theseserver objects in the dynamic invocation context.

2. The ORB interface supports dynamic invocations byproviding the functionality of composing operations,their parameters, and their return types.

3. The request processing classes supports dynamicinvocations through specialized request objects suchas org.omg.CORBA.Request and org.omg.COR

BA.ServerRequest, and also through extra controllogic.

4. The encoding and decoding mechanisms, whichmap the program data and operations to bit streamsaccording to the transport protocol, support thedynamic behavior by using value types such as Anyand NamedValue.

Although the list above is not complete, we haveobserved that the support for DII and DSI is incorporatedinto the static invocation model not only as a part of theprogramming interface, but also in the request processingmechanism and in the encoding/decoding process. There-fore, we refer to the dynamic invocation mechanism as anaspect of the ORB if its primary invocation model is static.Similarly, we can refer to the static invocation model as anaspect of the ORB, if its primary invocation mechanism isdynamic.10

Mining Results: The degree of scattering for thedynamic programming interface is reported in Table 3.

Result Analysis: The data presented confirms the aboveanalysis that the code handling the dynamic programmingmodel is not well modularized. More than a quarter of theclasses in all three implementations deal with DII or DSI insome way. Also, the degree of scattering of the dynamicprogramming model increases, with increasing code size.

AoP Benefit: Aspect-oriented programming can beapplied here to separate the dynamic programming modelfrom the static programming model. That is, we can writean aspect program for the static model to support thedynamic model, or vice versa. The use of AoP techniqueshas a number of advantages over the conventional ORBarchitecture. First of all, the separation of concerns liberates

the ORB architect from the effort of incorporating thedynamic model into the static model, or vice versa. Bothmodels can be better designed, modularized, and opti-mized. Second, since, in most cases, only one invocationmodel is sufficient for a particular domain application,implementing the dynamic programming interface asaspect program gives us the option of either ”weaving”the feature in or leaving it out. The ORB architecture,therefore, becomes more configurable, adaptive, and com-putational efficient.11

4.4.2 Portable Interceptors

Definition: Portable Interceptors are hooks into the ORBthrough which CORBA services can intercept various stagesduring the object request processing. Interceptors allow athird party to plug in additional ORB functionalities such astransaction support and security.

Characterization: The implementation for supportinginterceptors is characterized by the usage of the interceptorclass type.

Logic tangling: The specification for interceptors wereadded to the CORBA specification at a much later time; thatis, after the basic functionality of the ORB had been definedand implemented. The support for interceptors is incorpo-rated in the implementation of the POA and other objectsthat are directly responsible for request processing asfollows:

1. The ORB interface contains methods and datamembers to allow the registration of interceptors. Italso provides methods to allow access to theseinterceptors when it is necessary to notify them uponreaching interception points.

2. During the propagation of the request, the invoca-tion context is checked to see if it is modified byinterceptors.

3. The POA needs to bundle requests with informationof interceptors if they are registered with the ORB.

The number of objects, such as POA, is proportional tothe number of server objects in the domain applications.Therefore, an even higher degree of scattering couldhappen during runtime.

Mining Results: The degree of scattering for the portableinterceptor support is reported in Table 4.

Result Analysis: The mining results show that portableinterceptor support is a crosscutting phenomenon, mostlyin the vendor code space since the spreading in CCS ismuch lower.

AoP Benefit: Portable interceptor support is typicallyneeded to support enterprise computing features such assecurity, transaction processing, and fault tolerance.


9. As defined in [14], all user-defined IDL types should be generatedwith additional helper and holder classes to allow convenient manipulationof these types.

10. An earlier version of the popular C++ MICO CORBA implementationwas entirely based on the dynamic invocation interface.

11. The MinimumCORBA profile, for example, leaves all dynamic objectmanagement functionality out of the specification, arguing that, forresource constraint embedded applications, this functionality is notrequired.

TABLE 3Degree of Scattering for Dynamic Programming Interface

TABLE 4Degree of Scattering for Portable Interceptor Support

Implementing the support for interceptors in aspectprograms is attractive, since they can be configured outif they are not needed.

4.4.3 Type Any

Definition: We categorize type Any as part of the supportfor the dynamic programming style of CORBA. We providean independent analysis for this type because it is one of theprimitive data types of IDL and, hence, can be used beyondjust dynamic programming. For example, Any is also usedin representing generic information when querying theORB’s execution state or the interface repository.

Characterization: In CORBA, the IDL data type Any ismapped to the class org.omg.CORBA.Any in terms ofthe Java language mapping. In addition, we also includethe vendor specific implementation class for this languagemapping. The ORBacus implementation is com.ooc.

CORBA.Any, org.jacorb.orb.Any for JacORB, andorg.openorb.CORBA.Any for OpenORB.

Logic tangling: The support for the type Any crosscutsthe ORB functionality in the following ways:

1. All the helper and holder classes must support theconversions between the statically typed classes andthe type Any.

2. The ORB interface supports factory methods for userapplications to obtain the vendor specific instance ofthe type Any.

3. The encoding and decoding mechanisms, as ex-plained in Section 4.4.1.

4. The use of Any to represent generic informationabout the execution context of the ORB as part of theportable interceptor framework.

Mining Results: The degree of scattering for thedynamic programming interface is reported in Table 5.

Result Analysis: The data shows that the scattering ofthe type Any in all three implementations are consistentlyhigh. Therefore, we categorize the type Any as an aspect ofCORBA.

AoP Benefit: For applications that do not require thesupport of the IDL type Any, it is currently not possible toremove its support in conventional ORB architectures.Therefore, separately decomposing the support for Any,as a set of aspects, will lead to a simpler architecture, whilepreserving the CORBA functionality.

4.4.4 Wchars and Wstrings

Definition: Wchars are characters with an expandednumber of bytes. Every wchar has an equal number ofbytes and the number is platform dependent. CORBA useswchar to support additional sets of character encodingssuch as Unicode. A Wstring is a sequence of wchars. Wetreat wchar and wstring or, more generally speaking,primitive data types, as aspects, because each data typerepresents an independent, hence orthogonal way ofencapsulating and interpreting data in the applications.

Characterization: We use the lexical pattern “wchar”and “wstring” to locate class concern with the support forthese two data types.

Logic tangling: The implementation of wchar andwstring crosscuts the CORBA implementations as follows:

1. The initialization process of CORBA needs toinclude the loading of the encoding (i.e., Code-set)information of wchars.

2. The encoding and decoding mechanism containsspecial operations related to the reading and writingof wchars in incoming and outgoing octet streams.

3. CORBA supports multiple encoding formats forcharacters. Each encoding format also needs tosupport wchars and wstrings.

4. The error handling mechanism contains error codesand error messages related to operations with wcharand wstring.

Mining Results: The degree of scattering for the wcharand wstring support is reported in Table 6.

Result Analysis: The support of wchar and wstring

causes varying degrees of scattering. The degree ofscattering is generally low because the crosscutting mainlyinvolves operations regarding characters but not the callprocessing. However, the implementation of wchar supportis still nonlocalized.

AoP Benefit: The support for wide characters andstrings, as well as other primitive data types, is not localizedand modular. Decomposing IDL data types as aspectsrather than in a scattered fashion allows us to support userapplications with the right set of data types and reduces thecomplexity of the architecture, eventually offloading non-required types for specific resource constraint applications,for example.

4.4.5 Oneway Invocation

Definition: The oneway invocation semantic of CORBAsupports the best-effort delivery of client requests and is ofan asynchronous nature, without any return value sent backto the client. That is, the thread of control is returned to theuser application once the invocation is sent to the networklayer. We categorize the oneway invocation as an aspectbecause it has an orthogonal semantic to the synchronousinvocation, which is typically the primary communicationmechanism in CORBA.

Characterization: As previously mentioned, the charac-terization for the aspect of oneway invocations is the slicingofthe branching condition of whether the invoked interface istaggedonewayornot in its IDLdefinition. SinceAMTEXdoesnot yet evaluate this type of aspect characterization, we usethe lexical pattern “response” as an approximation. We haveverified that this approximation is fairly accurate, as all threeimplementations use the condition “response_expected”to decide if the current invocation should be treated asoneway or not.


TABLE 5Degree of Scattering for the Type Any

TABLE 6Degree of Scattering for Wchar and Wstring Support

Logic tangling: The implementation of oneway crosscutsthe ORB as follows:

1. The oneway invocation is addressed in the stub/skeleton layer to support the usage of the oneway

IDL keyword.2. Depending on whether the request is oneway or not,

the client-side takes different processing steps sothat the stub will not expect a response from theserver.

3. The server issues a reply message to the client’srequest in the case of synchronous communication.This reply is not needed if the invocation is oneway.Therefore, the server-side call dispatching processneeds the “oneway” information of the currentrequest to determine the execution path.

4. The low-level transport and protocol layer addressesthe encoding/decoding information and relatedsocket operations regarding the oneway semantic.

Mining Results: The degree of scattering for the onewaysupport is reported in Table 7.

Result Analysis: The results show that the scattering ofoneway support mainly exists in the vendor code space.Although the degree of scattering is relatively small, theruntime ramification of this aspect is high since thescattering of oneway concentrates on the path of callprocessing. Our metric does not capture this effect.

AoP Benefit: The oneway invocation is commonlyimplemented as a set of branched executions in both themarshalling and unmarshalling processes, regardless ofwhether the current invocation is oneway or not. If theapplication does not use oneway calls, these conditionalsbecome redundant, and yet, are still part of the executionpath of the synchronous invocation. This, in turn, degradesthe performance of synchronous invocations in CORBAimplementation not designed with aspects. Composingoneway as aspects will make the synchronous invocationsmore efficient without losing the support for onewayinvocations.

4.4.6 Common Aspects

In this section, we collectively treat the error handling, thepre/postcondition checking, the logging, and the synchro-nization functions. These are well-known aspects found inmost large software systems.

Definition: Error handling deals with unexpected statesof the system during execution. Sophisticated softwaresystems, such as middleware platforms, require a robust,flexible, and manageable error handling mechanism such asoffered by exception handling mechanisms found in manyprogramming languages.

Pre/postconditions are used in applications to validatethe correct state of the data either before or after the data isprocessed.

The purpose of logging is to report the running state ofthe system and to aid in collecting debugging information.

Synchronization primitives, such as mutex, semaphore,and monitors, are used to protect critical regions and thevalid state of shared resources.

Characterization: Exception-based error handling caneasily be characterized through the use of exception classesand expressions that match ”try” and ”catch” blocks.

The implementation of pre/postcondition checking isapplication specific. Typically, it can be characterized by theuse of assert-like statements.

The implementation of logging is highly applicationspecific. For example, JacOrb uses the method void

printLog(int mode, String message), and ORBacususes the following methods: info(String message) anderror(String message), warning(String message).

The use of synchronization can be characterized by thesynchronization data types such as mutexes, semaphoresand monitors. In addition, the keyword ”synchronized” inJava programs identifies this aspect.

Logic tangling: Error handling can be considered as anaspect because, although never being a design goal of anyapplication, error handling is a property that has to beincorporated in the architecture in an ad hoc manner. Moreimportantly, the error handling mechanism provided by alanguage, such as Java exceptions, can incur executionoverhead that cannot be overlooked in certain computingenvironments. That is particularly important to middlewarebecause it should be designed to fit a wide range ofplatforms. This clearly indicates that the error handlingmechanism, such as exceptions, crosscuts the design goal ofperformance optimization.

We consider the pre/postcondition checking an aspectbecause it implements the design requirements of validity.The validation checking by nature scatters throughout thedecomposition model.

Logging can be considered as an aspect because it isdesigned for ”debuggability” in sacrifice for systemperformance and maintainability of the source code.

Synchronization, as a pervasive property, is appliedwhere resource contention exists. Synchronization is a well-known aspect not only for middleware platforms, but alsofor software systems in general.

Mining Results: The degree of scattering for theanalyzed aspects is reported in Table 8. Since logging,pre/postcondition checking, and synchronization, otherthan error handling, are implementation specific, themining is conducted over the vendor code space only.

Results Analysis: The mining data indicates that thescattering degree of error handling is almost proportional tothe code size. Furthermore, the data confirms that mod-ularity is clearly violated in the implementation. Similarly,for the other functions, which are also widely scatteredthrough the code, the analysis confirms their aspectualnature.

AoP Benefit: We briefly discuss the key benefits ofmodularizing the functions discussed in this section asaspects.

1. Although Java exceptions provide a powerful me-chanism for error handling, it does come with a


TABLE 7Degree of Scattering for the Oneway Support

performance price, because not only does it increasethe code size, for the Java compiler has to generate theexception management code, but it also elongates thenormal execution path of the application because ofthe stack unwinding process. The exception mechan-ism might not be a big factor for performance in theenterprise or desktop computing environment. How-ever, in the case that the computing resources arelimited, it may be desirable not to use exceptionsupport, but to use return code-based error handling.That greatly decreases the code size and performanceoverhead. However, it is very difficult and cumber-some to allow switching between the two errorhandling schemes using traditional programmingparadigms. AoP can provide an elegant solution byallowing us to compose the source code for the basicfunctionality and the error handling functionalityseparately. For example, we can write two sets ofaspect programs, one using exceptions and the otherusing return code checking.Wecanconfigure theORBstatically or dynamically to use return code checkinginstead of exceptions if resources are constrained.12 Inaddition, anymodifications to the error handling logicwould not affect the ORB code, thus making changesless error prone.

2. The modularization of pre/postcondition checkingwith aspects offers the option of enforcing systema-tic checks and policies, which can also be easilymodified. In the case of traditional programmingtechniques, developers have to manually go throughthe entire code space to make the correspondingchanges.

3. Aspects can be applied to separate the logging codefrom the core logic of the implementation. In thatway, the state reporting capability can be preservewithout introducing any performance overhead inthe final system. The source code of the ORB can bemore concise and clean, while the logging codebecomes more modular and more reusable.

4. Synchronization assumes a concurrent executionmodel. That assumption is not always valid forcertain platforms where it is costly to use concur-rency for the limitation of computing resource andpower efficiency concerns. Aspect implementationof synchronization enables the feature to be config-ured in or out depending on the target platform.Synchronization implementation can also becomemore modularized.

4.4.7 Cross-Comparisons of Mining Results

The sections above have listed the mining results of severalindividual aspects. We have used our extended aspectmining tool to combine these individual results, which yieldstatistical information that illustrates the scattering of allthese aspects in the CORBA platform from a slightlydifferent angle. Table 9 shows, for each of the three CORBAimplementations, the number of classes in VCS that arecrosscut by at least one aspect. It also shows the number ofclasses containing three or more aspects.

These results strongly suggest that, in the investigatedplatforms, tangled logic, which gives rise to aspects, is acommon phenomenon in both implemented classes as wellas the IDL-compiler generated classes. We conclude thatvertical decomposition yields architecture models thatinherently suffer from coordinating orthogonal designrequirements. Moreover, these results almost suggest thatthe scattering of code in implementations of middlewaresystems is consistent regardless of whether the develop-ment model is cathedral or bazaar.13 However, furtherexperiments need to be carried out to more fully validatethis observation.

5 ASPECT REFACTORING MIDDLEWARE

USING AOP

Our aspect mining results have shown that aspects areinherent properties of middleware implementations. How-ever, it is still not clear how AoP techniques could improvethe architecture and result in implementations that, at least,


TABLE 8Degree of Scattering for Error Handling, Pre/Post Checking, Logging, and Synchronization Aspects

TABLE 9Combined Scattering of Aspects

12. When the MinimumCORBA specification was first discussed, theneed for costly exception support in the target domain, embedded systems,was questioned. 13. http://www.tuxedo.org/~esr/writings/cathedral-bazaar/.

preserve the design requirements. Obviously, that questioncannot be answered without quantitative comparisonsbetween two instances of implementations, one usingtraditional decomposition techniques and the other usingthe aspect-oriented approach. Our long term research goalis an aspect-centric design of a middleware platform. Here,we base our comparative evaluation on a refactored legacyimplementation. That is, if we identify a certain function-ality, which constitutes an aspect as the result of aspectmining, we should be able to separate that functionalityfrom the original implementation, compose the function-ality as an aspect, and weave it back into the architecture.All design requirements should still be satisfied transpar-ently to the user. We believe that ”refactoring” closelyresembles what happens in a completely aspect-orientedapproach. The following sections will present the set ofsoftware engineering metrics we have used in order toquantify the architectural differences. We then describe ourrefactoring approach, the detail of the aspect-orientedimplementations, and the results of the evaluations.

5.1 Quantification Metrics

Metrics are measures for the quality of software. In [15], thefollowing software metrics are used based on the staticinformation available in the implementation. These are

1. cyclomatic complexity,2. size,3. weight of the class (in number of methods),4. coupling between classes,5. DIT (depth of inheritance tree),6. number of immediate children, and7. lack of cohesion in methods.

These metrics can be applied to assess the design quality ofboth component programs as well as aspect programs ingeneral. In our analysis of the benefit of AoP as comparedwith the traditional programmingmethodology, not all of theabove metrics apply. In addition, while applying thesemetrics, our reference is the primary program (i.e., imple-mentation of the primary decomposition), with the recogni-tion that the sumof complexities of both theprimaryprogramand aspect programs might not necessarily decrease. We canmainly put the primary program under our considerationbecause aspect programs are to be configured in and out andare maintained separately. We think it is appropriate to use acombination of metrics to address various properties of theaspectized architecture, including both the static properties,which directly tie to the cost of development and main-tenance, and the runtime characteristics, which reflect thecost of adopting the technology. The following is a list ofmetrics that are used to quantify aspectization in our work.For each metric, we also provide analysis of the expectedchange due to aspectization and the rationale for the change.

1. Cyclomatic complexity: Cyclomatic complexity is ameasure of alternative execution paths in codesegments caused by control flow statements. It isan index obtained through heuristics and is inde-pendent of specific languages. The SEI defines thefollowing measures for cyclomatic complexity [16]:A cyclomatic complexity number (CCN) between 1to 10 refers to simple programs without much risk; aCCN between 11 to 20 refers to more complexprograms indicating moderate risk; and a CCN

between 21 and 50 identifies complex programs thatare highly risky. A lower CCN, that is, feweralternative execution paths, makes the programeasier to understand and to maintain. More im-portantly, it could also improve the runtime char-acteristics of the program in significant ways, suchas better cache performance and less coverage tests.AoP refactoring should lower the cyclomatic com-plexity because it takes the handling of crosscuttingproperties out from the primary decomposition.

2. Size: In [15], several methods are mentioned to assessthe size of a software system. In this paper, wedefine size as the total number of executable lines inall measured classes. The size of a software systemdirectly ties to the development and maintenancecost. AoP refactoring decreases the number ofcomments and blank lines of code, as well as thecount of executable statements of the primaryprogram.

3. Weight of a class: The weight of a class is the averagenumber of methods per class. It reflects the complex-ity of classes. AoP refactoring decreases the weightof classes.

4. Coupling between classes: Coupling is a measure ofhow much the types in the system are related to eachother. A good architecture is always less coupleddue to good modularization. AoP refactoring de-creases coupling by separating the primary programfrom the knowledge of the types, which implementthe crosscutting logic. In this paper, we measure theaverage number of classes that a class has connec-tions to in the call graph.

5. Response time: In the context of middleware, responsetime can be defined as the time taken to respond toan invocation request by the request broker. This isdefined as the total time a message traverse throughthe middleware stack during its round-trip. Wedivide that into four intervals of time as messagesare processed in the middleware stack:

a. Interval A: client-side marshalling;b. Interval B: server-side unmarshalling and dis-

patching;c. Interval C: server-side marshalling; andd. Interval D: client-side unmarshalling.

It is necessary for the aspect-oriented refactoring toat least preserve the performance measure. In thecase of having crosscutting features factored out,aspectization is expected to decrease the processingtime due to the simplification of the program logic.

6. Scattering degree: The scattering degree is measuredas, for a specific aspect, the number of classes thatcarries the characteristics of that aspect normalizedby the total number of classes in the project underinvestigation. Theoretically, the aspectization shoulddecrease the scattering factor to zero as thesecrosscutting classes or types are modularized inaspect programs.

To ease our discussion, we classify these metrics into twocategories, structural and behavioral. Structural metricsinclude cyclomatic complexity, size, weight, coupling, andthe degree of scattering. Behavioral metrics reflect theruntime characteristics of the system, such as, in our case,the response time.


The structural metrics are collected over classes that areinvolved in the refactorization. We use JavaNCSS,14 an opensourcemetric collection tool, to collect cyclomatic complexity,average class size, and weight. We use our extended aspectmining tool to collect the coupling index and the degree ofscattering. Tomeasureperformance, a simpleC-based timingtool is written based on the JavaNative Invocation interfaces.It is integrated with AspectJ programs to insert variousmeasurement points into the ORBacus execution stack. Thestack traversal intervals are measured in microseconds andcomputed as the average of 100,000 remote invocations on aPentium III 1G NT workstation. Each remote invocationinvolves an integermessage sent from the clientprocess to theserver. The server also respondswith an integermessage.Wehave carefully chosen themeasurement points to exclude thesocket operation. Therefore, the influence of the size of themessage is minimal.

5.2 The Refactoring Approach

There are a few key artifacts in an aspect-oriented system,namely, thecomponentprogram, theaspectprogram,and theaspect weaver. We use AspectJ as the aspect language for itsmaturity and its natural integration with the Java program-ming language. We pick ORBacus, the CORBA implementa-tion used previously for the aspect mining, as the componentprogram. To verify the correctness of the refactorization, weadopted the demonstration code, which is a part of thestandard ORBacus source distribution, to serve as test cases.The test programs invoke CORBA functionality withoutbeing aware of the refactorization that is performed. The testprograms are also used for performance measurements. Asthe first step of refactorization of the ORBacus implementa-tion, we need to identify the presence of the crosscuttingproperty in two forms, the implementation structure for theproperty and the crosscutting points in the primary decom-position model for that property. By using that model, thetangled code is transformed to three types of groupings ofclasses in the aspect-oriented implementation, namely,primary classes, aspect implementation classes, and theweaving classes. The transformation is illustrated in Fig. 1,where the outside box on the left depicts that the originalimplementation is one monolithic entity. The primarymodeland the aspect model coexist in a single structure with partsintersecting each other. The package diagrams on the rightpresents a cleardivisionof structures. The importance of suchdivision is that it allows all three components to be designed,tested and evolved with unprecedented independence andfreedom.

5.3 Aspect-Oriented Refactored Implementation

In this section, we present our refactored implementation ofa number of crosscutting features of ORBacus in AspectJ,including the dynamic programming interface, support forportable interceptors, collocated invocation, and logging.For each feature, we first provide the rationale of theconstruction of the package scheme, which is described inthe previous section. We use the package diagrams in Fig. 2to illustrate the hierarchical structure and the major types ofrelationship between aspect packages and the componentprogram, using the dynamic programming interface as anexample. We then present the evaluation of the metrics asthe result of factoring out that specific feature from theORBacus implementation. A detailed presentation, includ-ing code snippets and discussion of the aspects, of ourrefactoring is presented in Zhang and Jacobsen [17] which,due to space limitations, cannot be included here. At theend of this section, we will look at the overall change of themetrics after we factor out all the ”aspectized” features. Forclarity purpose, we use the term ”client” to denote a rolethat is requesting a service and the term ”server” to denotethe role for providing that service, with the observationthat, in the middleware context, the classification of clientand server is a relative one.

5.3.1 Dynamic Programming Interface

Aspect mining revealed that the dynamic programminginterface can be treated as an aspect of the CORBAimplementation, which mainly supports stub and skele-ton-based static invocation methods in its primary decom-position model. Our AoP-based refactorization of thedynamic programming interface consists of two parts, theclient side dynamic invocation interface (DII) and the serverside dynamic skeleton interface (DSI).

Dynamic invocation interface (DII):

. Aspect implementation: The client-side facility for thedynamic programming model, is supported throughthe implementations of the interface org.omg.

CORBA.Request and MultiRequestSender.These two class types are taken out of the originalimplementation and grouped under the aspectimplementation package for the DII.

. Crosscutting points: We then identify, in the primarydecomposition model, the places where operationsof classes need to acquire or to exploit the knowl-edge of these class types identified in step one.These places are the crosscutting points of the DIIaspect. In AspectJ, these crosscutting points can be


14. http://www.kclee.com/clemens/java/javancss/.

Fig. 1. Code transformation for the aspect-oriented refactorization.Fig. 2. Package organization for aspect-oriented refactorization.

implemented as “joinpoints” instead. To bemore specific, the crosscutting points of the aspectDII is summarized below in terms of how to changethe original model using AspectJ.

- Weuse the “introduction” construct to factorout a number of methods to handle multiple DIIrequests in the ORBacus implementation of theorg.omg.CORBA.ORB interface.

- The “introduction” construct is used tofactor out the downcall creation logic fordynamically composed downcalls.

- “introduction” is used to factor out the codein the object delegates [14], which createsdynamic invocation request objects.

- We group the aspect classes that containimplementations of these “joinpoints” inthe weave package.

. Evaluation: The structural metrics are collected onthe ORBacus implementation prior to AoP refactor-ing and after the DII is factored out. The responsetime is measure using both the original implementa-tion and ”woven” implementation. The data indi-cates that the structural change as the result offactoring out the DII is same as predicted andruntime performance of the aspectized DII isequivalent to that of the original implementation(see Table 10).

Dynamic skeleton interface (DSI):

. Aspect implementation: The server side facility of thedynamic programming model is supported throughthe ORBacus implementations of the interfaceServerRequest and the user specific implementa-tion of the interface DynamicImplemenation. Wefirst remove these two class types and group themunder the aspect implementation package.

. Crosscutting points: We implemented the crosscuttingpoints of the aspect DSI in the primary decomposi-tion model as follows:

- We first removed the code segments, whichdispatches client requests to a dynamic serverimplementation, from the request dispatchingcode. Then we use the ”around” construct toreplace the request dispatching call with analternative implementation, which appropri-ately handles dynamic server implementations.

- ORBacus prohibits the direct invocations for DSIserver implementations. We moved the logic ofchecking whether an invocation is toward adynamic implementation or not into the aspectimplementation. The ”before” construct isused to precede the normal invocation processin order to prevent direct invocations.

. Evaluation: For this evaluation, we used the staticinvocation interface on the client-side. The client-side processing times, interval A and interval B, aretherefore dramatically decreased as compared withthe DSI. However, that change is irrelevant to ourAoP refactorization. The data shows that factoringout the DSI has simplified the control flow anddecreased the class size. The average weight ofclasses dose not change because server-side supportfor the dynamic programming interface is muchsimpler. No additional methods are used to supportthe DSI in the original implementation (see Table 11).

5.4 Support for Portable Interceptors

. Aspect implementation: In ORBacus, the functionalityfor portable interceptors is implemented throughthree categories of classes. They include the classesrelated to implementing the interceptor interfacesdefined by the OMG. They also include the ORBacusspecific interceptor initialization classes and requestprocessing classes that support portable interceptors.We separated classes in these three categories fromORBacus, and grouped them under the aspectimplementation package.

. Crosscutting points: We implemented the crosscuttingpoints where the primary ORB model tangles withsupport for portable interceptors in AspectJ. Thesecrosscutting points correspond to the specified beha-vior of portable interceptors. That is, an ORBimplementationmust allow interceptions of the clientrequest process, of the server request process, and theof the creation process of server objects. The followingis a summary of our AoP implementations:

- The portable interceptor allows the processingof request sending to be intercepted before it iscompleted. Therefore, in ORBacus, the requestsending process, e.g., the downcall creationprocess, needs to check if any client requestinterceptors are registered. If yes, a downcallclass initialized with the portable interceptor


TABLE 10Metric Matrix for DII (for Exact Units, See Text)

TABLE 11Metric Matrix for DSI (for Exact Units, See Text)

information is created instead of a plain one.However, ORBacus performs the checking re-gardless of whether portable interceptors areused. We moved the code segments into theaspect program in an ”around” construct. Asthe result, the ”aspectized” ORBacus only per-forms necessary checks if portable interceptorsare required for a particular application.

- A similar situation occurs in the server siderequest dispatching process, e.g., the upcallcreation process. We moved the checking andupcall creation code into the aspect implementa-tion. That makes the server request processingleaner and more precise. That is, it only needs toknow and to handle portable interceptors whenit is required to do so.

- The portable object adapter (POA) plays a keyrole in the process of object creation. It needs tonotify all the interceptors if there are intercep-tors registered for intercepting object creationprocesses. Consequently, the POA code needs tohave extra control paths in order to support thatrequirement. We moved that checking logic intothe aspect code and implemented the same logicvia the “after” construct. That is, followingthe completion of object creation, the checkingcode is executed only if the support for portableinterceptors is required.

- The ORB also contains the initialization code forloading portable interceptors and registeringthem with the ORB. We moved the correspond-ing code into the aspect implementation suchthat, if interceptor support is not needed, it is nolonger necessary for the ORB to perform theextra initialization procedures.

. Evaluation: This section presents the measurementsof structural metrics and the response time. Theresponse time is measured as the time for a messageto traverse through the four intervals with andwithout the presence of the support for portableinterceptors. The data of structural metrics show thesame direction of change as in the case of thedynamic programming interface. The couplingfactor exhibits a larger drop because interceptorsupport is implemented by a larger number ofclasses. The runtime performance is equivalent tothe original implementation (see Table 12).

5.5 Invocation of Collocated ObjectsThe key abstraction provided by middleware systems is thetransparency of the location of server objects. Locationtransparency allows remote services to be invoked in thesame fashion as calling a method on an object whileperforming marshalling and unmarshalling behind thescene. Some CORBA implementations optimize the callingprocess to avoid unnecessary marshal/unmarshal work, inthe case where server objects are deployed or migrated intothe same process as the client. In ORBacus, the optimization

logic is an integral part of the request processing process,which is designed primarily for making remote invocations.We believe the optimization for in-process server objects inORBacus is logically orthogonal to its remote invocationmechanism. Therefore, we identify the optimization forlocal invocations as an aspect of the ORBacus implementa-tion of CORBA. Since we treat it as an ORBacus specificphenomenon, we omitted the corresponding aspect mininganalysis due to the lack of generality.

. Aspect implementation: In ORBacus terms, in-processobjects are referred to as collocated objects. Todistinguish between normal remote invocation callsand calls to collocated servers, ORBacus usesCollocatedClient and CollocatedServer tohandle corresponding request processing for theclient and server, respectively. We completelydecouple these class types from the ORBacus sourceand move them into the aspect package.

. Crosscutting points: In ORBacus, the collocatedinvocation is mainly implemented in the objectinitialization phase for both the client and the server.We have used AspectJ to reimplement the collocatedinvocation in aspect programs as follows:

- We use the ”after” construct to create theserver-side objects that are responsible forprocessing collocated requests, after the objectsfor servicing remote invocations are created.

- We use the ”around” construct to weave in theclient-side logic of checking whether the objectreference is pointing to a collocated server. Ifyes, a different communication model is set upto avoid marshalling and network operations.

. Evaluation: The response time is measured byrunning collocated client/server communicationson the original ORBacus and the ”aspectized” ORB(see Table 13).

5.6 Logging

. Aspect implementation: Logging in ORBacus is carriedout mainly by two class types, Logger for perform-ing the logging operations and CoreTraceLevel

for setting the levels of logging. We remove allinstances of these two class types from the ORBacusimplementation and group them under the aspectpackage.

. Crosscutting points: The crosscutting points forlogging includes the following three categories:

- Recording of the error information in exceptionhandling code.

- Tracking of the request processing.- Recording of network connection activities, such

as close of connection, decoding of data, andothers.


TABLE 12Metric Matrix of Portable Interceptor Support (for Exact Units, See Text)

We use various AspectJ constructs to implementthese crosscutting points in the aspect program.

. Evaluation: The response time is measured by usingthe client and server that are both based on the staticinvocation interface. From the measurements, it iseasy to observe that, while refactoring of loggingdecreases all structural metrics, it has a particularlyhigh impact on the size of the program. The runtimeperformance does not change significantly (seeTable 14).

5.7 Overall Assessment and Analysis

We have presented comparative results with respect to eachindividual feature that is refactored by using AspectJ. Weare also interested in the overall effect of the collectiverefactoring of ORBacus, in terms of change in its structureand the response time. In particular, we want to verify thatORBacus is able to, at least, maintain the same level ofservice in terms of handling remote object invocations. Weuse the same experiment settings as in the individualevaluations. The response time data are collected over threeORB implementation instances, the original one, the onewith all the ”aspectized” features factored out, and theimplementation with all the features ”woven” in. Thestructural metrics are collected on the set of all modifiedclasses.

The structural metrics indicate that, to implement theprimary functionality of the ORB, we have significantlylowered the complexity of the architecture via the aspect-oriented approach. The data show that the same function-ality can be implemented at least by 9 percent less code,12 methods fewer in total, and 70 instances fewer in termsof coupling with other classes.

From the observation of the response time measurementsfor the overall refactoring as well as individual ones, wedraw the conclusion that the ”aspectized” architecture isequivalent to that of the original architecture. The differenceis in a few microseconds, which is negligible for Java

applications. AspectJ implementations hardly incur any

overhead because we are simply moving the code from the

original program into the aspect program. In other words,

the original ORB is executing the them code anyway (see

Table 15).

5.8 Limitations

During our aspect-oriented refactoring of ORBacus, we

have realized some limitations in our approach due to

insufficient research in the area, overwhelming program-

ming effort and limitations in tool support.

1. We did not completely factor out class types such asAny and NVList, which are used widely for otherpurposes in addition to the dynamic programminginterface, such as for request context passing. Whilefailing to factor these types out does not prevent usfrom evaluating the aspect-oriented approach, wedefer the work until future research when it becomesnecessary to exactly quantify all aspects tied to thedynamic programming interface aspect.

2. We decided not to change the IDL-to-Java mappingportion of the implementation, since we believe theappropriate approach is to make the IDL codegenerator aware of the existence of aspects. Wedefer the discussion until future works. As aconsequence, the user code is still able to use thecorresponding OMG interfaces for a feature that ispossibly factored out. The ORB throws exceptionsduring runtime to flag these features do not exist.

3. We decided not to collect the memory usage due tothe fact that our ”aspectization” experiment isconducted on the Java platform. We do not havean accurate memory profiling tool that allows us tothe monitor memory usages of the applicationobjects. Also, the expense of running the full JVMmakes the memory improvements achieved by ourAoP refactoring almost trivial. Memory footprintwill become a more important metric for non-Java-based aspectization projects.


TABLE 13Metric Matrix of Collocated Invocations (for Exact Units, See Text)

TABLE 14Metric Matrix for Logging (for Exact Units, See Text)

TABLE 15Metric Matrix for Overall Evaluation (for Exact Units, See Text)

6 RELATED WORK

Although we do not have knowledge of any researchproject that is directly related to applying aspect-orientedprogramming to improve the internal architecture ofmiddleware to achieve customization, there are numerousprojects that are looking into using AoP to improve themodularity of software systems in general.

Putrycz and Bernard [18] present an aspect-orientedapproach to add load balancing functionality to ORBacususing AspectJ. Load balancing code is written in aspectprograms to detect server replicas and to redirect requestsfrom the clients to the replicas. Similar functionality is alsoadded to naming servers where repeated naming servicerequests are intercepted and distributed among replicas.

A conceptual analysis of using aspect is presented byKienzle and Guerraoui [19], who investigate the aspectiza-tion of concurrency and failure in distributed systems. Theiranalysis indicates that these two properties do lendthemselves well for an approach supported by aspects. Inour approach, we do not address these two properties, so acomparison is not possible.

Atlas [20] provides one of the earliest case studies ofapplying aspect-oriented programming as a general archi-tecture approach for building a Web-based learning envir-onment. Atlas uses aspects to support different architecturalconfigurations to implement design patterns and to help thedevelopment process by writing modular tracing code. Italso presents a notation system for aspects and a set of stylerules in designing aspect-oriented systems.

In the middleware field, there are a number of newapproaches to improve configurability and adaptability ofthe middleware platform. Astley et al. [21] achievesmiddleware customization through techniques based onseparation of communication styles from protocols and aframework for protocol composition. Further aspects thatcrosscut the system implementation are not explicitlyaddressed. Several projects exploit reflective programmingtechniques to allow the middleware platform to adapt itselfto changing runtime conditions. This includes projects suchas openCOM [1], openCORBA [22], and dynamicTAO [2].

Jacobsen and Kramer [23] have developed designpatterns to extend middleware platforms with at theinterface exposed concerns. This inspired the discussionby Jacobsen [24], [25] who outlined the use of nontraditionalprogramming paradigms for middleware system design.

7 CONCLUSION

We believe that adaptability and configurability areessential characteristics of middleware substrates. Thesetwo qualities require a very high level of modularity inmiddleware architecture. Traditional software architecturalapproaches, which we refer to as “vertical decomposition,”exhibit serious limitations in preserving the modularity ofdecomposition models for multiple orthogonal designrequirements. Those limitations correspond to the scatter-ing phenomena in the code. The aspect-oriented program-ming approach has brought new perspectives to softwaredecomposition techniques. The concept of an aspect allowsus to compose, with respect to the primary decompositionmodel, the modular solution for each orthogonal designrequirement. Although it is conceptually intuitive that AOPis beneficial to solving the problems of middlewarearchitecture, we still need to apply quantitative analysis to

justify our motivation. We perform aspect mining overseveral legacy implementations of middleware systems. Wediscover that the scattering of tangled logic is indeed verycommon as more than 50 percent of classes handlecrosscutting logic of some sort. Therefore, if aspect-orientedprogramming can be successfully applied to modularize thescattered code, the structural complexity of middlewaresystem architecture can be simplified tremendously. As anempirical study, we use AspectJ to refactor a number ofaspects identified through the mining process. The im-plementations, which exist in multiple places of the originalcode, are grouped within a few aspect units. The successfulrefactorization shows that middleware systems are able toprovide the fundamental services regardless of whethercertain pervasive features are factored out or factored in.Aspect-oriented refactorization has shown its superb cap-ability of loading and unloading pervasive features of thesystem, which is not possible in legacy implementations.The “woven” system transparently supports these refac-tored features. The runtime performance is equivalent tothe original implementation.

In the light of our experimentation, we are veryoptimistic that aspect-oriented programming will showmore promises in conquering the complexity of middlewarearchitectures. It will promote the adaptability and theconfigurability of middleware systems to an unprecedentedlevel to satisfy a broader range of computing needs. Infuture work, we will aim at developing more experience interms of applying aspect-oriented development methodol-ogies to this problem context. We are exploring varioustechniques to help us define horizontal decompositionprocedures more concretely. This experience will be usedtoward designing a completely new aspect-oriented mid-dleware platform.

REFERENCES

[1] M. Clarke, G.S. Blair, G. Coulson1, and N. Parlavantzas, “AnEfficient Component Model for the Construction of AdaptiveMiddleware,” Proc. IFIP/ACM Int’l Conf. Distributed SystemsPlatforms, Nov. 2001.

[2] F. Kon, M. Roman, P. Liu, J. Mao, T. Yamane, L. ClaudioMagalhaes, and R.H. Campell, “Monitoring, Security, andDynamic Configuration with the Dynamictao Reflective Orb,”Proc. IFIP/ACM Int’l Conf. Distributed Systems Platforms and OpenDistributed Processing, 2000.

[3] Cisco Systems, Cisco ons 15327—Sonet Multiservice Platform,http://www.cisco.com/univercd/cc/td/doc/pcat/15327.htm,2003.

[4] L. DiPalma and R. Kelly, “Applying CORBA in a ContemporaryEmbedded Military Combat System,” Proc. OMG’s Second Work-shop Real-Time and Embedded Distributed Object Computing, June2001.

[5] “The Common Object Request Broker: Architecture and Specifica-tion,” Object Management Group, www.omg.org, Dec. 2001.

[6] C. Zhang and H.-A. Jacobsen, “Aspectizing Middleware Plat-forms,” technical report, Univ. of Tortonto, Computer SystemsResearch Group, CSRG-466, Jan. 2003.

[7] G. Kiczales, “Aspect Oriented Programming,” ACM ComputingSurveys (CSUR), vol. 28, no. 4, 1996.

[8] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns.Addison-Wesley,first ed., Oct. 1994.

[9] R.E. Filman, “Achieving Ilities,” Proc. Workshop CompositionalSoftware Architectures, Jan. 1998.

[10] J.Hannemann, “TheAspectMiningTool,” http://www.cs.ubc.ca/~jan/amt/, 2003.

[11] C. Zhang, G. Dapeng, and H.-A. Jacobsen, “Extended AspectMining Tool,” http://www.eecg.utoronto.ca/~czhang/amtex,Aug. 2002.


[12] M. Robillard, “Feat: A Tool for Locating, Describing, andAnalyzing Concerns in Source Code,” Eclipse Technology eXchange(ETX), Proc. Int’l Conf. Software Eng., http://www.cas.ibm.ca/conferences/etx/, May 2003.

[13] C. Zhang and H.-A. Jacobsen, “Modularity Analyzer and AspectExtractor,” Eclipse Technology eXchange (ETX), Proc. Int’l Conf.Software Eng., http://www.cas.ibm.ca/conferences/etx/, May2003.

[14] “IDL to Java Language Mapping Specification,”The ObjectManagement Group, www.omg.org, 2003.

[15] L.H. Rosenberg, “Metrics for Object Oriented Environments,”Proc. Third Ann. EFAITP/AIE Software Metrics Conf., Dec. 1997.

[16] “Cyclomatic Complexity,” Carnegie Mellon Univ., http://www.sei.cmu.edu/str/descriptions/cyclomatic.html, Sept. 2000.

[17] C. Zhang and H.-A. Jacobsen, “Re-Factoring Middleware Systems:A Case Study,” technical report, Univ. of Tortonto, ComputerSystems Research Group, CSRG-466, Jan. 2003. Also to appear inProc. Int’l Symp. Distributed Objects and Applications, Nov. 2003.

[18] E. Putrycz and G. Bernard, “Using Aspect Oriented Programmingto Build a Portable Load Balancing Service,” Proc. Int’l Conf.Distributed Computing Systems (ICDCS) Workshops, pp. 473-480,2002.

[19] J. Kienzle and R. Guerraoui, “AoP—Does it Make Sense? The Caseof Concurrency and Failures,” Proc. 16th European Conf. ObjectOriented Programming, pp. 37-54, 2002.

[20] M. Kersten and G.C. Murphy, “Atlas: A Case Study in Building aWeb-Based Learning Environment Using Aspect-Oriented Pro-gramming,” Proc. ACM Conf. Object-Oriented Programming, Sys-tems, Languages, and Applications, pp. 340-352, 1999.

[21] M. Astley, D.C. Sturman, and G. Agha, “Customizable Middle-ware for Modular Software,” ACM Comm., May 2001.

[22] T. Ledoux, “OpenCorba: A Reflective Open Broker,” LectureNotes in Computer Science, vol. 1616, pp. 197-215, 1999.

[23] H.-A. Jacobsen and B. Kramer, “Design Patterns for Synchroniza-tion Adaptors of CORBA Objects,” special issue of L’OBJETJ. Object Orientation and Formal Methods, Hermes Publisher, 2000.

[24] H.-A. Jacobsen, “Middleware Architecture Design Based onAspects, the Open Implementation Metaphor and Modularity,”Proc. Workshop Aspect-Oriented Programming and Separation ofConcerns, Aug. 2001.

[25] H.-A. Jacobsen, “Re-Thinking Middleware Architecture Design,”Proc. Sixth Biennial World Conf. Integrated Design & ProcessTechnology IDPT, June 2002.

Charles Zhang is a graduate student in theMiddleware Systems Research Group in theDepartment of Electrical and Computer Engi-neering at the University of Toronto. His researchinterests mainly focus on rearchitecting middle-ware systems via an effective combination oftraditional software decomposition methods andthe emerging aspect-oriented programmingparadigm. To support such research goals, hisresearch activities mainly include structural

analysis of languages, aspect-oriented language design, aspect mining,and aspect refactoring of middleware systems.

Hans-Arno Jacobsen holds a faculty positionwith the Department of Electrical and ComputerEngineering and the Department of ComputerScience at the University of Toronto. Hisprincipal areas of research include middlewaresystems, distributed systems, and data manage-ment. He is a member of the IEEE, the IEEEComputer Society, and the IEEE Communica-tion Society.

. For more information on this or any other computing topic,please visit our Digital Library at http://computer.org/publications/dlib.


Date post:	20-Jun-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED … · 2003-11-03 · Refactoring Middleware with...

Documents