A middleware-transparent approach to developing distributed applications

SOFTWARE—PRACTICE AND EXPERIENCESoftw. Pract. Exper. 2005; 35:1131–1154Published online 23 May 2005 in Wiley InterScience (www.interscience.wiley.com). DOI: 10.1002/spe.666

A middleware-transparentapproach to developingdistributed applications

Sudipto Ghosh∗,†, Robert B. France, Devon M. Simmonds,Abhijit Bare, Brahmila Kamalakar, Roopashree P. Shankar, Gagan Tandon, Peter Vileand Shuxin Yin

Computer Science Department, Colorado State University, Fort Collins, CO 80523, U.S.A.

SUMMARY

An innovative middleware-transparent approach to developing distributed applications is presented.The approach uses an aspect-oriented software development technique to separate an application’smiddleware-independent functionality from its middleware-specific functionality. Application elementsthat are specific to the middleware are localized in aspects that can be seamlessly integrated intomiddleware-independent application designs. The middleware-transparent approach is used to decouplebusiness functionality from middleware-specific functionality. The decoupling allows developers to changemiddleware application elements without significantly modifying business functionality. Middlewaretechnologies such as Java Remote Method Invocation (RMI), Jini, Simple Object Access Protocol (SOAP)remote procedure call (RPC) and .Net are used as examples to illustrate the approach. Copyright c© 2005John Wiley & Sons, Ltd.

KEY WORDS: aspect-oriented programming; distributed applications; Java RMI; Jini; middleware technologies;SOAP-RPC; .Net

1. INTRODUCTION

The rapid evolution of the Internet and network technologies is making distributed systems thenorm for modern business applications. In a distributed system, the middleware is a layer ofsoftware between applications and the network they run upon. Middleware technologies, for example,CORBA [1], COM [2], Jini [3], .Net [4] and Simple Object Access Protocol (SOAP) [5], providehigh-level programming abstractions that enable remote method invocations over underlying networksof heterogeneous platforms. They also provide services such as naming, trading, and messaging, andquality of service features such as security and fault tolerance.

∗Correspondence to: Sudipto Ghosh, Computer Science Department, Colorado State University, Fort Collins, CO 80523, U.S.A.†E-mail: [email protected]

Copyright c© 2005 John Wiley & Sons, Ltd.Received 9 January 2004

Revised 19 November 2004Accepted 19 November 2004

1132 S. GHOSH ET AL.

Middleware functionality is cross-cutting, in that it is pervasive and is tangled with business-specificfunctionality in distributed applications. Middleware services (e.g., security), may also cross-cutother middleware features (e.g., event services and transactions). Middleware services are sometimesencapsulated as components. However, to use the services, the business-specific design must includecalls to services at appropriate locations in the design and must ensure appropriate ordering of services(e.g., performing authentication before authorization). The cross-cutting nature makes changing themiddleware of distributed applications risky and challenging.

This paper presents a middleware-transparent approach to the development of distributedapplications that allows architects to design business functionality without considering the middlewarethat will provide transparent access to remote resources. The approach uses an aspect-orientedtechnique to decouple business functionality from middleware concerns. Middleware-specificapplication elements are localized in aspects that can be seamlessly integrated (or woven) into anapplication design describing core business functionality. The localization of cross-cutting middlewareconcerns helps to insulate designs of business functionality from changes in middleware technologies.

The approach can be applied to designs expressed in an aspect-oriented programming (AOP)language, such as AspectJ, or to designs expressed in a modeling language such as the UnifiedModeling Language (UML) [6]. The focus of this paper is on the use of the approach at the codelevel. An overview of how the approach can be used to support model-driven development is given inSections 2 and 9.

2. BACKGROUND

Advances in Internet and middleware technologies have spawned a new generation of software-intensive systems. As organizations seek to enhance services and gain competitive advantage,developers are under increasing pressure to develop quality systems that quickly utilize newtechnologies. Software evolution is problematic when developers must adapt software systems torapidly evolving technologies in order to maintain or enhance an organization’s effectiveness orcompetitive advantage. The problem is exacerbated when pervasive technology-specific functionalityis tangled with core business functionality, as is often the case for middleware functionality.

Separation of middleware functionality from business functionality can ease the task of evolvingdistributed systems. Aspects can be used to support such separation of concerns. Aspects at the codelevel can be described using an AOP language [7–15]. An AOP aspect is an implementation or designconcern that cross-cuts the primary functional units of a program. Recent work examines the useof AOP to achieve middleware transparency. Bussard [16] encapsulated several CORBA services asaspects using AspectJ to make CORBA programming transparent to programmers. Hunleth, Cytron,and Gill [17] suggest the creation of an Aspect Interface Definition Language (IDL) for CORBA tocomplement the IDLs that are now available for languages such as Java and C++. Their proposedAspectIDL would support several new types of AspectJ introductions: interface method and field,interface super class, structure field, oneway specifier, and IDL typedef and enumerations.

The time-to-deliver pressure is often used as an excuse to adopt code-centric approaches to softwaredevelopment, but developers are finding it increasingly difficult to cope with the complexity ofdeveloping secure, fault-tolerant, highly available distributed software systems using only code leveldescriptions. The Model Driven Architecture (MDA) initiative recognizes the need for raising the levelof abstraction at which developers describe complex systems, and advocates the use of model-centric

Copyright c© 2005 John Wiley & Sons, Ltd. Softw. Pract. Exper. 2005; 35:1131–1154

DEVELOPING DISTRIBUTED APPLICATIONS 1133

approaches to development. MDA advocates separation of technology-independent concerns fromtechnology-specific concerns. A platform-independent model (PIM) describes the behavior of theapplication ‘undistorted by the idiosyncrasies of the technology or technologies in which it willbe implemented’‡. A platform-specific model (PSM) describes an application in technology-specificterms. An MDA design consists of PIMs, PSMs and PIM to PSM mappings. The mappings, ideallyimplemented in tools, transform the PIMs to PSMs. Use of an MDA approach makes it unnecessaryto repeat the process of modeling an application’s functionality and behavior each time a newimplementation platform comes along.

When used at the modeling level, the middleware-transparent approach aligns well with MDA.The description of the middleware-independent functionality is a PIM and aspects describe middleware(platform) functionality. A PSM is obtained by weaving aspects and a PIM. Researchers have startedto address the problem of describing and using aspects at an abstraction level higher than theprogramming language level [18–25]. In the aspect-oriented modeling approach proposed by Clarkeet al. [18] and Clarke and Murphy [19], a design called a subject is created for each system requirement.A comprehensive design is a composition of subjects. Subjects are expressed as UML model views,and composition merges the views provided by the subjects.

