Towards Just-in-time Middleware Architectures ∗

Charles Zhang, Dapeng Gao and Hans-Arno JacobsenDepartment of Electrical and Computer Engineering

and Department of Computer ScienceUniversity of Toronto

{czhang,gilbert,jacobsen}@eecg.toronto.edu

ABSTRACTMiddleware becomes increasingly important in building dis-tributed applications. Today, conventional middleware sys-tems are designed, implemented, and packaged prior to theirapplications. We argue that with this middleware construc-tion paradigm it is often difficult to meet the challengesimposed by application specific customization requirements.We propose to reverse this paradigm by automatically syn-thesizing middleware structures as the result of reasoningabout the distribution needs of the user application of mid-dleware. We term this type of post-postulated middlewareJust-in-time middleware (JiM). In this paper, we present ourinitial design and present an evaluation of the JiM paradigmthrough Abacus, a CORBA middleware implementation basedon the aspect oriented refactoring of an industrial strengthobject request broker. In addition, we present Arachne, theAbacus synthesizer, which integrates source analysis, fea-ture inference, and implementation synthesis. Our evalua-tions show that, through automatic synthesis alone, Abacusis able to support diversified application domains with veryflexible architectural compositions and versatile resource re-quirements as compared to conventional pre-postulated ap-proaches.

KeywordsAspect Oriented Middleware, Middleware Architecture

1. INTRODUCTIONThe purpose of middleware such as CORBA1, .NET Re-

moting2, and Web Services3 is to provide uniform and native

∗Accepted at AOSD051Common Object Request Broker Architecture. URL: www.omg.org2Microsoft .NET Remoting. URL: http://msdn.microsoft.com/library/en-us/dndotnet/html/hawkremoting.asp3W3C Web Services Activity URL: http://www.w3.org/2002/ws/

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.Copyright 200X ACM X-XXXXX-XX-X/XX/XX ... $5.00.

representations of remote services for distributed applica-tions to avoid dealing with the high degree of heterogeneityin hardware platforms, operating systems, communicationprotocols, programming languages, application semantics,and many others. Traditional middleware architectures areoften criticized as monolithic or coarse-grained. This highdegree of inflexibility has called for newer paradigms to buildversatile middleware architectures which aptly adapt to everchanging external execution environments as well as require-ments of features desired by the user applications of middle-ware.

Many new architectural paradigms have been proposed,successfully exploiting techniques such as reflection [2, 4,11], component frameworks [10], and aspects [14, 8]. Acommon characteristic of these solutions, as well as tradi-tional approaches, is that middleware functionality is inde-pendently conceived and packaged as either active servicesor framework libraries according to which applications aredeveloped. We term these middleware architectures pre-postulated architectures with respect to the application de-velopment time. The pre-postulated solutions have the fol-lowing limitations:

1.Impedance mismatch – Existing middleware architec-tures are typically designed according to specific and yetcoarse classifications of application domains such as enter-prise platforms, resource-constrained environments, safty-critical systems, and many others. However, user applica-tions might not be appropriately categorized in the sameway. Consequently, pre-postulated architectures might beeither functionally redundant (overfit), or insufficient (un-derfit), or incomplete (partial fit). Generally speaking, pre-postulation is infeasible in providing a tailored architecturefor a specific user application.

2.Application obliviousness – Pre-postulated architec-tures cannot take full advantage of the rich information em-bodied in user applications regarding their required middle-ware features such as data types, invocations styles, pro-gramming styles, and additional middleware services. It isvery difficult to pre-design a customizable and adaptive sys-tem which takes the full diversity of user applications intoconsideration.

3.Domain limitations – Pre-postulated middleware so-lutions typically target specific application domains and areoften problematic in supporting applications in other do-mains. This is because a large number of extrinsic, i.e.,domain-specific, properties are implemented in a non-modularand convoluted fashion4. More importantly, it is difficult to

4Please see section 2 for the definition of convolution

pre-postutate all of the variations of the deployment environ-ments in each and every user application scenario. There-fore, conventional middleware conceived for one applicationdomain typically cannot readily support a different domainwithout considerable re-implementations.

4.Excessive configurability – Middleware composed offine granularity have greatly alleviated the difficulty of cus-tomization. However, in pre-postulation approaches, soft-ware configuration is independent of the middleware ar-chitecture and left either minimal in terms of application-specific tailoring or primarily as the user’s responsibility.Configurability can be a daunting task because the numberof configuration possibilities grows exponentially as severalauthors have shown in [17, 8].

To solve the afore-mentioned problems, we call for a para-digm shift in the construction of middleware. We proposea reverse design paradigm in which the constituents of mid-dleware implementations are not pre-postulated for user ap-plications but post-postulated from the knowledge embed-ded in the user application or the specific target applicationdomain. Borrowing metaphorically from the terminologyJust-in-time (JIT) compilation in the Java world where themachine-specific code is generated only during runtime, weterm the paradigm Just-in-time Middleware (JiM), wherethe executable middleware is only generated at the most ap-propriate time. Intuitively, the “appropriateness” gets bet-ter as the time gets closer to the runtime of the application.Currently, we are primarily concerned with the developmenttime and defer “later times” till further research.

The JiM approach is based on the observation that indi-vidual user applications or application domains often do notrequire all of the middleware features available in standardplatforms. This feature redundancy in the final middlewaredeployed can best be avoided if the distributed computingintent of the user application can be externalized and ex-ploited to drive the composition of the middleware. In JiM,we propose the following general stages to achieve this goal:gathering functional requirements from both the user appli-cation and environmental constraints (Acquisition), reason-ing about the final composition of middleware (Targeting),and generating the correct middleware as well as the asso-ciated test cases (Synthesis). The most important premiseof enabling this process is a very high degree of modularityand configuration granularity. Traditional middleware ar-chitectures, as limited by their hierarchical structures, sufferfrom the incapability of modularizing crosscutting concerns.This often hinders the separation and the modularization ofgeneric middleware logic in face of domain specific proper-ties as pointed out by Harrison and Ossher [7]. Hence, webelieve that aspect oriented programming [9] is one of theenabling technologies for achieving JiM architectures. Fur-ther, the horizontal decomposition principles [17] serve aseffective guidance for implementing JiM, as our experiencehas shown.

In this paper, we make the following contributions:1. We present the key ingredients of the JiM paradigm:

acquisition, targeting, including both inference and verifica-tion, and synthesis. More specifically, we propose a featureacquisition process bootstrapped by both remote interfacedeclarations and the user application program source. Thisprocess is directed by rule-based dependency and constraintspecifications. We propose a code naming schema to orga-nize the code space of aspects in order to facilitate fast and

correct synthesis of middleware implementations.2. We present Abacus, our prototype of JiM based on

the aspect oriented refactoring of ORBacus5, an industrialstrength CORBA implementation, Abacus is capable of au-tomatically synthesizing specific middleware implementationsto manage distribution concerns for applications in differentexecution environments from embedded to desktop and toenterprise platforms. This synthesis process is facilitated byour aspect-aware IDL compiler and the Arachne synthesizer.We also describe an inference algorithm and motivate theguarantees the algorithm provides for the final middlewarecomposition – correctness and minimalism.

