A Middleware Transparent Approach to Developing Distributed
Applications
Sudipto Ghosh, Robert B. France, Devon M. Simmonds, Abhijit Bare, Brahmila Kamalakar, Roopashree P. Shankar,
Gagan Tandon, Peter Vile, Shuxin Yin Computer Science Department
Colorado State University Fort Collins, CO 80523 Phone: (970) 491-4608 Fax: (970) 491-2466
Email: ghosh,france,simmonds,abhijit,brahmila,roopaps,gagan,vile,yin @cs.colostate.edu November 9, 2004
Summary
An innovativemiddleware transparentapproach to developing distributed applications is presented. The
approach uses an aspect-oriented software development technique to separate an application’s middleware-independent functionality from its middleware-specific functionality. Application elements that are specific to the middleware are localized in aspects that can be seamlessly integrated into middleware-independent application designs. The middleware transparent approach is used to decouple business functionality from middleware-specific functionality. The decoupling allows developers to change mid-dleware application elements without significantly modifying business functionality. Midmid-dleware tech-nologies such as Java RMI, Jini, SOAP-RPC and .Net are used as examples to illustrate the approach.
Keywords:aspect-oriented programming, distributed applications, Java RMI, Jini, middleware tech-nologies, SOAP-RPC, .Net.
1 Introduction
The rapid evolution of the Internet and network technologies is making distributed systems the norm for
modern business applications. In a distributed system, themiddlewareis a layer of software between
ap-plications and the network they run upon. Middleware technologies, for example, CORBA [1], COM [2], Jini [3], .Net [4] and SOAP [5], provide high-level programming abstractions that enable remote method invocations over underlying networks of heterogeneous platforms. They also provide services such as naming, trading, and messaging, and quality of service features such as security and fault tolerance.
Middleware functionality is crosscutting in that it is pervasive and is tangled with business-specific functionality in distributed applications. Middleware services (e.g., security), may also crosscut other middleware features (e.g., event services and transactions). Middleware services are sometimes encap-sulated as components. However, to use the services, the business-specific design must include calls to services at appropriate locations in the design and must ensure appropriate ordering of services (e.g., per-forming authentication before authorization). The crosscutting nature makes changing the middleware of distributed applications risky and challenging.
This paper presents amiddleware transparent approach to the development of distributed
applica-tions that allows architects to design business functionality without considering the middleware that will provide transparent access to remote resources. The approach uses an aspect-oriented technique to de-couple business functionality from middleware concerns. Middleware-specific application elements are localized in aspects that can be seamlessly integrated (or woven) into an application design describ-ing core business functionality. The localization of crosscuttdescrib-ing middleware concerns 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) lan-guage, such as AspectJ, or to designs expressed in a modeling language such as the Unified Modeling Language (UML) [6]. The focus of this paper is on the use of the approach at the code level. An overview
of how the approach can be used to support model-driven development is given in Sections 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 new technologies. Software evolution is problematic when developers must adapt software systems to rapidly evolving technologies in order to maintain or enhance an organization’s effectiveness or competitive advantage. The problem is exacerbated when pervasive technology-specific functionality is 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 evolving dis-tributed systems. Aspects can be used to support such separation of concerns. Aspects at the code level can be described using an aspect oriented programming (AOP) language [7, 8, 9, 10, 11, 12, 13, 14, 15]. An AOP aspect is an implementation or design concern that cross-cuts the primary functional units of a program. Recent work examines the use of AOP to achieve middleware transparency. Bussard [16] en-capsulated several CORBA services as aspects using AspectJ to make CORBA programming transparent to programmers. Hunleth, Cytron, and Gill [17] suggest the creation of an AspectIDL for CORBA to complement the IDLs that are now available for languages such as Java and C++. Their proposed
As-pectIDL would support several new types of AspectJintroductions: 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 soft-ware development, but developers are finding it increasingly difficult to cope with the complexity of developing secure, fault-tolerant, highly available distributed software systems using only code level de-scriptions. The Model Driven Architecture (MDA) initiative recognizes the need for raising the level
of abstraction at which developers describe complex systems and advocates the use of model-centric approaches to development. MDA advocates separation of technology independent concerns from tech-nology specific concerns. A platform-independent model (PIM) describes the behavior of the application
“undistorted by the idiosyncrasies of the technology or technologies in which it will be implemented”1.
A platform specific model (PSM) describes an application in technology specific terms. A MDA de-sign consists of PIMs, PSMs and PIM to PSM mappings. The mappings, ideally implemented in tools, transform the PIMs to PSMs. Use of an MDA approach makes it unnecessary to repeat the process of modeling an application’s functionality and behavior each time a new implementation 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 (plat-form) functionality. A PSM is obtained by weaving aspects and a PIM. Researchers have started to address the problem of describing and using aspects at an abstraction level higher than the programming language level [18, 19, 20, 21, 22, 23, 24, 25]. In the aspect-oriented modeling approach proposed by
Clarke et al. [18, 19], a design called asubject is created for each system requirement. A
comprehen-sive 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 MIC initiative that targets embedded software systems. MIC extends the scope and usage of models such that they form the backbone of a development process for building embedded software systems. Requirements, architecture, and the environment of a system are captured in the form of formal high-level models that allow the representation of concerns. The middleware transparent approach can complement these and other aspect 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 a collec-tion 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 UIC was designed to address the needs of handheld devices that interact in distributed environments but have access to lim-ited resources. Most middleware implementations are customized for desktops and servers but not for handheld devices. This forces developers of these devices to implement customized solutions. However, customization eliminates the ability of handheld devices to interoperate with Internet-based distributed applications and to export their services to other applications. The UIC was designed to address these weaknesses. The UIC consists of a collection of abstract components that can be specialized for a spe-cific middleware, device, or network. Among the benefits of the UIC is dynamic configurability, that is, the ability to reconfigure the UIC at run-time using dynamically loadable and replaceable libraries of the UIC components. In the proposed approach, the middleware services may be provided as components. However, their use is encapsulated in the form of aspects. Pichler et al. [27] have shown how one can
aspectualizecomponent models.
The authors are not aware of any AOM approaches that specifically support middleware transparency. France, Ray, and Georg [28, 29] use template UML diagrams to describe aspects representing security concerns (e.g., see [30, 31, 29]). This paper adapts and enhances 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 multiple classes and methods in a distributed application. In client-server systems, client and service classes include middleware functionality that enables clients to access remote services in a transparent manner.
In peer-to-peer (P2P) applications, each peer has middleware functionality that enables it to transparently access other peers on the network.
Changing functionality that crosscuts a design can be difficult. Consider a scenario in which an application developer creates a distributed application consisting of a client and a remote service and that
uses a middleware platform that implements remote service discovery (finding and locating services)
and connectivity (establishing a connection to the services). Using current development techniques the
developer produces a design in which functionality is tangled with the business functionality. A
few months later, a new middleware platform that promises significant improvement in middleware
services arrives. A business decision is made to replace
by
. The tangling of
features and
business functionality across the design results in a costly and risky redesign of the entire application. In the previously described scenario, the required business functionality did not change, but the developer had to modify the parts of the design that address business functionality to accommodate the new middleware platform. One way to ease evolution of middleware-specific functionality in a distributed application is to isolate middleware functionality in aspects. This allows developers to create middleware transparent designs (MTDs), that is, designs that do not address middleware concerns. A MTD is composed with middleware aspects to produce a middleware-specific design (MSD). A MSD is a distributed application design that utilizes the middleware features implemented by the aspects.
The aspect-oriented approach is illustrated in Figure 1. Each middleware feature is localized in an
aspect,Middleware Aspect-i. The aspects are composed with the middleware transparent design (MTD)
that describes the business functionality of the client/service/peer system. In the context of MDA, a MTD expressed in a modeling language such as the UML is a PIM and the MSD produced by composing aspect models with the MTD is a PSM. At the code level, MTDs and aspects can be expressed in an aspect-oriented programming language such as AspectJ and the MSDs are the result of compiling the MTDs with aspects.
(MSD) Middleware−Specific Design Composer (MTD) Design Transparent ... Middlewareaspect − n aspect − 2 Middleware aspect − 1 Middleware Middleware−
Figure 1: Composing middleware aspects and a MTD.
Figure 2 illustrates how the aspect-oriented approach can ease evolution of a distributed
applica-tion’s middleware features. Features of the middleware platform are localized in the set of aspects
, and features are localized in the aspect set . Replacing the application’s
mid-dleware platform with a new platform involves producing a new MSD, , by composing
aspects in the set with !
. MSD2 application change middleware change Develop MTD Compose Middleware platform M1 MSD1 Compose Business Requirements MTD1 M1aspects Develop Aspects Middleware platform M2 Develop Aspects M2aspects
Figure 3 shows the aspect-oriented development framework used to support middleware transparent development of distributed applications. The framework provides support for composing MTDs and aspects to produce MSDs. Two types of aspects are supported: middleware functional aspects (MFAs), and quality of service aspects (QoSA). QoSAs localize quality of service (QoS) functionality and MFAs localize other middleware services. MFAs are used in the examples to illustrate the approach.
Aspect Weaver Converter
EMTD MTD
Aspects (MFA, QoSA)
MSD
Enhanced Aspects (EMFA, EQoSA)
Figure 3: An Aspect-Oriented Development Framework
Each MTD has a particular architectural signature (structure) consisting of a collection of interfaces, classes and relationships. A MTD may differ significantly from another MTD in its architectural sig-nature. Middleware aspects require that a design’s architectural signature have certain properties for
aspect weaving to be successful. A converter is used to incorporate these properties into a MTD. It
uses knowledge about the middleware aspects to add hooks into a MTD so that it can be mechanically composed with aspects. The enhanced MTD (EMTD) produced by a converter has the architectural sig-nature required by a middleware aspect. The conversion algorithm depends on the selected middleware service localized by an aspect (e.g., transaction) and the selected middleware technology (e.g., Jini). For a given middleware, different aspects will require different architectural signatures. 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 speci-fied in MTDs as that would make the MTDs platform specific. The conversion is not implemented in
the weaver (e.g., AspectJ) as this would make the weaver middleware specific. Specifying the transfor-mation in a separate component provides the flexibility and modularity needed to support separation of middleware specific from middleware independent concerns.
In the examples given in this paper the middleware aspects are specific to a middleware technology but are developed independently of any application. Before these aspects can be composed with an EMTD, the aspects may have to be modified. For example, some aspect elements may have to be renamed in order for them to work in an application context as desired. Converters are also used to convert aspects to context-specific forms (EMFAs EQoSAs) that can be mechanically composed with EMTDs.
The following three-stage design process can be used to create a distributed application in the frame-work. 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 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 each client 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, lease management,
and remote invocation of service methods. AspectJ was used to implement Jini aspects and Java for the application MTD. The client in the MTD contained code that invoked methods on an object representing the service. Functionality for discovering and connecting to the service were not included in the MTD. The service methods were implemented in the server code, but no lease management or proxy object creation code was written. When the aspects were woven with the 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 how the middleware transparent development approach can be used to develop a Jini compliant application that utilizes connectivity services in the middleware. The functional requirements of this application included providing clients the ability to register with the stock broker service, and to buy and sell stocks. The MTD was written in Java with AspectJ as the aspect language.
StockBrokerInterface <<interface>> <<realizes>> Authorization StockHolder Broker sell() buy() register()
Figure 4: Jini StockBroker MTD
The Jini converters and the MFA were developed as a one-time exercise. The MTD classes and inter-faces 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 PSM respectively. The specific activities that produced these models during the design phase are described below:
codebase:String registrations:Hashtable disco:LookupDiscovery item:ServiceItem LEASE_TIME:int UnicastRemoteObject RemoteException RMISecurityManager MarshalledObject ActivationGroupDesc ActivationGroupID ActivationGroup ActivationDesc ActivationID ActivationException Activatable Activation lease UnknownLeaseException constructorProxy(String) Remote ServerAspect discovery LookupDiscovey DiscoveyEvents DiscoveyListener <<interface>> ServiceItem ServiceRegistration <<interface>> ServiceRegistrar <<interface>> Lookup run() renewLeases() computeSleepTime() createProxy():StockBrokerInterface registerWithLookup(ServiceRegistrar) discarded(DiscoveryEvent) discovered(DiscoveryEvent) Lease <<interface>>
Figure 5: Jini StockBroker MFA
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 contains the signatures of operations that allow clients to register with a broker and to buy and sell stocks.
The class"$#&%(')*# implements the broker services declared in the interface. The MFA is shown in
Figure 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 captured in an inner class and that a proxy for this inner class
Broker StockHolder Authorization register buy sell StockBrokerService Runnable BrokerProxy RemoteStockBrokerInterface Remote Activatable Serializable StockBrokerInterface
Figure 6: Jini StockBroker EMTD
be created as well. The aspect converter implemented a simple string matching algorithm that replaces aspect class names and attributes with class names and attributes from the Stock Broker application. The application converter was written using the Java Tree Builder [32]. It generated the EMTD (see Figure 6) by refactoring the MTD to include seven new components all of which are required by Jini. The tasks performed by the application converter are as follows:
(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 and
StockBrokerService <<interface>> Lease UnknownLeaseException lease Activation Activatable ActivationException ActivationID ActivationDesc ActivationGroup ActivationGroupID ActivationGroupDesc DiscoveryListener LookupDiscovery DiscoveryEvents <<interface>> discovery StockBrokerInterface Serializable Runnable BrokerProxy Remote run() renewLeases() computeSleepTime() createProxy():StockBrokerInterface registerWithLookup(ServiceRegistrar) discarded(DiscoveryEvent) discovered(DiscoveryEvent) constructorProxy(String) codebase:String registrations:Hashtable disco:LookupDiscovery item:ServiceItem LEASE_TIME:int UnicastRemoteObject RemoteException RMISecurityManager MarshalledObject Stock− Remote StockHolder Authorization Activatable Broker ServiceItem <<interface>> ServiceRegistration <<interface>> ServiceRegistrar Lookup Broker− Inerface Remote−
Figure 7: Jini StockBroker PSM
a challenge: AspectJ is Java compatible but the composition mechanisms are limited to those provided by AspectJ. This is discussed further in Section 8.
This approach was repeated with several applications and middleware technologies such as Java RMI, SOAP-RPC, and .Net. Functionality pertaining to discovering services, connecting to services, and advertising services, were successfully implemented as code-level aspects. Other middleware features pertaining to transactions, group management, and quality of service concerns are part of the ongoing research project.
5 Java RMI Case Study
In Java-RMI, clients talk to servers by sending remote method invocations to remote objects. These
objects are created by servers by extending the UnicastRemoteObjectclass, or by extending the
Activatableclass. Servers register remote objects created by extending the
UnicastRemoteOb-ject with a registry service, called rmiregistry, using the Naming class that provides facilities for
binding, rebinding and unbinding. Clients look up services from the rmiregistry using the lookup
facilities provided in theNamingclass.
Servers create remoteactivatableobjects by extending theActivatableclass and register them
with thermiddaemon 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 uses Java RMI. An aspect that handles Remote Exceptions that occur in Java RMI was written in AspectJ (see Figure 8).
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.
Two aspects for the shopping cart that make the server side Java-RMI aware were also developed.
One aspect (Figure 9) was written for theUnicastRemoteObjecttype, and the other (Figure 10) for
theActivatabletype. Some client specific aspects were also written that support looking up remote
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 line name = "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.
6 SOAP-RPC Case Study
The Simple Object Access Protocol (SOAP) is a lightweight, XML-based communication protocol for exchanging information between applications in a distributed environment. The SOAP implementation used was the Apache SOAP version 2.3.1. In this implementation for the Java language, a call object is created. A method name is set 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 by the throwing of SOAPException which must be caught by the client.
The example focused on passing complex and nested objects, arrays of complex objects, and arrays of nested objects between the client and server. The server side classes in SOAP-RPC are plain Java class files that do not require SOAP-RPC specific code. The server class methods that need to be available for remote calls were implemented. The web server is started at a location such that it has access to the
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("Exportes ActivatableImplementation"); System.exit(0);
} }
Figure 10: Server side aspect for Activatable object.
server classes. The server class methods are deployed on the web server using a deployment descriptor file.
Client classes in the MTD were created without considering SOAP-RPC concerns. A SOAP-RPC aspect that implements a method with the same name as that needed to make the remote call was also created. Unlike the aspects used in the previous example, the client-side aspect used in this example is application specific. The aspect consisted of code for creating the appropriate method parameters, setting the method name, performing the method invocation and catching the response and any generated exceptions. The client code (i.e., the MTD class) is woven with the aspect code using the AspectJ
compiler.
In another SOAP-RPC development example, the client-side aspect was made generic so that it
could be reused for other SOAP-RPC applications. An XML Schema Definition document (XSD) that contained information relevant to a remote method call was developed. The information included the following:
1. Server host name 2. Target object URI 3. Method name
4. Argument names, data types and serializers 5. Return data type, return name and serializers 6. Nested object names, data types and serializers
The XSD is not specific to any application in particular. Parts of the XSD (MethodMappingsType,
ArgumentTypeandNestedObjectType) in Figure 11 are presented. TheReturnType
defini-tion is similar to theArgumentTypedefinition. An argument class may be a user-defined class, and
it may have another user-defined class nested in it. The NestedObjectsTypeclass in the
argu-ments definition represents nested objects in the argument. A nested object could contain one or more nested objects. For applications with customized serializers for exchanging user-defined datatypes, the customized serializer name replaces the serializer value in the schema and has a return nested 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 the Java Architecture for
XML binding (JAXB)2and the XML file describing the MTD.
<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.
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 Intermediate Lan-guage. .Net provides several infrastructures to implement distributed applications, such as XML web services using ASP.Net technology and .Net remoting. It also provides remote method invocation capa-bilities, services such as lifetime management and activation, and allows objects across the application
domain to interact. A leasing interface is used for remote object lifetime management. The framework supports the notion of remote objects, proxy objects, and remote object activation. It provides communi-cation channels that can serialize and deserialize objects when they are sent across applicommuni-cation domains. C# was chosen as the language to implement the distributed application. Two techniques were ex-plored for implementing crosscutting communication functionality as aspects. In the first technique, the .Net remoting features such as message sink chains associated with contex-bound objects were used. The application domain is divided into contexts that each contain one or more objects. In a cross-context method call, the call is intercepted by a message sink chain. Message sinks allow hooking 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 when cross-context methods are called.
There are some problems with this approach. To implement a remoting server that starts up and immediately attempts to register, one would need to have an outside object make a method call to force the sinks to execute the code for registration. Moreover, message sinks also require certain specific classes to be extended. Such a solution has restricted flexibility.
The second technique used the Aspect/C# language to implement aspects. Aspect/C# provides capa-bilities for introduction, and before, after, and around advice. An XML deployment descriptor document is used to weave aspect code into core classes. The descriptor file specifies the base directories for aspect code and core class files. The descriptor maps methods of aspect classes to methods of core classes.
The code that handlesremotingas methods in the aspect classes was extracted. These methods are
ap-propriately 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 by theSystem.MarshallByRefObject
class. Suppose the remote class is called Rem. A newRemWrapperwas defined that inherits from
Rem. The remoting server registers the classRemWrapperinstead of Remwith the remoting frame-work.
ACalculator application is used to illustrate middleware transparent development of .Net applica-tions. The server side of the application consists of the following classes:
1. CalcServerclass: contains themain()method in which the server waits for the client class
to connect.
2. ICalculatorinterface: defines theadd()andmultiply()methods.
3. Calculatorclass: implements the ICalculator interface and provides the remote object.
4. CalculatorWrapperclass: encapsulates the Calculator object, inherits from the
System.MarshallByRefObjectand implementsICalculator.
5. CalcServerAspectclass: defines the server side aspect. TheConnectmethod 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. MySponsorclass: acts as the sponsor for the lease of theCalculatorWrapperobject.
The client side has the following classes:
1. CalcClientclass: defines amain()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 CalculatorWrapperobject
on the server. It does not specify the CalculatorWrapperclass name; instead it attempts to
activate an object that implementsICalculator.
3. ICalculator: same as the server side interface.
It would seem that the Wrapper class can be eliminated by having the aspect force the required inheritance. However, if the remote class inherits from another application class, this would become a
problem 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 business functionality and transparently integrated into a distributed application. This allows one to more easily change pervasive middleware functionality. The following paragraphs present a discussion of the lessons learned and the issues that need to be addressed in future.
Aspects: An aspect captures the minimal structure and behavior expected from a certain middleware feature as a pattern. In some cases, this is not sufficient to support MTSD. For example, when error handling is performed, the catching of the exception and the actions taken to handle may differ from one application to another. The developer is required to add the application-specific code either to the aspect or to the code produced by the weaver. This problem was experienced in the work on CORBA transactions [33]. The behavior of operations such as commit and rollback can depend on the type of transactional resource and object, as well as the desired behavior from the point of view of the application developer. User-defined exceptions that need to be raised and handled by a 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 application developer. 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 implement the functionality described by aspects using models which can then be transformed to appropriate program-ming 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 models are also being investigated.
Converters: Ideally one should be able to weave an aspect with an MTD without the need to refactor or convert the MTD. In practice, an MTD may not have the architectural properties needed to weave the MTD and an aspect. For example, to use CORBA, several classes (e.g., skeletons and adapters) need to be generated from a service interface. It is unlikely that the MTD will have such classes. In Java RMI, the stub class is 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 done
by converters. For example, AspectJ 1.0 did not contain mechanisms to extend classes. However, the
current 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 be done 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 be included as this is often created by the target technology (e.g., Jini). In the MTSD approach, the proxy classes are introduced by converters. This is necessary in cases where the target technology assumes their existence. The creation of proxy classes, their methods, and data items is normally beyond the scope 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 of functionality that is beyond the capability of AOP languages.
The converters used in this paper are language and middleware specific. It is anticipated that vendors that provide middleware aspects will also provide converters. If there is a standard set of enhancements for every middleware technology, the converters will only need to be changed when the technology evolves or when the target programming language changes.
A vendor that develops middleware aspects and converters will need to make assumptions about the MTD architecture. This may require the application developer to follow guidelines in developing a MTD
that can be converted and composed with the aspects.
Scalability: The approach was applied to relatively small case studies where the business functional-ity was changed without 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 func-tionality are (1) the enhancements required (or implemented by the converter), and (2) the specification of pointcuts in the aspects. For example, changing business requirements may necessitate a change in the MTD architecture, 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 to add new pointcuts to the aspects. For example, if a new operation, foo(), requires
authoriza-tion, the authorization aspect code will need to be woven withfoo(). A new pointcut forfoo()must
be added to the authorization aspect.
The question as to which middleware features are amenable to aspect treatment is currently being investigated. 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 the generation of CORBA files associated with the service interface. The enhancement was performed by first generating the CORBA IDL interface from a Java interface using the tool, rmic, and then running the CORBA IDL compiler. Thus, the enhancements for CORBA were performed using available software, whereas, a converter needed to be implemented for Jini.
Component-based Approaches vs. MTSD: Container-based technologies, such as Enterprise Jav-aBeans (EJB) [34] and Real-time 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 an application, while the supporting infrastructural services are provided by the container. Con-tainers typically provide such services as security and distributed transactions. Thus, conCon-tainers insulate
the developer from the underlying middleware. Containers provide glue code generation services that are transparent to developers. Glue code is used to integrate different parts of an application code to form the complete system. In MTSD, glue code is provided by the aspects.
MTSD removes a number of inherent weaknesses in component-based approaches, and therefore, complements the approaches. Component-based approaches customize the generic business logic by adding “plumbing code” specific to the component technology. For example, an EJB server-side compo-nent 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, a developer wishing to change to a new or different component-based technology must remove scattered and tangled code from applications. MTSD is designed to address these problems.
Middleware features provided as components can be incorporated into the application using aspects with 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 to select ap-propriate mechanisms and ordering of aspects to ensure correct emergent behavior. Using the MTSD 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 using the component container. Once run-time weaving becomes available in AspectJ, it will be possible to weave 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 functional middleware design concerns in aspects that can be mechanically composed with middleware independent application designs at the code level. Current aspect-oriented programming languages can limit the type of
middle-ware 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 limita-tions will be removed as the languages evolve, but the code-based approach to aspect-oriented software
development will always be limited by the types ofjoin-pointsthat can be used for weaving in new code.
These limitations are almost nonexistent at the design modeling level because of the rich abstractions supported by modeling languages. There will still be limitations arising from use of specific modeling languages, but it is more likely that the abstractions can 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 be significantly changed to work with a distributed supermarket management application even though both are Jini ap-plications. The coupling arises out of a need for the aspect to know the names and attributes of several application classes. Although customized aspects can be written for every new application, reuse of the aspects in different Jini applications is limited because of the inability to describe generic aspects that can be instantiated for (or mapped to) different Jini applications. In the examples presented in this paper this limitation was addressed by introducing additional mechanisms not typically found in AOP development environments. For example, in the Jini example a tool was developed for renaming elements in generic Jini aspects to make them application specific and in one of the SOAP-RPC example an XSD was used to describe generic aspects. Language-specific aspects need to be written which makes 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 MTDs are described. The objective was to develop support for defining aspects that can be reused across different applications and that can be used to support MDA. An MDA approach has been developed in which a PIM describes a MTD, aspects describe middleware-specific design patterns, and a PSM is produced
by incorporating aspects into a PIM. The approach requires that aspect (pattern) elements be bound to application-specific elements before composition with the PIM. The binding is defined by the application
developer. The result of binding elements in an aspect is called acontext-specific aspect.
Middleware experts isolate and model the middleware specific concerns as aspects. Application developers create a PIM describing a MTD and define bindings used to produce context-specific aspects. Tools are used to weave the context-specific aspects with the PIM to produce the PSM.
9.1 Middleware Transparent Modeling
Aspect Model − 2 Middleware Aspect Model − n ... Context−specific
Generic Generic Generic
STEP 1 Binding PIM (MTD) Context−specific Middleware Aspect Model − 1 ... Middleware Aspect Model − 2 Middleware Context−specific Middleware Aspect Model − n Middleware Model − 1 Aspect
Figure 12: Generic and context-specific middleware aspects.
The design approach is illustrated in Figures 12 and 14. In Figure 12, the PIM describes the MTD
in terms of UML diagrams (e.g., class and sequence diagrams). AGeneric Middleware Aspect Model
describes middleware-specific design patterns. The aspect model is generic in that it can be applied to multiple PIMs.
Figure 13 illustrates the binding and composition process using aCurrencyConverter application.
The PIM (see Figure 13(a)) contains a Java server class called CurrencyConvertServer that implements
convert(float amt, String currency) CurrencyConvertInterface <<interface>> CurrencyConvertServer CurrencyConvertClient uses <<interface>> Remote
Currency Converter PIM
Generic Aspect
(a) Currency converter PIM and generic aspect. <<ClassTemplate>> |GenericServerInterface CurrencyConvertClient CurrencyConvertInterface <<interface>> <<interface>> Remote uses
convert(float amt, String currency)
Remote <<interface>> (b) Context−specific aspect. (c) Currency converter PSM. <<GenericServerImplementation>> CurrencyConvertServer <<GenericServerInterface>> CurrencyConvertInterface
Figure 13: Illustration of currency converter application.
amt, String currency)for converting currencies. The Java client classCurrencyConvertClient
invokes methods on the server. Generic aspects are described using a language for creating parameterized forms of UML diagrams (called diagram templates) [36, 37, 38, 39]. The generic aspect model for Java
RMI specifies a generic server interface that extends the special Java interface Remote. As part of the
binding process, the generic server interface needs to be bound to the PIM’sCurrencyConvertInterface
(see Figure 13(b)).
The context-specific aspect shown in Figure 13(b) is composed with the PIM to produce a PSM
(see Figure 13(c)) containing the CurrencyConvertServer and CurrencyConvertClient classes, and the
Middleware Aspect Model − n Composition Implement Application STEP 2 STEP 3 Context−specific Middleware Aspect Model − 1 Context−specific ... PIM (MTD) PSM (MSD) Implemented Context−specific Middleware Aspect Model − 2 STEP 2 Application Aspect Compiler Aspect − nCode Aspect − 2Code Aspect − 1Code
Implement Implement ... Implement Model − 2 STEP 3 Model − n Aspect Middleware Context−specific Context−specific Model − 1 Aspect Middleware Context−specific MTD Implemented of PIM Implementation Implement Aspect Middleware ...
(a) First compose and then implement. (b) First implement and then weave.
Figure 14: Application of design level middleware aspects.
Developing an aspect-oriented design consisting of middleware aspects and a PIM describing a MTD 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 are refined, where each refinement adds details previously abstracted in the design descriptions. Each level of 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 of abstraction. In other cases, new aspects are introduced.
9.1.2 Developing Generic Aspects
Generic aspect models describe middleware-specific design patterns in terms of template forms of UML class diagrams and interaction diagrams [40, 36, 37, 38, 39]. These pattern specifications define con-strained 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 UML diagrams that describe how the middleware functionality is realized in the application. These diagrams are 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 PIM describes 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 involves merging the elements in the views. Currently, the approach is limited to name-based merging of elements: elements with the same syntactic type and name (or signature in the case of operations and attributes) are merged.
The result of merging views can produce an inconsistent model. For this reason, techniques for iden-tifying inconsistencies during or after composition are needed [29]. Once identified, the inconsistencies
must be resolved. The technique allows one to specifycomposition directivesthat can be used to resolve
conflicts [30, 29]. Composition directives can be used to refactor diagrams, that is, to remove or add structures in diagrams. In some cases, resolving conflicts using composition directives may be impracti-cal because of the extensive changes needed. In these cases the developer may have to consider doing a redesign of the MTD or using different aspects.
9.2 Implementing Aspect-Oriented Designs
Figure 14 describes two approaches to implementing aspect-oriented designs. The previous discussion was based on the approach illustrated in Figure 14(a). In that approach context-specific aspects are composed with the PIM to produce a PSM that is then implemented in code, possibly with the help of code generators.
An alternative approach is presented in Figure 14(b), where the PIM is implemented as is in code and the context-specific aspects are directly implemented as code aspects. The weaving is done at the coding level rather than at the modeling level. In the Currency Converter example, this could involve
writing an AspectJ aspect that would effectively declare the interfaceCurrencyConvertInterfacewith the
extends Remoteclause using the following AspectJ notation:
declare parents:
CurrencyConverterInterface
extends Remote;
A problem with this approach is that it may not always be possible to directly implement an aspect model as an aspect in a programming language. However, the advantage is that one can transform the context-specific aspect model to any aspect language (Java / C#) as long as appropriate constructs exist in 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 decouple busi-ness functionality from the specifics of the middleware technologies was presented. The approach was illustrated at the code level through Java RMI, Jini, .Net and SOAP-RPC examples. While the examples
presented in the paper are code-based, a proposal to raise the level of abstraction and use middleware transparent design models along with aspect models was presented. This proposal supports model-based development and consequently, the MDA initiative.
Use of the approach can reduce the effort needed to evolve distributed applications when change is triggered by changes in middleware platforms. The approach was applied to relatively small case studies. In future, large systems that change over a period of time will be used to investigate the scalability of the approach.
Work is being done using several middleware technologies to identify what features can and cannot be practically isolated as aspects. An evaluation is being performed to identify which aspects are best specified and composed at the modeling level and which ones at the code level. The approach will be
applied to aspectualizepluggable protocol frameworks for interoperability with new middleware
tech-nologies.
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 other design prob-lems 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 applications will be evalu-ated.
References
[1] OMG — The Object Management Group. Common Object Request Broker Architecture
CORBA/IIOP 2.6. OMG, 2002.
[2] Microsoft Inc. Component Object Model (COM) Website. URLhttp://www.microsoft.
[3] Jim Waldo. “Alive and Well: Jini Technology Today”.IEEE Computer, 33(6):107–109, June 2000.
[4] Microsoft Corporation. .Net. URLhttp://www.microsoft.com/net/, 2003.
[5] W3C. Simple Object Access Protocol (SOAP).URLhttp://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] L. Bergmans and M. Aksit. Composing multiple concerns using composition filters.
Communica-tions of the ACM, 44(10), Oct 2001.
[8] G. Kiczales, E. Hilsdale, J. Hugunin, M. Kersten, J. Palm, and W. G. Griswold. Getting started with
AspectJ. Communications of the ACM, 44(10):59–65, October 2001.
[9] G. Kiczales, E. Hilsdale, J. Hugunin, M. Kersten, J. Palm, and W. G. Griswold. An overview of
AspectJ. InProceedings of the European Conference on Object-Oriented Programming (ECOOP
’01), pages 327–353, Budapest, Hungary, June 2001.
[10] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. V. Lopes, J-M. Loingtier, and J. Irwin.
Aspect-oriented programming. In Proceedings of the European Conference on Object-Oriented
Programming (ECOOP ’97), volume 1241 ofLecture Notes in Computer Science, pages 220–242, Jyvaskyla, Finland, June 1997.
[11] K. Kieberherr, D. Orleans, and J. Ovlinger. Aspect-oriented programming with adaptive methods.
Communications of the ACM, 44(10):39–41, October 2001.
[12] H. Ossher and P. Tarr. Using multidimensional separation of concerns to (re)shape evolving
[13] J. A. D. Pace and M. R. Campo. Analyzing the role of aspects in software design. Communications of the ACM, 44(10):66–73, Oct. 2001.
[14] A. R. Silva. Separation and composition of overlapping and interacting concerns. InOOPSLA ’99
First Workshop on Multi-Dimensional separation of Concerns in Object-Oriented Systems, Denver, Colorado, November 1999.
[15] G. T. Sullivan. Aspect-oriented programming using reflection and metaobject protocols.
Commu-nications of the ACM, 44(10):95–97, October 2001.
[16] Laurent Bussard. Towards a Pragmatic Composition Model of CORBA Services Based on
As-pectJ. InProceedings of ECOOP 2000 Workshop on Aspects and Dimensions of Concerns, Sophia
Antipolis and Cannes, France, June 2000.
[17] Frank Hunleth, Ron Cytron, and Christopher Gill. Building Customizable Middleware Using
Aspect Oriented Programming. In OOPSLA Workshop on Advanced Separation of Concerns in
Object-Oriented Systems, Tampa, Florida, USA, October 2001.
[18] S. Clarke, W. Harrison, H. Ossher, and P. Tarr. Separating concerns throughout the development
lifecycle. In Proceedings of the 3rd ECOOP Aspect-Oriented Programming Workshop, Lisbon,
Portugal, June 1999.
[19] S. Clarke and J. Murphy. Developing a tool to support the application of aspect-oriented
program-ming principles to the design phase. InProceedings of the International Conference on Software
Engineering (ICSE ’98), Kyoto, Japan, April 1998.
[20] J. L. Fiadeiro and A. Lopes. Algebraic semantics of co-ordination or what is it in a signature? In
and Software Technology (AMAST’98), volume 1548 ofLecture Notes in Computer Science, pages 293–307, Amazonia, Brasil, January 1999. Springer-Verlag.
[21] J. Gray, T. Bapty, S. Neema, and J. Tuck. Handling Crosscutting Constraints in Domain-Specific
Modeling. Communications of the ACM, 44(10):87–93, October 2002.
[22] A. Rashid. A Hybrid Approach to Separation of Concerns: The Story of SADES. In 3rd
Interna-tional Conference on Meta-Level Architectures and Separation of Concerns (Reflection), Springer-Verlag Lecture Notes in Computer Science 2192, pages 231–249, Kyoto, Japan, September 25–28 2001.
[23] A. Rashid, A. Moreira, and J. Araujo. Modularization and Composition of Aspectual Requirements. In 2nd International Conference on Aspect-Oriented Software Development, ACM, pages 11–20, Boston, March 2003.
[24] A. Rashid, P. Sawyer, A. Moreira, and J. Araujo. Early Aspects: A Model for Aspect-Oriented
Requirements Engineering. InIEEE Joint International Conference on Requirements Engineering,
IEEE Computer Society Press, pages 199–202, Essen, Germany, September 9–13 2002.
[25] J. Suzuki and Y. Yamamoto. Extending UML with Aspects: Aspect Support in the Design Phase. In
Proceedings of the 3rd ECOOP Aspect-Oriented Programming Workshop, Lisbon, Portugal, June 1999.
[26] Manuel Roman, Fabio Kon, and Roy H. Campbell. Universally Interoperable Core: A
plat-form for the construction of domain specific middleware implementations. URLhttp://www.
ubi-core.com/, 2004.
[27] Roman Pichler, Klaus Ostermann, and Mira Mezini. On Aspectualizing Component Models.
[28] R. France and G. Georg. Modeling fault tolerant concerns using aspects. Technical Report 02-102, Computer Science Department, Colorado State University, 2002.
[29] Geri Georg, Indrakshi Ray, and Robert France. Using Aspects to Design a Secure System. In
Proceedings of the Interational Conference on Engineering Complex Computing Systems (ICECCS 2002), Greenbelt, MD, December 2002. ACM Press.
[30] Geri Georg, Robert France, and Indrakshi Ray. An Aspect-Based Approach to Modeling Security
Concerns. InProceedings of the Workshop on Critical Systems Development with UML, Dresden,
Germany, 2002.
[31] Geri Georg, Robert France, and Indrakshi Ray. Designing High Integrity Systems using Aspects. In Proceedings of the Fifth IFIP TC-11 WG 11.5 Working Conference on Integrity and Internal Control in Information Systems (IICIS 2002), Bonn, Germany, November 2002.
[32] Jens Palsberg. JTB: Java Tree Builder. URLhttp://www.cs.purdue.edu/jtb/.
[33] B. Kamalakar. Aspect-Oriented Development of CORBA-based Applications. Master’s Thesis (in
preparation), Department of Computer Science, Colorado State University, Fort Collins, Colorado,
USA, 2004.
[34] Sun Microsystem. Entity Java Bean EJB. URLhttp://java.sun.com/products/ejb/,
2003.
[35] Distributed Object Computing (DOC) Group. Real-time CCM with CIAO. URLhttp://www.
cs.wustl.edu./˜schmidt/CIAO.html, 2004.
[36] R. B. France, D. K. Kim, E. Song, and S. Ghosh. Using Roles to Characterize Model Families. InProceedings Tenth OOPSLA Workshop on Behavioral Semantics: Back to the Basics, Portland, Oregon, October 2001.
[37] R. B. France, I. Ray, G. Georg, and S. Ghosh. “An Aspect-Oriented Approach to Design
Model-ing”. IEE Proceedings — Software, Special Issue on Early Aspects, Aspect-Oriented Requirements
Engineering and Architectural Design, 151(4):173–185, August 2004.
[38] D. K. Kim, R. B. France, S. Ghosh, and E. Song. Using Role-Based Modeling Language (RBML)
as Precise Characterizations of Model Families. In Proceedings of the 8th IEEE International
Conference on Engineering of Complex Computer Systems (ICECCS), Greenbelt, MD, December 2002.
[39] D. K. Kim, R. B. France, S. Ghosh, and E. Song. A Role-Based Metamodeling Approach to
Specifying Design Patterns. InCOMPSAC 2003, pages 452–457, Dallas, TX, November 2003.
[40] R. B. France, S. Ghosh, E. Song, and D. K. Kim. A Metamodeling Approach to Pattern-Based
Model Refactoring. IEEE Software Special Issue on Model-Driven Development, 20(5):52–58,