Gray et al. [21] use aspects to represent the cross-cutting functionality in domain-specific models.Their research is part of the Model Integrated Computing (MIC) initiative that targets embeddedsoftware systems. MIC extends the scope and usage of models such that they form the backboneof a development process for building embedded software systems. Requirements, architecture, andthe environment of a system are captured in the form of formal high-level models that allow therepresentation of concerns. The middleware-transparent approach can complement these and otheraspect-modeling efforts by providing UML-based techniques for representing and composing cross-cutting middleware functionalities.

The Universally Interoperable Core (UIC) designed by Ramon, Kon and Campbell [26], is acollection of components that specify the requirements for a generic object request broker (ORB).An ORB allows the interaction of distributed objects that provide and consume services. The UICwas designed to address the needs of handheld devices that interact in distributed environments buthave access to limited resources. Most middleware implementations are customized for desktops andservers but not for handheld devices. This forces developers of these devices to implement customizedsolutions. However, customization eliminates the ability of handheld devices to interoperate withInternet-based distributed applications and to export their services to other applications. The UIC wasdesigned to address these weaknesses. The UIC consists of a collection of abstract components thatcan be specialized for a specific middleware, device, or network. Among the benefits of the UIC isdynamic configurability—that is, the ability to reconfigure the UIC at run-time using dynamicallyloadable and replaceable libraries of the UIC components. In the proposed approach, the middlewareservices may be provided as components. However, their use is encapsulated in the form of aspects.Pichler et al. [27] have shown how one can aspectualize component models.

The authors are not aware of any aspect-oriented modeling (AOM) approaches that specificallysupport middleware transparency. France, Ray, and Georg [28,29] use template UML diagrams to

‡See http://www.omg.org/mda/faq mda.htm.



describe aspects representing security concerns (e.g., see Georg et al. [29–31]). This paper adapts andenhances this work to describe middleware-specific aspects.

3. OVERVIEW OF PROPOSED APPROACH

Middleware-specific functionality is cross-cutting, that is, the functionality is scattered across multipleclasses and methods in a distributed application. In client–server systems, client and service classesinclude middleware functionality that enables clients to access remote services in a transparentmanner. In peer-to-peer (P2P) applications, each peer has middleware functionality that enables it totransparently access other peers on the network.

Changing functionality that cross-cuts a design can be difficult. Consider a scenario in whichan application developer creates a distributed application consisting of a client and a remoteservice and that uses a middleware platform M1 that implements remote service discovery (findingand locating services) and connectivity (establishing a connection to the services). Using currentdevelopment techniques the developer produces a design in which M1 functionality is tangled with thebusiness functionality. A few months later, a new middleware platform M2 that promises significantimprovement in middleware services arrives. A business decision is made to replace M1 by M2.The tangling of M1 features and business functionality across the design results in a costly and riskyredesign of the entire application.

In the previously described scenario, the required business functionality did not change, but thedeveloper had to modify the parts of the design that address business functionality to accommodatethe new middleware platform. One way to ease evolution of middleware-specific functionality in adistributed application is to isolate middleware functionality in aspects. This allows developers to createmiddleware-transparent designs (MTDs)—that is, designs that do not address middleware concerns.An MTD is composed with middleware aspects to produce a middleware-specific design (MSD).An MSD is a distributed application design that utilizes the middleware features implemented by theaspects.

The aspect-oriented approach is illustrated in Figure 1. Each middleware feature is localized in anaspect, Middleware Aspect-i. The aspects are composed with the MTD that describes the businessfunctionality of the client/service/peer system. In the context of MDA, an MTD expressed in amodeling language such as the UML is a PIM, and the MSD produced by composing aspect modelswith the MTD is a PSM. At the code level, MTDs and aspects can be expressed in an aspect-orientedprogramming language such as AspectJ, and the MSDs are the result of compiling the MTDs withaspects.

Figure 2 illustrates how the aspect-oriented approach can ease evolution of a distributed application’smiddleware features. Features of the M1 middleware platform are localized in the set of aspectsM1aspects, and M2 features are localized in the aspect set M2aspects. Replacing the application’smiddleware platform M1 with a new platform M2 involves producing a new MSD, MSD2, bycomposing aspects in the set M2aspects with MTD1.

Figure 3 shows the aspect-oriented development framework used to support middleware-transparentdevelopment of distributed applications. The framework provides support for composing MTDs andaspects to produce MSDs. Two types of aspects are supported: middleware functional aspects (MFAs),



(MSD)Middleware Specific Design

Composer

(MTD)Design

Transparent

... aspect nMiddleware

aspect 2Middleware

aspect 1Middleware

Middleware

Figure 1. Composing middleware aspects and a MTD.

MSD2application change

middleware change

Develop MTD

Compose

Middleware platform M1

MSD1

Compose

Business Requirements

MTD1M1aspects

Develop Aspects

Middleware platform M2

Develop Aspects

M2aspects

Figure 2. Supporting evolution of middleware platforms.



Aspect WeaverConverter

EMTDMTD

Aspects (MFA, QoSA)

MSD

Enhanced Aspects (EMFA, EQoSA)

Figure 3. An aspect-oriented development framework.

and quality of service aspects (QoSA). QoSAs localize quality of service (QoS) functionality and MFAslocalize other middleware services. MFAs are used in the examples to illustrate the approach.

Each MTD has a particular architectural signature (structure) consisting of a collection of interfaces,classes and relationships. An MTD may differ significantly from another MTD in its architecturalsignature. Middleware aspects require that a design’s architectural signature has certain propertiesfor aspect weaving to be successful. A converter is used to incorporate these properties into anMTD. It uses knowledge about the middleware aspects to add hooks into an MTD so that it can bemechanically composed with aspects. The enhanced MTD (EMTD) produced by a converter has thearchitectural signature required by a middleware aspect. The conversion algorithm depends on theselected middleware service localized by an aspect (e.g., transaction) and the selected middlewaretechnology (e.g., Jini). For a given middleware, different aspects will require different architecturalsignatures. Each middleware technology will thus have its own set of converters.

There are significant benefits to this separation. The properties added by converters are not specifiedin MTDs as that would make the MTDs platform specific. The conversion is not implementedin the weaver (e.g., AspectJ) as this would make the weaver middleware specific. Specifying thetransformation in a separate component provides the flexibility and modularity needed to supportseparation of middleware-specific from middleware-independent concerns.

In the examples given in this paper, the middleware aspects are specific to a middleware technologybut are developed independently of any application. Before these aspects can be composed with anEMTD, the aspects may have to be modified. For example, some aspect elements may have to berenamed in order for them to work in an application context as desired. Converters are also used toconvert aspects to context-specific forms—enhanced MFAs and enhanced QoSAs (EMFAs EQoSAs)—that can be mechanically composed with EMTDs.