3. We present a thorough evaluation of Abacus throughboth randomized feature selections and an experimental cross-domain application: an ubiquitous messenger. We measureand report both the static and the dynamic versatility exhib-ited by Abacus in transforming itself to dramatically differ-ent execution environments including cell-phones, desktopmachines and enterprise computing settings.

The organization of the paper is as follows: Section 2briefly introduce middleware and the horizontal decompo-sition (HD) principles. Although the focus of this paper ison customization, we use the HD principles to enable thearchitectural flexibility required by JiM. In Section 3, wepresent an abstract discussion of key ingredients for achiev-ing a JiM architecture. In Section 4, we present Abacus, aJiM implementation. The evaluation of Abacus is presentedin Section 5.

2. BACKGROUNDMiddleware: We define middleware as a set of services

that facilitate the development and the deployment of dis-tributed systems in a heterogeneous networking environ-ment. In the context of this paper, we further narrow thisdefinition to be the software substrate which enables trans-parent remote invocations of services. The design require-ments for middleware are still very complex because theycover two orthogonal middleware characteristics, identitycoupling and temporal coupling,among applications request-ing services (clients) and ones providing computing services(servers). Identity coupling characterizes how much clientsand servers know about each other, and temporal couplingcharacterizes the degree of synchrony of the message ex-change between them. Traditional RPC-based middleware,such as DCOM, CORBA, and Java RMI, exhibits strongidentity and temporal coupling. Clients and servers of pub-lish/subscribe middleware, on the other hand, do not knowabout each others’ identities and do not synchronize whencommunicating either.

Horizontal decomposition: Horizontal decomposition(HD) is a set of principles we have proposed in [17] to guidethe aspect oriented design and implementation of complexsystems such as middleware. HD principles play the funda-mental role in achieving a very high degree of modularityand enabling the JiM paradigm because they effectively ad-dress the feature convolution problem prevalent in legacymiddleware architectures. We use “convolution” to denotelarge-scale N-by-N interactions among orthogonal featuresin vertical architectures, those built using hierarchical mod-ules [6]. We perceive that the implementation of an aspect

5ORBacus. URL:http://www.orbacus.com/support/newsite/index.jsp

consists of both its functional implementation and its pos-sible interactions with every other aspect. HD promotesa two dimensional architecture in which the vertical archi-tecture implements a minimum set of essential functional-ity of the application, and the horizontal architecture cap-tures crosscutting concerns including both functional andnon-functional features [13]. The horizontal features are de-coupled from each other and each can be independently “wo-ven” into the vertical architecture. We term this fashion ofarchitecture “super-impositional architecture” [17].

3. JUST-IN-TIME CUSTOMIZATION“The program is obsolete by the time it is done” [3]. Tar-

geting a very diversified application domain, the design ofmiddleware becomes obsolete even faster. We think that oneway of overcoming this “curse” is to postpone at least part,if not all, of the composition of middleware, or software ingeneral, as close to its execution time as possible. We thinkthis is possible because, with the help of higher-degree mod-ularization techniques, it is possible to separate the mini-mum common functionality of middleware implementationsacross different domains and to construct extrinsic proper-ties as modules. These modules are constructed in a dis-ciplined way so that they can be combined with minimumconstraints. The core-based super-impositional architectureadvocated with the horizontal decomposition principles isone way of achieving this goal.

The spirit of Just-in-time customization is to let the dis-tribution intentions of the user applications drive the finalcomposition of middleware. This is contrary to traditionalconstruction methods in which the design and the imple-mentation of middleware are conducted prior to that of theapplication. With certain assumptions, our current researcheffort in JiM focuses on facilitating the composition of mid-dleware after the user application is developed. The follow-ing sections discuss essential JiM concepts as well as ourgeneral assumptions. We purposely present the discussionin an abstract manner rather than in implementational de-tails. In Section 4, we incarnate these concepts through ourconcrete implementation which serve as examples for theabstract discussion.

3.1 General assumptionsThe complete realization and evaluation of JiM is a com-

plex task. However, we are able to test the viability of thisapproach under the following assumptions:

1. The JiM paradigm is based on the existence of a min-imum set of functionalities and their associated structureswhich can be factored out from domain-specific variations.We term this set of middleware functionalities “the middle-ware core” and use it as the basis of just-in-time customiza-tion.

2. We limit our discussion to the remote-procedure-callbased middleware. The support of the full spectrum of mid-dleware types and properties through JiM is an interestingand future research endeavor.

3. The JiM paradigm is most effective when the middle-ware is parasitical, i.e., part of the user application stackthat responsible for managing distributed concerns. Theparadigm can also be used in providing specialized activedistributed services tailored for specific applications or do-mains. We defer to future research the discussion of theproperties of JiM in the case of generic active distributed

Explicit Acquisition

Functional Inference

Verification

Application

sources

User

preferences

Initial Manifest

Inferred Manifest

Synthesis

Adjustment

Suggestions

Final Manifest

Middleware

Implementation

Feature

Dependency

Rules

Composition

Constraints

Convolution

Descriptions

Figure 1: JiM customization stages

services. To these services, the distribution needs of individ-ual user applications generally are not sufficient in decidingthe included functionalities of middleware.

3.2 OverviewJust-in-time customization consists of four high-level stages

as illustrated in Figure 1. The process is bootstrapped bythe explicit acquisition of middleware functionalities througheither the analysis of the application source or explicit pref-erence indication by the user. A tool should be provided tofacilitate this process through the use of mappings betweenconfiguration options and elements of user programs. Theinitial manifest of middleware features gathered from thisstage is then further analyzed in the Functional Inferencestage. The inference algorithms autonomously adjust themanifest in compliance with feature dependency rules. The“inferred manifest” is then validated according to externalconstraints in the Verification stage. The violations of ei-ther dependency rules or constraints re-initiate the ExplicitAcquisition stage where users can adjust the desired featureset according to the violation information. The finalizedmanifest is passed to the Synthesis stage where the tailoredmiddleware is synthesized according to convolution descrip-tions and a well-defined coding naming schema. These de-scriptions and the schema enable the selection of the rightcomponents of a particular feature implementation if thisfeature interacts with unselected features.

3.3 Dependencies, constraints, and convolu-tion descriptions

In JiM, three types of specifications are defined in addi-tion to the middleware implementation: feature dependen-cies, composition constraints, and convolution descriptions.A feature dependency rule states that the implementationof certain functionality is composed from other functional-ities. These dependencies must be satisfied by adding theconstituent functionalities if a composite functionality is in-cluded in the manifest. For example, selecting the mid-dleware data type String would result in both String andchar being included in the feature manifest if the implemen-tation of String is based on that of the char. Dependency

rules can be either automatically derived from feature im-plementations or manually specified to express logical rela-tionships among features. Composition constraints are alsodependencies that dictate the inclusions and exclusions offunctionalities reflecting certain external conditions. Differ-ent from functional dependencies which are propositional,constraints are predicates on conditions independent of mid-dleware itself. For example, targeting a cellphone applica-tion on J2ME6 platforms requires the omission of certainfunctionalities due to the lack of support in J2ME virtualmachines. This omission can be specified as a constraintto validate a manifest generated for cellphone applications.Convolution descriptions are also propositions describing theinteractions among features. Convolutional descriptions aredifferent from functional dependencies as the latter pertainsto the implementations of functionalities and the former totheir interactions. Convolutional descriptions are used atthe synthesis stage to guarantee that the right interactioncode is selected. This mechanism is explained in detail inSection 3.5.

3.4 Functionality acquisitionThe goal of functional acquisition is to obtain a tailored

and minimum set of middleware functionalities as desired bythe user application. The process is divided into two stages:direct collection of functionalities (explicit acquisition) andthe adjustment according to functional dependencies (infer-ence).

3.4.1 Explicit acquisitionThere are two basic forms of explicit acquisition: auto-

matic feature extraction and user preference indication. Au-tomatic feature extraction is to examine the program sourceand to detect middleware functionalities user applicationsintend to use. This intent can be discovered most explicitlyin service declaration descriptions expressed in well-definedlanguages such as the interface definition language (IDL) inthe CORBA and DCOM world, remote interfaces of the JavaRMI mechanism, as well as the web service description lan-guage (WSDL) of Web Services. The language elements ofIDL, for instance, embody a rich set of middleware function-alities including data types, synchrony/asynchrony of mes-sage passing, invocations styles, and many others. Remoteservice descriptions can serve as the initial recipe for deter-mining the final ingredients of the synthesized middleware.In many cases, service descriptions alone are not sufficient todetermine all the necessary functionalities because some arepresent, not as language elements, but as libraries or exten-sion points for controlling the behaviour of middleware itself.One example is the interceptor infrastructure in CORBA im-plementations. The use of these types of functionalities canonly be detected by analyzing the application source code.Another type of explicit acquisition is to allow the user toselect additional features in foreseeing their future uses. Atool can be provided to facilitate both compiler-based anduser-driven acquisition.

3.4.2 Rule-based inferenceThe functionality manifest established through the ex-

plicit acquisition typically will not be the final manifest usedin synthesis. An inference process is needed to reason about

6Java Micro Edition. URL: http://java.sun.com/j2me

functional dependency rules and to possibly include addi-tional functionalities. This process must provide two guar-antees regarding the inferred manifest:

1. Each functionality in the manifest must have its func-tionality dependency satisfied.

2. The inferred manifest must be a minimum superset ofthe explicit manifest.

The second garantee is critical to the JiM paradigm andalso difficult to implement because the term “minimum” canbe interpreted differently in different contexts. An appro-priate cost model can be employed by inferrence algorithmsto rank all possible supersets. The cost functions in themodel can reflect the weights of many properties regardinga particular functionality such as its physical size, memoryrequirements, energy consumptions, level of preference, andothers. The definition of the cost function can either beuser-defined or provided by the middleware vendor. We willdescribe such an algorithm and the associated cost functionin Section 4.2.

3.4.3 VerificationDuring the verification stage, the inferred manifest is checked

against composition constraints. Though logically separatefrom the functionality acquisition mechanism, verification isfrequently invoked in the inference stage to validate the in-ferred manifests. Violations of composition constraints caneither be used to prune choices of feature supersets or to re-initiate the acquisition process with the information aboutoffending functionalities and violated constraints. This re-quires different indications of user preferences or modifica-tions of the application in the worst case.

3.5 Target synthesisDuring the target synthesis stage, the tailored middleware

is composed in strict accordance with the final manifest gen-erated at the inference stage. Due to the convolution phe-nomena, it is often not correct to naively select the entirefunctionality. Instead, we need to select its relevant com-ponents in the context of a specific final manifest. Thispartial selection could be different from synthesis instanceto another. To tackle this difficulty, we propose to use astructural schema to organize the code space of middlewarefeatures. The convolution descriptions guide the feature se-lection process. We discuss these concepts abstractly in thefollowing sections and provide our specific implementationsin Section 4.2.

3.5.1 Structural schemaThe primary purpose of the structural schema is to make

the code space of middleware features comprehensive to thesynthesizer. The traditional structure of the code spaceis based on name spaces (or packages in Java terms) and,therefore, suited for the vertical dimension. Features mod-ularized as aspects are non-hierarchical and convolutional.Therefore, the structural schema for JiM must make thefollowing properties explicit for each aspect: the differentia-tion between implementation and interaction, and the set ofbinary relationships with other aspects. The former is nec-essary because, if the feature is selected, the implementationof aspects is included completely, but the interaction logicmight subject to partial selection. The explicit binary rela-tionships in the schema allow the synthesizer to select thecorrect parts of an aspect according to what other aspects

it interacts with as specified in the convolution descriptions.Instantiations of the schema elements, i.e., implementation,interaction, and binary relationship, can be either sourcefiles or bytecode representations7.

3.5.2 Implementation selectionThe implementation selection is the primary role of the

JiM synthesizer which, according to the final manifest, de-termines and includes the correct constituents of a featureimplementation in the final middleware implementation. Theoutput of the synthesizer can either be a build configurationor an executable middleware instance. Utilizing the struc-tural schema and the convolution descriptions, the mecha-nism of the synthesizer can be straightforward: if a featureis present in the manifest, the synthesizer firstly includes itsimplementation then its individual binary relationship withother features if they are also activated, by walking the codespace according to the schema.

3.6 Functional verificationThe functional correctness of middleware is typically ver-

ified through integration tests in which individual tests areprovided for all the packaged functionalities. In the JiM ap-proach, such integration tests are difficult to devise since thefunctional ingredients of the final middleware implementa-tion change from case to case. However, we can take advan-tage of the high degree of orthogonality among the seman-tics of horizontal features and design test cases only for theseindividual features. It is then the synthesizer’s job to auto-matically assemble the composite test plan from individualtests for the final middleware implementation. Functionalverification is a separate logical step in completing the JiMprocess. It can be integrated as part of the synthesizer ifwe incorporate the source code of test cases into the struc-tural schema described previously. We present such a testingframework based on JUNIT 8 and AspectJ in Section 4.2

4. JUST-IN-TIME MIDDLEWARE:THE ABACUS IMPLEMENTATION

In this section, we present the Abacus, the aspect-orientedORBacus, as the prototype implementation of JiM to val-idate key JiM concepts that serve as the basis of our eval-uation. Abacus is based on our long term aspect orientedrefactoring of ORBacus, an open source industrial strengthCORBA implementation. We have re-structured more than65% of the original implementation and re-modularized themas aspects. In addition, we have substantially extended ouraspect-aware IDL compiler [15] and built Arachne, the Aba-cus synthesizer. The following sections first give an overviewof the characteristics of the Abacus architecture. The imple-mentation of JiM concepts is then discussed in detail.