The following three-stage design process can be used to create a distributed application in theframework. Stage 1 activities can be done concurrently as can the activities of stage 2.

Stage 1. Tasks:

(a) create the MTD for the server and client;(b) select the target middleware and create middleware aspects (MFA, QoSA).



Stage 2. Tasks:

(a) transform the MTD to an EMTD using the application converter;(b) transform the aspects to enhanced aspects (EMFA, EQoSA) using the aspect converter.

Stage 3. Tasks:

weave the enhanced aspects into the EMTD to produce the PSM. A PSM is produced for eachclient and for each server.

4. JINI CASE STUDY

This section describes how Jini [3] features were successfully isolated in aspects at the code level.Jini requires the discovery of a lookup service, listening for the arrival of new services, leasemanagement, and remote invocation of service methods. AspectJ was used to implement Jini aspectsand Java was used for the application MTD. The client in the MTD contained code that invokedmethods on an object representing the service. Functionality for discovering and connecting to theservice was not included in the MTD. The service methods were implemented in the server code, butno lease management or proxy object creation code was written. When the aspects were woven withthe client and server code, the resulting code was a full-fledged Jini application.

For the Jini example, a simple distributed stock broker application is used. The example shows howthe middleware-transparent development approach can be used to develop a Jini-compliant applicationthat utilizes connectivity services in the middleware. The functional requirements of this applicationincluded providing clients with the ability to register with the stock broker service, and to buy and sellstocks. The MTD was written in Java with AspectJ as the aspect language.

The Jini converters and the MFA were developed as a one-time exercise. The MTD classes andinterfaces were also developed for the application. All other steps in the process were automated.Figures 4, 5, 6, and 7 show the class diagram views of the MFA, MTD, EMTD and the application PSMrespectively. The specific activities that produced these models during the design phase are describedbelow:

1. Create the MTD and MFA. The MTD shown in Figure 4 was developed and tested as a stand-alone Java application. It consists of a single interface and three classes. The interface containsthe signatures of operations that allow clients to register with a broker and to buy and sell stocks.The class Broker implements the broker services declared in the interface. The MFA is shown inFigure 5.

2. Generate the Enhanced Models (EMTD, EMFA). A number of Jini design models are possible.The one that was selected required that the services to be made available by the server be capturedin an inner class, and that a proxy for this inner class be created as well. The aspect converterimplemented a simple string-matching algorithm that replaces aspect class names and attributeswith class names and attributes from the Stock Broker application. The application converter waswritten using the Java Tree Builder [32]. It generated the EMTD (see Figure 6) by refactoring theMTD to include seven new components, all of which are required by Jini. The tasks performedby the application converter are as follows:



StockBrokerInterface

<<interface>>

<<realizes>>

Authorization

StockHolderBroker

sell()buy()register()

Figure 4. Jini StockBroker MTD.

(a) create a remote interface to be used by the server;(b) create two inner classes: a server (from the MTD) and a proxy for the server;(c) create a wrapper class as the outer class for the two classes created in the previous task;(d) insert import statements from the interface into the wrapper class;(e) add Jini-specific throws clauses and/or exceptions statements to the client and server code.

3. PSM Generation. The AspectJ compiler was used as the weaver. This was both an asset anda challenge: AspectJ is Java compatible but the composition mechanisms are limited to thoseprovided by AspectJ. This is discussed further in Section 8.

This approach was repeated with several applications and middleware technologies such as JavaRMI, SOAP remote procedure call (RPC), and .Net. Functionality pertaining to discovering services,connecting to services, and advertising services, was successfully implemented as code-level aspects.Other middleware features pertaining to transactions, group management, and quality of serviceconcerns are part of the ongoing research project.

5. JAVA-RMI CASE STUDY

In Java remote method invocation (RMI) clients talk to servers by sending RMIs to remoteobjects. These objects are created by servers by extending the UnicastRemoteObject class,or by extending the Activatable class. Servers register remote objects created by extending theUnicastRemoteObject with a registry service, called rmiregistry, using the Naming class thatprovides facilities for binding, rebinding and unbinding. Clients look up services from the rmiregistryusing the lookup facilities provided in the Naming class.



codebase:Stringregistrations:Hashtabledisco:LookupDiscoveryitem:ServiceItemLEASE_TIME:int

UnicastRemoteObject

RemoteException

RMISecurityManager

MarshalledObject

ActivationGroupDesc

ActivationGroupID

ActivationGroup

ActivationDesc

ActivationID

ActivationExceptionActivatable

Activation

lease

UnknownLeaseException

constructorProxy(String)

Remote

ServerAspect

discovery

LookupDiscovey

DiscoveyEvents

DiscoveyListener<<interface>>

ServiceItem

ServiceRegistration

<<interface>>

ServiceRegistrar<<interface>>

Lookup

run()renewLeases()computeSleepTime()createProxy():StockBrokerInterfaceregisterWithLookup(ServiceRegistrar)discarded(DiscoveryEvent)discovered(DiscoveryEvent)

Lease<<interface>>

Figure 5. Jini StockBroker MFA.

Servers create remote activatable objects by extending the Activatable class, and register themwith the rmid daemon process. If the remote objects are not invoked over a specified period of time,they are deactivated. Reactivation occurs the moment a new client request arrives.

The middleware-transparent approach was used to develop a Book Shopping application that usesJava RMI. An aspect that handles remote exceptions that occur in Java RMI was written in AspectJ(see Figure 8).

Two aspects for the shopping cart that make the server-side Java-RMI aware were also developed.One aspect (Figure 9) was written for the UnicastRemoteObject type, and the other (Figure 10)for the Activatable type. Some client-specific aspects were also written that support looking upremote objects and remotely invoking these objects.



Broker

StockHolder

Authorization

registerbuysell

StockBrokerServiceRunnable

BrokerProxy

RemoteStockBrokerInterface

Remote

ActivatableSerializable


Figure 6. Jini StockBroker EMTD.

6. SOAP-RPC CASE STUDY

SOAP is a lightweight, XML-based communication protocol for exchanging information betweenapplications in a distributed environment. The SOAP implementation used was the Apache SOAPversion 2.3.1. In this implementation for the Java language, a call object is created. A method name isset and parameters are subsequently assigned to the call object. The call is then invoked via a URL.If there is a return value, it is returned through the call object as a response. Failures are dealt with bythe throwing of SOAPException which must be caught by the client.

The example focused on passing complex and nested objects, arrays of complex objects, and arraysof nested objects between the client and server. The server-side classes in SOAP-RPC are plain Javaclass files that do not require SOAP-RPC-specific code. The server class methods that need to beavailable for remote calls were implemented. The web server is started at a location such that ithas access to the server classes. The server class methods are deployed on the web server using adeployment descriptor file.