4.1 Architectural highlightsThe architecture of Abacus is based on a very high level

of configurability along two dimensions: the vertical dimen-sion by preserving the original hierarchical configurability,and the horizontal dimension by modularizing crosscutting

7We think it can also be linkable executables. However, thecurrent AOP compilers only support weaving either sourcecode or byte code.8JUnit. URL: http://www.junit.org

concerns. This high degree of configurability is the founda-tion of Just-in-time customization.

4.1.1 Enhancements of vertical configurabilityThe vertical configurability, i.e., changing parts of the hi-

erarchical structure, is well designed in the original ORBa-cus implementation and also entirely preserved. Abacus canbe vertically configured through two traditional ways: sys-tem property tables, which is the Java equivalence of theenvironment variable mechanism; and policies, which is aCORBA specific way of fine tuning the functionalities of theORB9. We enhanced this configurability by adding supportfor J2ME environments through the creation of the J2MEnetwork transport level support according to the MIDP2.0specification10. This transport can be selected through thesystem property table.

4.1.2 Fine-granular horizontal configurabilityA vast amount of aspects are available for configuration

including IDL language data types, synchrony of remote in-vocation semantics, CORBA infrastructures, and program-ming styles. Table 1 categorizes a total of 26 aspects mod-ularized in Abacus.

Categories Features

Server Data Integer, String, Double,Types Fixed, Float, Long

Wide Character, Wide StringRemote Invocation Synchrony, Asynchrony (Oneway),Semantics Passing-by-valueCORBA Policies, Implementation Repository,Infrastructures Interface Repository, Type Code,

Collocation Optimization,Interceptors,Caching, Fault Tolerance,Object Disposal

Remote Invocation DII, DSI, Any, Dynamic AnyStylesRegional Support Locale, Encoding conversion

Table 1: Complete Listings of Configurable Aspects

4.2 Arachne: The Abacus synthesizerThe various stages of Just-in-time customization in Aba-

cus are integrated in and largely automated by a tool we havebuilt named Arachne11. Arachne is composed of three com-ponents: the aspect-aware IDL compiler, the Java sourceparser, and the inference engine. The aspect-aware IDLcompiler produces more modular skeletons and stubs in bothclasses and aspects. It also performs the initial feature selec-tions by examining the language elements used in the IDLdeclarations. The Java source parser further selects featuresthrough checking Java class types used in the user appli-cation. Currently, the just-in-time vertical configuration isnot yet taken into consideration since configurations via en-vironment variables, policies, or even deployment descrip-tors typically happen post development time. We defer the9For the rest of the paper, we use ORB (Object RequestBroker) to denote the implementation instance of CORBA

10J2ME Mobile Information Device Profile URL: http://java.sun.com/products/midp/

11A mythical character who is too good at weaving

1 aspect aspect1, aspect2, … ;

2 modulename { 3 aspect1 = aspect2 * (aspect3 + aspect4); 4 …..;

5 };

Figure 2: Illustration of language elements in HDL

discussion of the “later-time” just-in-time customizations ofboth dimensions to our future research.

4.2.1 Aspect-aware IDL compilerThe aspect-aware IDL compiler carries out two key func-

tions in the early stage of the JiM process: aspectizing stubsand skeletons and explicitly acquiring middleware function-alities from service declarations. Stubs and skeletons areintegral parts of the middleware, generated by IDL com-pilers as adapters that translate application semantics intothe machinery of middleware. Therefore, aspect-orientedmodularization of stubs and skeletons must be performedduring IDL compilation by properly generating the mini-mum (convolution-free) adaptation code and expressing therest of the functionalities in aspect modules. During thesame process, the compiler conveniently collects all the IDLlanguage elements that can be used to initiate functionalityinference. Our aspect-aware IDL compiler is an extensionof a prototype presented in [15] and constructed entirely inaspects woven into the JacORB 12 IDL compiler. Our com-piler is still experimental since we do not have access to thesource of the ORBacus IDL compiler.

4.2.2 Dependencies, constraints andconvolution descriptions

In Arachne, dependencies, constraints and convolution de-scriptions are separate specifications defined as Boolean ex-pressions. Dependencies and convolution descriptions arepropositional reflecting the innate relationships among mid-dleware aspects. Constraints are predicative because theprescribed relationships are only true under specific externalconditions. Constraints can be either provided as referencesby the vendor or defined by the user.

Currently, dependencies in Arachne are specified in a sim-ple language called horizontal dependency definition lan-guage (HDL). Figure 2 illustrates the basic structure ofHDL. Identifiers of aspects can be declared using the aspectkeyword (line 1). Dependency rules of the same nature canbe grouped and scoped with a name (line 2). “*” standsfor logical AND, and “+” stands for logical OR. In our ex-ample (line 3), aspect1 depends on aspect2 together witheither aspect3 or aspect 4. In Figure 3, we list all thedependencies of horizontal features in Abacus. An excep-tion is made for the dependency rule “core” (first rule inFigure 3) in which “core” is not a selectable feature andalways activated by default. The “core” dependency ruleallows us to specify the minimum valid configuration of Aba-cus. In our current definition, a valid Abacus instance mustsupport either synchronous or asynchronous communication(oneway). Constraints are used to limit the freedom of fea-ture selection by denying the selection of certain features incertain environments. They are also defined in HDL for-

12JacORB URL:http://www.jacorb.org

aspect any, dynamic, pi, synchrony,

asynchrony,...;

Core {

core = synchrony + asynchrony;

any = int + string + ulonglong + ... ; dii = dynamic; dsi = dynamic; pi = dynamic; dynamic = any; ulonglong = longlong ; IR = (DII + DSI)*typecode; convert = locale; wstring = wchar; };

Figure 3: Dependency specifications in Abacus usingHDL

j2me { resource = ! valuetype * ! finalize; precision = ! double * ! fixed; infrastructure = ! applet;

};

desktop { reflection = ! dii * ! dsi ; typeinfo = ! IR + ! IMR ;

};

Figure 4: Constraint specifications in Abacus

mat in which the left side of the Boolean expression is thename of the constraint rather than the name of a feature.In Figure 4, we list constraints for both J2ME and desktopplatforms defined in two HDL modules. The J2ME con-straints are mostly reflections of platform incompatibilitiesbetween J2SE and J2ME. The division into separate con-straining rules is to provide more specific feedbacks to usersupon violations. The Desktop constraints are illustrative.Table 2 gives the descriptions of the constraints.

Constraint Annotations

Resource J2ME disallows object serialization usedby “valuetype” and user garbage collection

Precision J2ME does not support high precision typessuch as “double” and “fixed”

Infrastructure The applet infrastructure isnot supported in J2ME

Reflection & Reflective remote invocations, often assistedtype info by type information are commonly used in

enterprise applications

Table 2: Descriptions of Constraints