Client classes in the MTD were created without considering SOAP-RPC concerns. A SOAP-RPCaspect that implements a method with the same name as that needed to make the remote call was



StockBrokerService<<interface>>

Lease

UnknownLeaseException

lease

Activation

Activatable ActivationException

ActivationID

ActivationDesc

ActivationGroup

ActivationGroupID

ActivationGroupDescDiscoveryListener

LookupDiscovery

DiscoveryEvents

<<interface>>

discovery


Serializable

Runnable

BrokerProxy

Remote

run()renewLeases()computeSleepTime()createProxy():StockBrokerInterfaceregisterWithLookup(ServiceRegistrar)discarded(DiscoveryEvent)discovered(DiscoveryEvent)constructorProxy(String)

codebase:Stringregistrations:Hashtabledisco:LookupDiscoveryitem:ServiceItemLEASE_TIME:int

UnicastRemoteObject

RemoteException

RMISecurityManager

MarshalledObject

Stock

Remote

StockHolder

Authorization

ActivatableBroker

ServiceItem

<<interface>>ServiceRegistration

<<interface>>ServiceRegistrar

Lookup

BrokerInerface

Remote

Figure 7. Jini StockBroker PSM.

public aspect ExceptionHandler{pointcut forAllMethods():execution(* *(..));after() throwing (RemoteException e): forAllMethods(){

System.out.println("In Remote Exception Handler: " + e);}

}

Figure 8. Handling remote exceptions in Java RMI.



public aspect CartImplAspect{declare parents: CartImpl extends UnicastRemoteObject;declare parents: CartImpl implements Cart, Serializable;public static void CartImpl.main(String[] args) {

String name;if(System.getSecurityManager() == null) {

System.setSecurityManager(new RMISecurityManager());System.out.println("Security Manager installed");

}try {

CartImpl cartObj = new CartImpl();// the host and port are obtained from the command linename = "rmi://"+args[0]+":"+args[1]+"/"+"CartServer";Naming.rebind(name, cartObj);System.out.println("CartServer bound in Registry);

} catch (Exception e) {System.out.println("CartImpl err:" + e.getMessage());e.printStateTrace();

}}

}

Figure 9. Server-side aspect for UnicastRemoteObject.

also created. Unlike the aspects used in the previous example, the client-side aspect used in thisexample is application specific. The aspect consisted of code for creating the appropriate methodparameters, setting the method name, performing the method invocation and catching the responseand any generated exceptions. The client code (i.e. the MTD class) is woven with the aspect code usingthe AspectJ compiler.

In another SOAP-RPC development example, the client-side aspect was made generic so that itcould be reused for other SOAP-RPC applications. An XML Schema Definition document (XSD) thatcontained information relevant to a remote method call was developed. The information included thefollowing:

• server host name;• target object URI;• method name;• argument names, data types and serializers;• return data type, return name and serializers;• nested object names, data types and serializers.

The XSD is not specific to any application in particular. Parts of the XSD (MethodMappingsType, ArgumentType and NestedObjectType) in Figure 11 are presented. The ReturnTypedefinition is similar to the ArgumentType definition. An argument class may be a user-definedclass, and it may have another user-defined class nested in it. The NestedObjectsType class in



public aspect SetupAspect {public static void Setup.main(String args[]) throws Exception {

if(System.getSecurityManager() == null) {System.setSecurityManager(new RMISecurityManager());System.out.println("Security Manager installed");

}Properties props = new Properties();props.put("java.security.policy", "java.policy");ActivationGroupDesc.CommandEnvironment ace = null;ActivationGroupDesc exampleGroup =

new ActivationGroupDesc(props, ace);ActivationGroupId agi =

ActivationGroup.getSystem().registerGroup(exampleGroup);String location = "file:/s/chopin/k/grad/roopaps/");MarshalledObject data = null;ActivationDesc desc = new ActivationDesc (agi,

"Activate.ActivatableHelloImpl", location, data);ActivatableHello obj =

(ActivatableHello)Activatable.register(desc);System.out.println("Got the stub for the

Activatable implementation");Naming.rebind("Activatable Implementation", obj);System.out.println("Exports ActivatableImplementation");System.exit(0);

}}

Figure 10. Server side aspect for Activatable object.

the argument’s definition represents nested objects in the argument. A nested object could containone or more nested objects. For applications with customized serializers for exchanging user-defineddatatypes, the customized serializer name replaces the serializer value in the schema and has a returnnested object type.

The MTD is described by an application-specific XML file that conforms to the XSD.An application-specific SOAP-RPC aspect file (an MSD) can be automatically generated using theJava Architecture for XML Binding (JAXB)§ and the XML file describing the MTD.

7. .NET CASE STUDY

The .Net platform supports multiple languages through the use of the common language runtime(CLR) that is capable of just-in-time (JIT) compiling and executing code in the Microsoft IntermediateLanguage. .Net provides several infrastructures to implement distributed applications, such as XML

§See http://java.sun.com/xml/jaxb.



<xsd:complexType name="MethodMappingsType"><xsd:sequence><xsd:element name="clientMethod" type="xsd:string"/><xsd:element name="remoteMethod" type="xsd:string"/><xsd:element name="serverHost" type="xsd:string"/><xsd:element name="targetObjectURI" type="xsd:string"/><xsd:element name="arguments" type="argumentType" maxOccurs="unbounded"/><xsd:element name="returnObject" type="returnObjectType"/>

</xsd:sequence></xsd:complexType>

<xsd:complexType name="argumentType"><xsd:sequence><xsd:element name="argumentName" type="xsd:string"/><xsd:element name="argumentClass" type="xsd:string"/><xsd:element name="serializer" type="xsd:string"/><xsd:element name="nestedObjects" type="nestedObjectType" minOccurs="0"

maxOccurs="unbounded"/></xsd:sequence>

</xsd:complexType>

<xsd:complexType name="nestedObjectType"><xsd:sequence><xsd:element name="nestedObjectName" type="xsd:string"/><xsd:element name="nestedObjectClass" type="xsd:string"/><xsd:element name="serializer" type="xsd:string"/><xsd:element name="nestedObjects" type="nestedObjectType" minOccurs="0"

maxOccurs="unbounded"/></xsd:sequence>

</xsd:complexType>

Figure 11. Schema definitions for generic SOAP aspect.

Web services using ASP.Net technology and .Net remoting. It also provides RMI capabilities, andservices such as lifetime management and activation, and allows objects across the application domainto interact. A leasing interface is used for remote object lifetime management. The frameworksupports the notion of remote objects, proxy objects, and remote object activation. It providescommunication channels that can serialize and deserialize objects when they are sent across applicationdomains.

C# was chosen as the language to implement the distributed application. Two techniques wereexplored for implementing cross-cutting communication functionality as aspects. In the first technique,the .Net remoting features such as message-sink chains associated with context-bound objects wereused. The application domain is divided into contexts that each contain one or more objects. In across-context method call, the call is intercepted by a message-sink chain. Message sinks allowhooking up of extra functionality before or after executing a certain method on a context-bound object.



Adding functionality through message sinks meant that this functionality would be called only whencross-context methods were called.

There are some problems with this approach. To implement a remoting server that starts up andimmediately attempts to register, one would need to have an outside object make a method call to forcethe sinks to execute the code for registration. Moreover, message sinks also require certain specificclasses to be extended. Such a solution has restricted flexibility.

The second technique used the Aspect/C# language to implement aspects. Aspect/C# providescapabilities for introduction, and before, after, and around advice. An XML deployment descriptordocument is used to weave aspect code into core classes. The descriptor file specifies the basedirectories for aspect code and core class files. The descriptor maps methods of aspect classes tomethods of core classes.

The code that handles remoting as methods in the aspect classes was extracted. Thesemethods are appropriately woven into the server and client core classes using the Aspect/C#deployment descriptor and Aspect/C# compiler. Another task is to extend the remote class bythe System.MarshallByRefObject class. Suppose the remote class is called Rem. A newRemWrapper was defined that inherits from System.MarshallByRefObject. The new classcreates and encapsulates an object of the class Rem. The remoting server registers the classRemWrapper instead of Rem with the remoting framework.

A Calculator application is used to illustrate middleware-transparent development of .Netapplications. The server side of the application consists of the following classes:

1. CalcServer class: contains the main() method in which the server waits for the client classto connect.

2. ICalculator interface: defines the add() and multiply() methods.3. Calculator class: implements the ICalculator interface and provides the remote object.4. CalculatorWrapper class: encapsulates the Calculator object, inherits from the

System.MarshallByRefObject and implements ICalculator.5. CalcServerAspect class: defines the server-side aspect. The Connect method carries

out the server-side remoting operations, for example, creating the TCPChannel for the server.The activation method used here is the Singleton method.

6. MySponsor class: acts as the sponsor for the lease of the CalculatorWrapper object.

The client side has the following classes:

1. CalcClient class: defines a main() method that prompts users for values.2. CalcClientAspect class: defines a method called Connect() that supplies the code to

register a TCPChannel for the client application. It activates a CalculatorWrapper objecton the server. It does not specify the CalculatorWrapper class name; instead it attempts toactivate an object that implements ICalculator.

3. ICalculator: same as the server-side interface.

It would seem that the wrapper class can be eliminated by having the aspect force the requiredinheritance. However, if the remote class inherits from another application class, this would become aproblem because multiple inheritance is not supported by the programming language.



8. ISSUES AND OPEN QUESTIONS

In the previous sections it was shown that middleware components can be isolated from the businessfunctionality and transparently integrated into a distributed application. This allows one to more easilychange pervasive middleware functionality. The following paragraphs present a discussion of thelessons learned and the issues that need to be addressed in future.

8.1. Aspects

An aspect captures the minimal structure and behavior expected from a certain middleware feature asa pattern. In some cases, this is not sufficient to support MTSD. For example, when error handlingis performed, the catching of the exception and the actions taken to handle the error may differfrom one application to another. The developer is required to add the application-specific code eitherto the aspect or to the code produced by the weaver. This problem was experienced in the workon CORBA transactions [33]. The behavior of operations such as commit and rollback can dependon the type of transactional resource and object, as well as the desired behavior from the point ofview of the application developer. User-defined exceptions that need to be raised and handled bya transactional service method in an aspect are obtained from the IDL specification of the method.Specific CORBA exceptions that have to be handled in the aspect are specified by the applicationdeveloper. The application developer also defines the exception-handling behavior.

The code-aspects used in the examples are specific to Java or C#. However, one can implementthe functionality described by aspects using models which can then be transformed to appropriateprogramming languages. An approach for describing aspects using models is presented in Section 9.Techniques for incorporating application-specific behavior into design aspect models or woven modelsare also being investigated.

8.2. Converters

Ideally one should be able to weave an aspect with an MTD without the need to refactor or convert theMTD. In practice, an MTD may not have the architectural properties needed to weave the MTD and anaspect. For example, to use CORBA, several classes (e.g., skeletons and adapters) need to be generatedfrom a service interface. It is unlikely that the MTD will have such classes. In Java RMI, the stub classis generated, but in Jini, a proxy class implemented by the application developer is needed.

As AOP languages mature, it may be possible to use them to perform some tasks currently doneby converters. For example, AspectJ 1.0 did not contain mechanisms to extend classes. However, thecurrent version of AspectJ does, and thus this functionality does not have to be included in a converter.Other tasks such as the introduction of inner classes are still not supported by AspectJ and must bedone by the converters.

In addition, there are some tasks that are beyond the scope of an AOP language. For example,when an application developer creates a service, it is unlikely that a proxy class for the service will beincluded as this is often created by the target technology (e.g., Jini). In the MTSD approach, the proxyclasses are introduced by converters. This is necessary in cases where the target technology assumestheir existence. The creation of proxy classes, their methods, and data items is normally beyond thescope of an AOP language because this requires the creation of new classes, not just modifications



to existing ones. The creation of CORBA IDL definitions from Java interfaces is another example offunctionality that is beyond the capability of AOP languages.

The converters used in this paper are language and middleware specific. It is anticipated that vendorsthat provide middleware aspects will also provide converters. If there is a standard set of enhancementsfor every middleware technology, the converters will only need to be changed when the technologyevolves or when the target programming language changes.

A vendor that develops middleware aspects and converters will need to make assumptions about theMTD architecture. This may require the application developer to follow guidelines in developing anMTD that can be converted and composed with the aspects.

8.3. Scalability

The approach was applied to relatively small case studies where the business functionality was changedwithout changing the middleware features, or new middleware features were added to an application.This experience indicates that the steps that are likely to be affected by changing functionality are(1) the enhancements required (or implemented by the converter), and (2) the specification of pointcutsin the aspects. For example, changing business requirements may necessitate a change in the MTDarchitecture, which in turn necessitates changes to the types of conversions implemented in a converter.When new functionality is added to the MTD implementation, the application developer may need toadd new pointcuts to the aspects. For example, if a new operation, foo(), requires authorization, theauthorization aspect code will need to be woven with foo(). A new pointcut for foo() must beadded to the authorization aspect.

The question as to which middleware features are amenable to aspect treatment is currently beinginvestigated. In Jini, the proxy class is created after developing a converter for that purpose. In CORBA,the security and transaction features that were captured as aspects required enhancements involving thegeneration of CORBA files associated with the service interface. The enhancement was performed byfirst generating the CORBA IDL interface from a Java interface using the rmic tool, and then runningthe CORBA IDL compiler. Thus, the enhancements for CORBA were performed using availablesoftware, whereas a converter needed to be implemented for Jini.