Convolution descriptions describe the one-to-many rela-tionships between any two horizontal features. Figure 5gives a complete listing of the convolution descriptions usedin Arachne. The left side of the Boolean expression is a se-lectable feature, which crosscuts the features on the rightside. These descriptions are essential to the final synthesisas they direct which part of the “weaving” code of a partic-ular feature should be selected with respect to the activated

convolution_descriptions { double = any * valuetype; finalize = DII; fixed = any * IR; IR = policy * PI; policy = IMR * oneway * PI; ulonglong = any * valuetype; any = IR * policy * PI * valuetype; dii = any; dynamic = IR; longlong = double * any * valuetype; oneway = collocation; PI = DII * DSI * IR; wchar = any * convert * valuetype; };

Figure 5: Convolution descriptions in Abacus

features it crosscuts.

4.2.3 Inference algorithmGiven the initial feature manifest, the inference algorithm

in Abacus is responsible for selecting unspecified features inorder to satisfy all functional dependency rules. If multi-ple choices for selections exist, the algorithm guarantees togenerate a minimum superset of the initial manifest.

Before we introduce the algorithm, we first define a fewterms. Feature state: A feature can be in one of threestates during the inference process: selected (true), ex-cluded (false), and unspecified (unknown). Rule activation:A dependency rule r is activated if the feature on the leftside of r is selected, i.e., its value is “1” in the manifest.Minterm: Our algorithm only deals with rules written inthe form of sum-of-products. Each product term is called aminterm. A minterm represents an AND relationship betweenn features in the term. Cost function: A cost function asso-ciates each feature with a positive number representing thecost of including this feature. In our evaluation, we associatethe cost with the bytecode size of each feature to determinethe preferred alternative configuration. The cost could beother metrics of resource consumptions or even selected byusers.

We first present a simple algorithm, Algorithm 1 requiresall rules having only one minterm evaluated to unknown.The algorithm simply iterates each dependency rule r andinvokes the evaluate function on r against the inferred man-ifest. The function returns either true (rule satisfied) orfalse (rule violated) or unknown. In the case of unknown,new features are added to the manifest to satisfy r. Thealgorithm stops if no new features are added after iteratingthrough all rules in consecutive runs. The complete algo-rithm handles multiple disjunctive minterms in dependencyrules by recursively invoking the simple algorithm on eachminterm. At each recursive step, the cost function is used todetermine the minimum configuration and pass it to the up-per recursive level. Due to the page limitation, we presentthe full description of the algorithm and the proof for itsguarantees in an extended version of this paper.

4.2.4 Packaging schemaDue to the convolution problem, the code of an aspect

needs to be packaged according to a well-defined schemaso that the relevant parts of the aspect can be correctlyselected for the final synthesis. Figure 6 illustrates the gen-

Algorithm 1 Simple Inference Algorithm

Require: initial manifest F , dependency rules RLet F ′ = Floop

for each r ∈ R doif r is activated by F ′ thenBoolean result = evaluate(r, F ′)if result = true then

GOTO next relse if result = false then

RETURN errorelse

for each unkown f in r doset f to 1 or 0 so that r evaluates to 1

end forend if

end ifend forif F ′ = F then

BREAKelse

F = F ′

end ifend loopSet all unknown features in F to false

RETURN F

<< regular name space >>

aspectname

funct. impl

interaction

core

aspectname

test

default

aspectname

core

<< more aspect names >>

<< more aspect names >>

Figure 6: The packaging schema in Abacus

eral definition of the schema. In this hierarchical schema,the implementation and the interaction of an aspect, rep-resented by aspectname, are separated into two sub-trees,functional implementation and interaction. The spe-cific interactions between any two aspects is organized usingone aspect’s identifier as the package name under the “inter-action” sub-tree of the other aspect’s root. For simplicity,we use a Java package hierarchy to instantiate this schema.

4.2.5 Synthesis processThe synthesis process is guided by the Arachne user in-

terface and initiated by loading IDL definitions and appli-cation source locations. During the source analysis, we linkthe class types in the application source to the implemen-tation class types of an aspect to discover whether this as-pect should be activated or not. Collecting type informationof Java applications can be accomplished by many tools,and, for convenience, we chose to use the parsing engineof Prism [16], our aspect mining tool. Upon the comple-

tion of IDL and source analysis, the activated features aremarked on the feature pallet on which user can make furtherselections and adjustments. The complete set of explicitlyacquired features is then processed by the inference enginewhich generates the final manifest of features.

With the help of our packaging schema and convolutiondescriptions, the final synthesis procedure proceeds as de-scribed in Algorithm 2. The output of this procedure is a listof modules corresponding to the final manifest. In our cur-rent implementation, a resource list is generated and handedover to the AspectJ weaver. More sophisticated buildingtools such as ant13 could also be exploited. A note-worthycharacteristic of our HDL-based feature synthesis procedureis that it is easy to add a new aspect feature if its imple-mentation conforms to the code naming schema. Arachneis able to reason about this new feature if its dependenciesand convolution descriptions are correctly specified in HDL.

Algorithm 2 Synthesis Procedure

Require: final manifest F , convolution descrition set Cfor all f in F do

if ∃c ∈ C such that f activates c thenfor each f ′ on the right side of c do

Include all modules in the path “f ⇒functionalimplementationInclude all modules in the path “f ⇒ coreInclude all modules in the path “f ⇒interaction ⇒ f ′”

end forend if

end for

4.2.6 Integration test synthesisThe functionality of the synthesized Arachne instance can

be verified through a synthesized set of test cases for thefeatures included in the implementation. In Abacus, testcases are written in JUnit independently for each feature.All share a common starting point by registering them-selves with this starting point through AspectJ advices. Theschema for test-case organization is the same as for the fea-tures, and the same synthesis procedure (Algorithm 2) isused. Therefore, when a particular feature is selected, itstest cases are also “woven” into the final test plan.

5. EVALUATIONOur evaluation focuses on assessing the customization ca-

pability of JiM concepts through the Abacus implementa-tion. This assessment includes a broad range of softwaremetrics including both static characteristics and dynamicperformance evaluations. We divide the evaluation to twoportions: first the exemplary usage of Abacus in supportinga ubiquitous messenger application and then the random-ized selections of features which models different real-worldusage scenarios. All experiments are run on a Pentium 42.5GHz Linux workstation running Redhat 9.0. The J2MEconfiguration is evaluated using the Nokia Series 90 conceptemulator14.

13Ant. URL: http://ant.apache.org/14Nokia Emulators. URL: http://www.forum.nokia.com

1 #include<mmsg.idl> 2 module CORBAMessenger{ 3 interface MiniMessenger{ 4 void login( in string user); 5 void logout( in string user); 6 seqMsg contact( in Msg info); 7 oneway void asyncContact( in Msg info);

}; };

Figure 7: Service declarations of UMessenger

5.1 Ubiquitous MessengerA distributed application is well-suited for JiM if the same