8.4. Component-based approaches versus MTSD

Container-based technologies, such as Enterprise JavaBeans (EJB) [34] and real-time CORBAComponent Model (CCM) with CIAO [35], are designed to enable the development of scalable, secure,multiplatform applications. The goal is to allow developers to write only the business logic of anapplication, while the supporting infrastructural services are provided by the container. Containerstypically provide such services as security and distributed transactions. Thus, containers insulate thedeveloper from the underlying middleware. Containers provide glue-code-generation services that aretransparent to developers. Glue code is used to integrate different parts of an application code to formthe complete system. In MTSD, glue code is provided by the aspects.

MTSD removes a number of inherent weaknesses in component-based approaches, and thereforecomplements the approaches. Component-based approaches customize the generic business logicby adding ‘plumbing code’ specific to the component technology. For example, an EJB server-side component requires the use of specific packages and the implementation of specific interfaces.



These packages and interfaces differ from one component-based technology to another. As a result, adeveloper wishing to change to a new or different component-based technology must remove scatteredand tangled code from applications. MTSD is designed to address these problems.

Middleware features provided as components can be incorporated into the application using aspectswith the additional advantage of being able to specify precedence (ordering) among the aspects.When multiple aspects are used in an application, different weaving strategies may be necessary toselect appropriate mechanisms and ordering of aspects to ensure correct emergent behavior. Using theMTSD approach, weaving strategies can be changed without having to modify either the primary model(code) or the middleware features.

An advantage of component-based approaches is that services can be incorporated at run-time usingthe component container. Once run-time weaving becomes available in AspectJ, it will be possible toweave in services at run-time using the MTSD approach.

9. TOWARDS A MIDDLEWARE-TRANSPARENT DESIGN MODELING APPROACH

The examples given in the previous sections illustrate that it is possible to isolate functionalmiddleware design concerns in aspects that can be mechanically composed with middleware-independent application designs at the code level. Current aspect-oriented programming languagescan limit the type of middleware features that can be captured by code-level aspects. For example,AspectJ at the time of the reported work did not support inner classes required for lease management.It is expected that some of the limitations will be removed as the languages evolve, but the code-basedapproach to aspect-oriented software development will always be limited by the types of join-pointsthat can be used for weaving in new code. These limitations are almost non-existent at the designmodeling level because of the rich abstractions supported by modeling languages. There will still belimitations arising from use of specific modeling languages, but it is more likely that the abstractionscan be used to localize a larger set of cross-cutting functionality.

Code-level aspects also tend to be highly coupled to the application being developed. For example,a connectivity aspect written for a distributed currency converter application would have to besignificantly changed to work with a distributed supermarket-management application even thoughboth are Jini applications. The coupling arises out of a need for the aspect to know the names andattributes of several application classes. Although customized aspects can be written for every newapplication, reuse of the aspects in different Jini applications is limited because of the inability todescribe generic aspects that can be instantiated for (or mapped to) different Jini applications. In theexamples presented in this paper, this limitation was addressed by introducing additional mechanismsnot typically found in AOP development environments. For example, in the Jini example a tool wasdeveloped for renaming elements in generic Jini aspects to make them application specific, and in oneof the SOAP-RPC examples an XSD was used to describe generic aspects. Language-specific aspectsneed to be written which make it appear that the approach is tied to a particular programming language.

These observations lead to the step of raising the level of abstraction at which aspects and MTDsare described. The objective was to develop support for defining aspects that can be reused acrossdifferent applications and that can be used to support MDA. An MDA approach has been developedin which a PIM describes a MTD, aspects describe middleware-specific design patterns, and a PSM isproduced by incorporating aspects into a PIM. The approach requires that aspect (pattern) elements be



AspectModel 2

MiddlewareAspect

Model n...

Context specific

Generic Generic Generic

STEP 1BindingPIM (MTD)

Context specificMiddleware

AspectModel 1

...MiddlewareAspect

Model 2

Middleware


AspectModel n

Middleware

Model 1

Aspect

Figure 12. Generic and context-specific middleware aspects.

bound to application-specific elements before composition with the PIM. The binding is defined by theapplication developer. The result of binding elements in an aspect is called a context-specific aspect.

Middleware experts isolate and model the middleware-specific concerns as aspects. Applicationdevelopers create a PIM describing an MTD and define bindings used to produce context-specificaspects. Tools are used to weave the context-specific aspects with the PIM to produce the PSM.

9.1. Middleware-transparent modeling

The design approach is illustrated in Figures 12 and 13. In Figure 12, the PIM describes the MTDin terms of UML diagrams (e.g., class and sequence diagrams). A generic middleware aspect modeldescribes middleware-specific design patterns. The aspect model is generic in that it can be applied tomultiple PIMs.

Figure 14 illustrates the binding and composition process using a CurrencyConverter application.The PIM (see Figure 14(a)) contains a Java server class called CurrencyConvertServer thatimplements an interface called CurrencyConvertInterface. This interface has a method called floatconvert(float amt, String currency) for converting currencies. The Java client classCurrencyConvertClient invokes methods on the server. Generic aspects are described using a languagefor creating parameterized forms of UML diagrams (called diagram templates) [36–39]. The genericaspect model for Java RMI specifies a generic server interface that extends the special Java interfaceRemote. As part of the binding process, the generic server interface needs to be bound to the PIM’sCurrencyConvertInterface (see Figure 14(b)).



MiddlewareAspect

Model n

Composition

Implement

Application

STEP 2

STEP 3


AspectModel 1

Context specific...

PIM (MTD)

PSM (MSD)

Implemented


AspectModel 2

STEP 2

Application

Aspect Compiler

Aspect nCode

Aspect 2Code

Aspect 1Code

Implement Implement...

Implement

Model 2

STEP 3

Model nAspect

MiddlewareContext specificContext specific

Model 1Aspect

MiddlewareContext specific

MTD

Implemented

of PIMImplementation

Implement

AspectMiddleware

...

(a) (b)

Figure 13. Application of design-level middleware aspects: (a) first compose and then implement;(b) first implement and then weave.

The context-specific aspect shown in Figure 14(b) is composed with the PIM to produce a PSM(see Figure 14(c)) containing the CurrencyConvertServer and CurrencyConvertClient classes, and theCurrencyConvertInterface and Remote interfaces with the appropriate associations.

Developing an aspect-oriented design consisting of middleware aspects and a PIM describing anMTD involves the following activities:

1. Identify types of middleware services that can be represented as design aspects.2. Specify middleware-specific design patterns (i.e. create generic middleware aspects).3. Produce context-specific aspects and compose them with the PIM.