operational logic ought to be supported in diversified do-mains. Instant messaging applications such as ICQ or theMSN messenger are good examples because their primaryfunctionality, i.e., message exchange, is widely available onnetworked computers including cell phones, PDAs, privatedesktops and enterprise environments. Each environmenthas distinct computational requirements. We have designeda messenger application, ubiquitous messenger (UMessen-ger), which provides increasingly richer functionalities in en-vironments with lesser resource constraints. Table 3 showsthe setup of our target environments, the assumed con-straints for our messenger applications and the aspect con-figurations.

Target Constraints AspectEnvironment Configurations

Embedded Platform Only supports sync, async,(J2ME, CLDC 1.0, strings and string,long longMIDP 2.0) numeric dataDesktop (J2SE) Supports large All of above +

file exchange double, valuetypeEnterprise Supports dynamic All of above +Features types, encryption, Any, portable

and transaction interceptorsthrough interceptors

Table 3: Ubiquitous Messenger Setup

Figure 7 shows the service declarations in IDL definitionsfor the messenger in these three target environments. Theremote interfaces are kept simple and identical in all cases,but we use richer sets of IDL data types in the definitionsof the message payload to reflect different functionalities ofthe messenger. Figure 8 shows the corresponding IDL defi-nitions of messages. Despite its simplicity, we use UMessen-ger to show the kind of versatility in aspect configurationsAbacus is able to support.

5.1.1 Static propertiesWe first measure the static properties on the compiled

Java byte code. The static properties such as size and cou-pling are generally considered as reflecting the complexityof the code and the degree of difficulties in terms of main-tenance and evolution. Table 4 reports the sizes of the syn-thesized ORBs as well as the coupling metrics measuredon bytecode by JDepend15. Our baseline of the compari-

15JDepend URL:http://www.clarkware.com/software/

module CORBAMessenger{ struct Msg{

string from; string to; string stringdata; long long numericData;

}; };

module CORBAMessenger{ valuetype LargeData{

private string filename; typedef sequence <octet> content; long save();

}; struct Msg{ //repeat fields of minimum message

sequence <double> floatData; LargeData payload;

}; };

module CORBAMessenger{ valuetype LargeData{ //same as in desktop message

}; struct Msg{ //repeat fields of desktop message

any anyData; }; };

Figure 8: Message definition for embedded environ-ment (a), desktop environment (b), enterprise envi-ronment (c)

son is the original ORBacus ORB which does not adapt todifferent functionalities in UMessenger. As expected, oursynthesized ORB constantly has smaller bytecode sizes. Forexample, the configuration for J2ME produces an ORB mea-sured 42% of its original size. The degree of coupling in allthree configurations is considerably lower than in the origi-nal ORB varying from 16% to 33%.

Target Bytecode Efferent AfferentEnvironment Size Coupling Coupling

Embedded Platform 823.9k 249 183Desktop (J2SE) 875.1k 251 185Enterprise 1168k 304 230

Original 1945.3k 365 275

Table 4: Static comparisons with the original ORB

5.1.2 Runtime propertiesTo study the runtime characteristics of Abacus, we first

measure and compare the time taken for payloads to traversethe middleware stack for all three generated ORBs as wellas the original ORB. We then collect the response time, thememory usage, and the cache miss rates of these ORBs.

Payload transportation.For this experiment, we host boththe client and the server on the same machine to minimizethe network delay. Figure 9 shows the average cost, mea-sured using a regular JVM, of the payload transportationfor the original ORB as well as the synthesized ORBs forthe UMessenger in the desktop and the enterprise settings.

JDepend.html

Messenger Client-Server Data Send Average

0

2000

4000

6000

8000

10000

12000

14000

0 2 4 10 30 50 200

400

1000

3000

5000

2000

040

000

Payload Size (octet)

Invo

catio

n Ti

me

(use

c)

Originj2medesktopenterprise

Figure 9: Data transport of UMessenger using Aba-cus

The full J2ME configuration is measured in an emulationsetting using the Nokia Series 90 emulator. The responsetime of ORBs in the regular JVM is roughly equal as thegraph shows. The synthesized ORBs incur virtually no over-head compared to the original version in the presence of theAspectJ runtime infrastructure. We are not observing ap-parent speedups. This is a combined effect of both the effi-cient design in the original implementation and the difficultyin performance gains in face of the JVM overhead and op-timization. The emulated J2ME responses are significantlyslower compared to regular JVM environments.

Response, resource, and cache.Table 5 reports a fewruntime metrics we have collected in addition to the bench-mark. We measure the average response time, memory us-age and cache performance numbers, all compared to thatof the original version. The cache misses are collected forthe server process using PCL16 over 200,000 remote invo-cations. The response time is measured as the average of200k remote invocations of an empty method(“ping”). Allthree configurations are basically equivalent in terms of theresponse time with the J2ME version using regular networktransport being 7% faster than the original ORB. The mem-ory usages of all three versions are within 1% difference ofeach other. However, compared to the original version, Aba-cus exhibits an average of 24% reduction of memory usage.Similar patterns are observed on Level-1 cache misses, in-cluding both data cache (DL1), instruction cache (IL1), andLevel-2 miss rates. The J2ME configuration consistently hasthe best performance measures because it has a minimal setof functionality.

5.2 Randomized CustomizationThe purpose of UMessenger is to illustrate one type of

application which can take advantage of the customizationcapabilities of JiM. Our intention of evaluating Abacus ondifferent application domains has influenced the fabricationof features in UMessenger. And this is not an approximationof the customization choices that the real world demands of

16Performance Counter Library. URL:http://www.fz-juelich.de/zam/PCL/

Target Response Memory IL1 DL1 L2

J2ME 261 15223k 64067k 190394k 0.0058Desktop 281 15164k 69582k 195186k 0.0052Enterprise 277 15028k 75307k 197084k 0.0052Original 282 19694k 70277k 210822k 0.0063

Table 5: Dynamic Properties Comparing with Orig-inal ORB (Response time in µ sec)

JiM. To emulate unpredictability of user application fea-tures, we choose to randomize the selections of features byassigning each configurable feature a random variable froma uniform distribution. Each feature has equal chances ofbeing selected, unselected, or unknown. We iterate this ran-domization for fifteen times and obtain ten valid configura-tions. Table 6 shows the initial random selections (under Rheader) and the selection decisions made by our inferenceengine (under I header) in five random runs. A selected fea-ture is represented as “1”, or “0” otherwise. “x” means theselection is unspecified. In the “I” column, we only show thevalue if it is modified compared to its initial value in the “R”column. We can observe a few characteristics of Arachne: 1.the selection decisions of all features are made; 2. most ofthe “x” features are set to “0” driven by the minimalismgoal of our inference algorithm.

Features Random Configurations

RC1 RC2 RC3 RC4 RC5R I R I R I R I R I

double x 0 x 0 1 x 0 1finalize x 0 x 0 0 0 0fixed x 0 x 0 1 1 xIMR x 0 x 0 1 0 1IR 0 0 0 0 xpolicy x 0 0 x 0 0 0ulonglong 0 x 0 1 x 0 xany 1 x 1 0 1 xapplet 0 1 1 1 xcollocation x 0 x 0 x 0 1 0convert 0 1 x 0 x 0 xDII x 0 x 0 x 0 x 0 1DSI 1 0 0 1 xoneway 1 x 0 1 1 0PI 1 1 0 x 0 1valuetype x 0 x 0 x 0 x 0 xwchar 1 x 0 1 1 xdynamic x 1 x 1 x 0 1 0float x 0 1 x 0 0 xlonglong 0 0 1 1 x 0 x

Validity valid valid valid valid invalid

Table 6: Randomized Feature Selection and Synthe-sis in Abacus

5.2.1 Static propertiesWe collect the same static properties as in the previous

case. We show in table 7 that the bytecode sizes of sixrandomly synthesized ORBs are between 56% (RC3) and

Randomized Customization Client-Server Data Send Average

0

500

1000

1500

2000

2500

0 2 4 10 30 50 2004001000300050002000040000

Payload Size (octet)

Invo

catio

n Ti

me

(use

c)

OriginRC1RC2RC3

Figure 10: Benchmarking the Randomly Synthe-sized ORBs

75% (RC4) of the original ORB, with the efferent couplingranging from 73.6% (RC3) to 88% and the afferent couplingranging 72.6% to 88.7%. This shows the redundancy in theoriginal implementations and Abacus can always synthesizea leaner middleware implementation.

Target Bytecode Efferent AfferentSize Coupling Coupling

RC1 1237.8k 299 225RC2 1217.1k 300 224RC3 1095.6k 269 197RC4 1463k 322 244RC5 1290k 309 233RC6 1351k 313 236

Original 1945.3k 365 275

Table 7: Static Comparisons with Original ORB

5.2.2 Runtime propertiesTo study the runtime properties of the randomly synthe-

sized ORBs, we repeat the same set of experiments by firstmeasuring the average time for transporting payloads of in-creasing sizes. We then measure the response time, thememory consuption, and the cache miss rates. All exper-iments are run in the regular JVM.

Payload transportation.In Figure 10, we plot the averagetime of the payload transportation for randomly synthesizedORBs. Similar to the case of UMessenger, the performancesof all versions are roughly equal. This further illustrates theORBs synthesized in AspectJ incur no apparent overhead.

Response, resource, and cache.In Table 8, we show theaverage response time, memory usage, and cache misses forthe six randomly synthesized configurations. Similar to thecase of UMessenger, the response time of all configurationsare within 1% differences of each other. The memory us-ages reductions are within 5% (RC4) and 24% (RC3) ascompared to the original version. The reductions of level-1

instruction cache misses is as much as 8% (RC6) and 3% onaverage. The reductions of level-1 data cache misses rangefrom 1% (RC3) to 10% (RC6). The average reduction oflevel-2 cache-miss rates is 4%. The large majority of thesynthesized ORBs perform better than the original one.

Target Response Memory IL1 DL1 L2

RC1 285 15473k 67518k 194102k 0.0064RC2 287 15175k 69210k 190411k 0.0055RC3 284 14960k 68730k 208584k 0.0056RC4 268 18660k 70895k 205221k 0.0066RC5 275 15802k 67391k 190998k 0.0062RC6 281 15231k 64723k 189562k 0.0060

Original 282 19694k 70277k 210821k 0.0063

Table 8: Runtime Properties Comparing with Orig-inal ORB

5.2.3 Concluding remarksOur evaluation shows that the JiM paradigm is effective

in solving this design dilemma: achieving generality whilesacrificing specialty or vice versa. Abacus is general enoughto fit dramatically different distribution concerns and yetsufficiently specialized for individual scenarios. Both staticand dynamic measurements reflect that we can have signifi-cant complexity reductions and runtime improvements if wetailor middleware according to specific distribution needs ofindividual applications.

6. RELATED WORKConfigurability and customization are active themes of

current middleware research. We skip the comparisons toresearch work in [10, 4, 2] because they address adaptation,which can be interpreted as dynamic customization. Sinceadaptation is not the focus of this paper, we first discuss therelated research work in the context of highly customizablemiddleware architectures. In addition, we discuss differencesbetween the synthetic approach of JiM and the product lineapproaches.

Customizable Middleware: The FACET [8] projectexperiments with the concept of feature subsetting in mid-dleware through the aspect oriented implementation of aCORBA event channel. FACET divides the functionality ofthe even channel into the “base” and “features” where the“base” implements the fundamental functionality of FACETand “features” are added into the “base” via AspectJ. Alarge number of configuration possibilities exist in FACET,and feature dependency graphs are used to limit valid con-figurations. Fundamentally different from FACET, Abacusis proposed as a post-postulated solution where the distribu-tion concerns of applications are evaluated and reasoned. Interms of implementation techniques, we share some commondesign elements, such as the core-based design, the use offeature dependencies, and the aspect oriented test case syn-thesis. In Abacus, through dependency specifications, wemake very explicit both the relationships among core andfeatures as well as the relationships among features. Thisserves the foundation for automatic inference and synthesis.

The MicroQoSCorba project [12]17 targets resource-con-17 MicroQoSCORBA. URL:http://microqoscorba.eecs.

strained environments and provides both a fine-grained ar-chitecture and CASE tools to make automatic adjustmentsaccording to the variations in both user applications andplatforms. Like Abacus, MicroQoSCorba also uses IDL com-pilers to collect required middleware features and to di-rect the building process to select relevant implementations.However, the source code analysis is missing in MicroQos-Corba compared to Abacus. The feature dependencies andthe inference stage are not explicitly addressed in MicroQos-Corba. Most importantly, Abacus provides a higher de-gree of modularity using AOP and scales in two dimensions.We have similar approaches to MicroQoSCorba of makingkey middleware elements lightweight. However, contrary toMicroQoSCorba, our “customization” is not at the cost oflosing the original full functionality, benefiting from the as-pect oriented approach. As we have illustrated, the con-figuration domains of Abacus are not limited to embeddedsystems and also include other application domains.

Product Lines and Generative Programming: Gen-Voca [1] advocates the synthesis of a family of complex sys-tems from incrementally adding features to simple ones us-ing step-wise-refinement (SWR). The AHEAD tool suite al-lows algebraic specifications of the SWR relationships amongfeatures and carries out the automatic synthesis. GenVocaembodies a rich yet comprehensive methodology for pro-gramming specification and program generation. Compar-atively, our research has two slightly different focal points:we focus on enabling the user-driven middleware compo-sition from fine-granularity modules, a paradigm orthogo-nal and complimentary to the synthesis-based approachesin GenVoca and SWR; we focus on the higher degree mod-ularization in large and complex software systems such asmiddleware through the effective use of aspects.

Colyer and Clement [5] demonstrated how aspect orientedrefactoring can be used to support commercial middlewareproduct families. The focus of their work is to evaluate thesuitability of AOP in supporting very large software projectsthrough capturing crosscutting features in aspects and weav-ing them into other product family members as new features.They provide valuable experiences and insights which bene-fit us in scaling JiM to support even larger size middlewareimplementations.