9.1.1. Identifying middleware aspects

Middleware aspects can be identified at different levels of abstraction. During development, designs arerefined, where each refinement adds details previously abstracted in the design descriptions. Each levelof detail presents opportunities for identifying middleware functionality that can be isolated in aspects.In some cases, the additional detail can be handled by refining aspects defined at higher levels ofabstraction. In other cases, new aspects are introduced.



convert(float amt, String currency)

CurrencyConvertInterface

<<interface>>

CurrencyConvertServer

CurrencyConvertClient

uses

<<interface>>

Remote

Currency Converter PIM

Generic Aspect

<<ClassTemplate>>|GenericServerInterface

(a)

CurrencyConvertInterface

<<interface>> <<interface>>

Remote

uses

convert(float amt, String currency)

Remote<<interface>>

<<GenericServerImplementation>>CurrencyConvertServer

<<GenericServerInterface>>CurrencyConvertInterface

(b)

CurrencyConvertClient

(c)

Figure 14. Illustration of a currency-converter application: (a) currency converter PIM and generic aspect;(b) context-specific aspect; and (c) currency converter PSM.

9.1.2. Developing generic aspects

Generic aspect models describe middleware-specific design patterns in terms of template formsof UML class diagrams and interaction diagrams [36–40]. These pattern specifications defineconstrained forms of the UML metamodel that specify UML models that conform to the patterns.Binding application-specific elements to template parameters in a generic aspect produces UMLdiagrams that describe how the middleware functionality is realized in the application. These diagramsare collectively called the context-specific aspect model.

9.1.3. Composing aspects and a PIM

The PIM and the context-specific aspects of an aspect-oriented design are views of a design. The PIMdescribes the MTD view of the design and the context-specific aspects describe middleware service



views of the design. Composing them results in an integrated view of the design. Composition involvesmerging the elements in the views. Currently, the approach is limited to name-based merging ofelements: elements with the same syntactic type and name (or signature in the case of operationsand attributes) are merged.

The result of merging views can produce an inconsistent model. For this reason, techniquesfor identifying inconsistencies during or after composition are needed [29]. Once identified, theinconsistencies must be resolved. The technique allows one to specify composition directives that canbe used to resolve conflicts [29,30]. Composition directives can be used to refactor diagrams; that is, toremove or add structures in diagrams. In some cases, resolving conflicts using composition directivesmay be impractical because of the extensive changes needed. In these cases the developer may have toconsider doing a redesign of the MTD or using different aspects.

9.2. Implementing aspect-oriented designs

Figure 13 describes two approaches to implementing aspect-oriented designs. The previous discussionwas based on the approach illustrated in Figure 13(a). In that approach context-specific aspects arecomposed with the PIM to produce a PSM that is then implemented in code, possibly with the help ofcode generators.

An alternative approach is presented in Figure 13(b), where the PIM is implemented as is in codeand the context-specific aspects are directly implemented as code aspects. The weaving is done at thecoding level rather than at the modeling level. In the Currency Converter example, this could involvewriting an AspectJ aspect that would effectively declare the interface CurrencyConvertInterface withthe extends Remote clause using the following AspectJ notation:

declare parents:CurrencyConverterInterfaceextends Remote;

A problem with this approach is that it may not always be possible to directly implement an aspectmodel as an aspect in a programming language. However, the advantage is that one can transform thecontext-specific aspect model to any aspect language (Java / C#) so long as appropriate constructs existin the aspect language and the transformations can be specified using a combination of these constructs.This work has been reported in Kamalakar [33].

10. CONCLUSION AND FUTURE WORK

A middleware-transparent approach that uses aspect-oriented development techniques to decouplebusiness functionality from the specifics of the middleware technologies was presented. The approachwas illustrated at the code level through Java RMI, Jini, .Net and SOAP-RPC examples. While theexamples presented in the paper are code-based, a proposal to raise the level of abstraction and usemiddleware-transparent design models along with aspect models was presented. This proposal supportsmodel-based development and, consequently, the MDA initiative.



Use of the approach can reduce the effort needed to evolve distributed applications when changeis triggered by changes in middleware platforms. The approach was applied to relatively small casestudies. In future, large systems that change over a period of time will be used to investigate thescalability of the approach.

Work is being done using several middleware technologies to identify what features can and cannotbe practically isolated as aspects. An evaluation is being performed to identify which aspects are bestspecified and composed at the modeling level, and which ones at the code level. The approach willbe applied to aspectualize pluggable protocol frameworks for interoperability with new middlewaretechnologies.

Techniques are being developed that can be used for composing aspect-oriented design models.Static and dynamic analysis techniques are being developed to identify inconsistencies and otherdesign problems in models and code resulting from the weaving of middleware aspects with MTDs.The impact of using an aspect-oriented approach on the maintenance of middleware-based applicationswill be evaluated.

REFERENCES

1. OMG—The Object Management Group. Common Object Request Broker Architecture, CORBA/IIOP 2.6, 2002.2. Microsoft Inc. Component Object Model (COM) Web site. http://www.microsoft.com/com/.3. Waldo J. Alive and well: Jini technology today. IEEE Computer 2000; 33(6):107–109.4. Microsoft Corporation. .Net. http://www.microsoft.com/net/ [2003].5. W3C. Simple Object Access Protocol (SOAP). http://www.w3.org/TR/SOAP/ [2003].6. The Object Management Group. The Unified Modeling Language. Version 1.4, OMG, formal/2001-09-67, 2001.7. Bergmans L, Aksit M. Composing multiple concerns using composition filters. Communications of the ACM 2001;

44(10):51–57.8. Kiczales G, Hilsdale E, Hugunin J, Kersten M, Palm J, Griswold WG. Getting started with AspectJ. Communications of

the ACM 2001; 44(10):59–65.9. Kiczales G, Hilsdale E, Hugunin J, Kersten M, Palm J, Griswold WG. An overview of AspectJ. Proceedings of the

European Conference on Object-Oriented Programming (ECOOP’01), Budapest, Hungary, June 2001. Springer: London,2001; 327–353.

10. Kiczales G, Lamping J, Mendhekar A, Maeda C, Lopes CV, Loingtier J-M, Irwin J. Aspect-oriented programming.Proceedings of the European Conference on Object-Oriented Programming (ECOOP’97), Jyvaskyla, Finland, June 1997(Lecture Notes in Computer Science, vol. 1241). Springer: Berlin, 1997; 220–242.

11. Kieberherr K, Orleans D, Ovlinger J. Aspect-oriented programming with adaptive methods. Communications of the ACM2001; 44(10):39–41.

12. Ossher H, Tarr P. Using multidimensional separation of concerns to (re)shape evolving software. Communications of theACM 2001; 44(10):43–50.

13. Pace JAD, Campo MR. Analyzing the role of aspects in software design. Communications of the ACM 2001; 44(10):66–73.14. Silva AR. Separation and composition of overlapping and interacting concerns. OOPSLA’99 First Workshop on

Multi-Dimensional Separation of Concerns in Object-Oriented Systems, Denver, CO, November 1999. Available at:http://www.cs.ubc.ca/∼murphy/multid-workshop-oopsla99/.

15. Sullivan GT. Aspect-oriented programming using reflection and metaobject protocols. Communications of the ACM 2001;44(10):95–97.

16. Bussard L. Towards a pragmatic composition model of CORBA services based on AspectJ. Proceedings of ECOOP2000 Workshop on Aspects and Dimensions of Concerns, Sophia Antipolis and Cannes, France, June 2000. Available at:http://amidst.ctit.utwente.nl/publications/ecoop adc2000 workshop report.pdf.

17. Hunleth F, Cytron R, Gill C. Building customizable middleware using aspect oriented programming. OOPSLAWorkshop on Advanced Separation of Concerns in Object-Oriented Systems, Tampa, FL, October 2001. Available at:http://www.cs.ubc.ca/∼kdvolder/Workshops/OOPSLA2001/submissions/01-hunleth.pdf.

18. Clarke S, Harrison W, Ossher H, Tarr P. Separating concerns throughout the development lifecycle. Proceedings of the3rd ECOOP Aspect-Oriented Programming Workshop, Lisbon, Portugal, June 1999 (Lecture Notes in Computer Science,vol. 1743). Springer: London, 1999.



19. Clarke S, Murphy J. Developing a tool to support the application of aspect-oriented programming principles to the designphase. Proceedings of the Aspect-Oriented Programming Workshop at ICSE 1998, Kyoto, Japan, April 1998. Available at:http://www2.parc.com/csl/projects/aop/workshops/icse98/aop-icse98-proceedings.pdf.

20. Fiadeiro JL, Lopes A. Algebraic semantics of co-ordination or what is it in a signature? Proceedings of the 7th InternationalConference on Algebraic Methodology and Software Technology (AMAST’98), Amazonia, Brasil, January 1999 (LectureNotes in Computer Science, vol. 1548), Haeberer A (ed.). Springer: London, 1999; 293–307.

21. Gray J, Bapty T, Neema S, Tuck J. Handling crosscutting constraints in domain-specific modeling. Communications of theACM 2002; 44(10):87–93.

22. Rashid A. A hybrid approach to separation of concerns: The story of SADES. Proceedings of the 3rd InternationalConference on Meta-Level Architectures and Separation of Concerns (Reflection), Kyoto, Japan, 25–28 September 2001(Lecture Notes in Computer Science, vol. 2192). Springer: London, 2001.

23. Rashid A, Moreira A, Araujo J. Modularization and composition of aspectual requirements. Proceedings of the 2ndInternational Conference on Aspect-Oriented Software Development, ACM, Boston, MA, March 2003. ACM Press:New York, 2003; 11–20.

24. Rashid A, Sawyer P, Moreira A, Araujo J. Early aspects: A model for aspect-oriented requirements engineering.Proceedings of the IEEE Joint International Conference on Requirements Engineering, Essen, 9–13 September 2002.IEEE Computer Society Press: Washington, DC, 2002; 199–202.

25. Suzuki J, Yamamoto Y. Extending UML with aspects: Aspect support in the design phase. Proceedings of the 3rd ECOOPAspect-Oriented Programming Workshop, Lisbon, Portugal, June 1999 (Lecture Notes in Computer Science, vol. 1743).Springer: London, 1999.

26. Roman M, Kon F, Campbell RH. Universally Interoperable Core: A platform for the construction of domain specificmiddleware implementations. http://www.ubi-core.com/ [2004].

27. Pichler R, Ostermann K, Mezini M. On aspectualizing component models. Software Practice and Experience 2003;33(10):957–974.

28. France R, Georg G. Modeling fault tolerant concerns using aspects. Technical Report 02-102, Computer ScienceDepartment, Colorado State University, 2002.

29. Georg G, Ray I, France R. Using aspects to design a secure system. Proceedings of the International Conference onEngineering Complex Computing Systems (ICECCS 2002), Greenbelt, MD, December 2002. IEEE Computer SocietyPress: Washington, DC, 2002.

30. Georg G, France R, Ray I. An aspect-based approach to modeling security concerns. Proceedings of the Workshop onCritical Systems Development with UML, Dresden, Germany, 2002. Available at:http://www4.in.tum.de/∼csduml02/abstracts.html.

31. Georg G, France R, Ray I. Designing high integrity systems using Aspects. Proceedings of the Fifth IFIP TC-11 WG 11.5Working Conference on Integrity and Internal Control in Information Systems (IICIS 2002), Bonn, Germany, November2002. Kluwer Academic: Norwell, MA, 2003.

32. Palsberg J. JTB: Java Tree Builder. http://www.cs.purdue.edu/jtb/.33. Kamalakar B. Aspect-oriented development of CORBA-based applications. Masters Thesis (in preparation), Department

of Computer Science, Colorado State University, Fort Collins, CO, 2004.34. Sun Microsystem. Entity Java Bean EJB. http://java.sun.com/products/ejb/ [2003].35. Distributed Object Computing (DOC) Group. Real-time CCM with CIAO.

http://www.cs.wustl.edu/∼schmidt/CIAO.html [2004].36. France RB, Kim DK, Song E, Ghosh S. Using roles to characterize model families. Practical Foundations of Business and

System Specifications, Kilov H (ed.). Kluwer Academic: Norwell, MA, 2003.37. France RB, Ray I, Georg G, Ghosh S. An aspect-oriented approach to design modeling. IEE Proceedings–Software, Special

Issue on Early Aspects, Aspect-Oriented Requirements Engineering and Architectural Design 2004; 151(4):173–185.38. Kim DK, France RB, Ghosh S, Song E. Using role-based modeling language (RBML) as precise characterizations of model

families. Proceedings of the 8th IEEE International Conference on Engineering of Complex Computer Systems (ICECCS),Greenbelt, MD, December 2002. IEEE Computer Society Press: Washington, DC, 2002.

39. Kim DK, France RB, Ghosh S, Song E. A role-based metamodeling approach to specifying design patterns. Proceedingsof the 27th Annual International Conference on Computer Software and Applications, Dallas, TX, November 2003. IEEEComputer Society Press: Washington, DC, 2003; 452–457.

40. France RB, Ghosh S, Song E, Kim DK. A metamodeling approach to pattern-based model refactoring. IEEE SoftwareSpecial Issue on Model-Driven Development 2003; 20(5):52–58.


Documents

A middleware-transparent approach to developing distributed applications