7. CONCLUSIONTraditionally, the middleware architecture and its hosted

applications are bound by a causal relationship: middle-ware is designed, implemented and packaged first; appli-cations are developed in accordance with services providedby a particular middleware implementation. This type of“pre-postulated” middleware always poses many challengesin customizing middleware functionalities due to the difficul-ties in making good presumptions of what features are actu-ally needed in specific usage scenarios. We believe that, inthe case of middleware customization, the best presumptionis not to make any presumptions at all. We have proposedto reverse the traditional causal relationship by delaying thecomposition of middleware architecture till after the user ap-plication is designed or implemented. We term middlewarearchitectures supporting this new relationship Just-in-timemiddleware architectures (JiM).

We have presented the mechanism of JiM as a multi-

wsu.edu

staged process including feature acquisition, functional in-ference, constraint verification, and implementation synthe-sis. We also have built Abacus, a Java ORB based on “as-pectizing” ORBacus, an industrial strength CORBA imple-mentation. In addition, we have built Arachne, a tool whichintegrates the aspect-aware IDL compiler and the inferenceengine. Our evaluation proves that Abacus is capable ofsolving the “impedance mismatch” problem by providingmiddleware functionalities across application domains fromembedded devices to enterprise environments through post-compilation customization. Our quantifications show thatAbacus exhibits a great versatility in terms of physical sizes,resource consumptions, and runtime performance, in addi-tion to general improvements on these qualities as comparedto the original implementation.

Our title of this paper suggests that we are just at thebeginning of exploiting this useful paradigm. Our currentimplementation has greatly benefited from but is also lim-ited by the design of ORBacus. That is, our customiza-tion ability is confined within the capability of the originalORBacus. In our future research, we will focus on furthervalidation of the JiM approach through supporting more di-versified middleware features and more application domainsusing both new implementations and case studies. We arealso interested in exploiting the load-time weaving capabil-ity of AspectJ and postponing the synthesis of middlewareimplementations in order to take advantage of the load timeinformation. For instance, we can define cost functions tak-ing memory usage as inputs. Finally, we will also studyhow generative approaches can benefit JiM by incorporat-ing model driven techniques such as MDA18.

AcknowledgmentsThis research has been supported in part by an NSERCgrant and in part by an IBM CAS fellowship for the firstauthor. The authors are very grateful for this support.

8. REFERENCES[1] D. Batory, J.N. Sarvela, and A. Rauschmayer. Scaling

step-wise refinement. IEEE Transactions on SoftwareEngineering, 30(6):355–371, June 2004.

[2] Gordon S. Blair, Geoff Coulson, Anders Andersen,Lynne Blair, Michael Clarke, Fabio Costa, HectorDuran-Limon, Tom Fitzpatrick, Lee Johnston, RuiMoreira, Nikos Parlavantzas, and Katia Saikoski. TheDesign and Implementation of Open ORB 2. IEEEDistributed Systems Online Journal 2(6), 2001.

[3] Jr. Brooks, F.P. The Mythical Man-month.Addison-Wesley Publishing Company, 1975.

[4] M. Clarke, G. Blair, G. Coulson G., andN. Parlavantzas. An efficient component model for theconstruction of adaptive middleware. In IFIP/ACMInternational Conference on Distributed SystemsPlatforms (Middleware’2001), November 2001.

[5] Adrian Colyer and Andrew Clement. Large-scaleAOSD for middleware. In 3rd InternationalConference on Aspect-oriented Software Development(AOSD’04), pages 56 – 65, Lancaster, UK, 2004.

[6] Edsger W. Dijkstra. The humble programmer.Commun. ACM, 15(10):859–866, 1972.

[7] William Harrison and Harold Ossher. Subject-orientedprogramming: a critique of pure objects. InProceedings of the eighth annual conference onObject-oriented programming systems, languages, andapplications, pages 411–428. ACM Press, 1993.

18Model Driven Architecture. URL:www.omg.org/mda

[8] Frank Hunleth and Ron Cytron. Footprint and featuremanagement using aspect-oriented programmingtechniques. In Languages, Compilers, and Tools forEmbedded Systems (LCTES’02), 2002.

[9] Gregor Kiczales, John Lamping, Anurag Menhdhekar,Chris Maeda, Cristina Lopes, Jean-Marc Loingtier,and John Irwin. Aspect-oriented programming. InMehmet Aksit and Satoshi Matsuoka, editors,Proceedings European Conference on Object-OrientedProgramming, volume 1241, pages 220–242.Springer-Verlag, Berlin, Heidelberg, and New York,1997.

[10] Fabio Kon, Manuel Roman, Ping Liu, Jina Mao,Tomonori Yamane, Luiz Claudio Magalhaes, andRoy H. Campbell. Monitoring, Security, and DynamicConfiguration with the dynamicTAO Reflective ORB.In Proceedings of the IFIP/ACM InternationalConference on Distributed Systems Platforms andOpen Distributed Processing (Middleware’2000),number 1795 in LNCS, pages 121–143, New York,April 2000. Springer-Verlag.

[11] Thomas Ledoux. OpenCorba: a reflective open broker.In Pierre Cointe, editor, Meta-Level Architectures andReflection, Second International Conference,Reflection’99, volume 1616 of Lecture Notes inComputer Science, pages 197–214, Saint-Malo, France,July 1999. Springer-Verlag.

[12] A. David McKinnon, Kevin E. Dorow, Tarana R.Damania, Olav Haugan, Wesley E. Lawrence,David E. Bakken, and John C. Shovic. A configurablemiddleware framework for small embedded systemsthat supports multiple quality of service properties.Submitted to SoftwarePractice and Experience.

[13] John Mylopoulos, Lawrence Chung, and Brian Nixon.Representing and using non-functional requirements:a process-oriented approach. IEEE Transactions onSoftware Engineering, 1992.

[14] Charles Zhang and Hans-Arno Jacobsen. QuantifyingAspects in Middleware Platforms. In 2ndInternational Conference on Aspect Oriented Systemsand Design, pages 130–139, Boston, MA, March 2003.

[15] Charles Zhang and Hans-Arno Jacobsen. RefactoringMiddleware Systems: A Case Study. In InternationalSymposium on Distributed Objects and Applications(DOA 2003), Catania, Sicily (Italy), 2003. LectureNotes in Computer Science, Springer Verlag.

[16] Charles Zhang and Hans-Arno Jacobsen. Prism isresearch in aspect mining. In Companion of the 19thannual ACM SIGPLAN conference on Object-orientedprogramming, systems, languages, and applications.ACM Press, 2004.

[17] Charles Zhang and Hans-Arno Jacobsen. ResolvingFeature Convolution in Middleware Systems. InProceedings of the 19th ACM SIGPLAN conference onObject-oriented Programming, Systems, Languages,and Applications, September 2004.