A Middleware Transparent Approach to Developing ... - CiteSeerX

4 downloads 88885 Views 223KB Size Report
Nov 9, 2004 - The middleware transparent approach is used to decouple business ..... The application converter was written using the Java Tree Builder .... .Net provides several infrastructures to implement distributed applications, such as XML web ..... An evaluation is being performed to identify which aspects are best.
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 innovative middleware transparent approach to developing distributed applications is presented. The approach uses an aspect-oriented software development technique to separate an application’s middlewareindependent functionality from its middleware-specific functionality. Application elements that are specific to the middleware are localized in aspects that can be seamlessly integrated into middlewareindependent application designs. The middleware transparent approach is used to decouple business functionality from middleware-specific functionality. The decoupling allows developers to change middleware application elements without significantly modifying business functionality. Middleware technologies 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 technologies, SOAP-RPC, .Net.

1

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, the middleware is a layer of software between applications 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 encapsulated 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., performing authentication before authorization). The crosscutting nature makes changing the middleware of distributed applications risky and challenging. This paper presents a middleware transparent approach to the development of distributed applications 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 decouple business functionality from middleware concerns. Middleware-specific application elements are localized in aspects that can be seamlessly integrated (or woven) into an application design describing core business functionality. The localization of crosscutting 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) language, 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 2

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 distributed 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] encapsulated 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 AspectIDL 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 software 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 descriptions. The Model Driven Architecture (MDA) initiative recognizes the need for raising the level 3

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 technology 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 design 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 (platform) 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 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 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 1

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

4

techniques for representing and composing cross-cutting middleware functionalities. The Universally Interoperable Core (UIC) designed by Ramon, Kon and Campbell [26], is a collection 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 limited 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 specific 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 aspectualize component 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. 5

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 aspectoriented programming language such as AspectJ and the MSDs are the result of compiling the MTDs with aspects.

6

Middleware aspect − 1

Middleware aspect − 2

Middleware− Transparent Design (MTD)

...

Middleware aspect − n

Composer

Middleware−Specific Design (MSD)

Figure 1: Composing middleware aspects and a MTD. Figure 2 illustrates how the aspect-oriented approach can ease evolution of a distributed application’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 middleware platform   with a new platform  involves producing a new MSD,  , by composing aspects in the set      with  !  . middleware change

Middleware platform M1

Develop Aspects

M1aspects

Business Requirements

Middleware platform M2

Develop MTD

Develop Aspects

M2aspects

MTD1

Compose

MSD1

Compose

application change

MSD2

Figure 2: Supporting evolution of middleware platforms. 7

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. EMTD

MTD

Aspect Weaver

Converter

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 signature. 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 signature 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 specified in MTDs as that would make the MTDs platform specific. The conversion is not implemented in 8

the weaver (e.g., AspectJ) as this would make the weaver middleware specific. Specifying the transformation 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 framework. 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, 9

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 register() buy() sell() Authorization

Broker

StockHolder

Figure 4: Jini StockBroker MTD The Jini converters and the MFA were developed as a one-time exercise. The MTD classes and interfaces 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: 10

Activation UnicastRemoteObject Activatable

ActivationException

RemoteException

ActivationID

Remote

ActivationDesc

MarshalledObject RMISecurityManager

ActivationGroup

discovery

ActivationGroupID

DiscoveyListener

ActivationGroupDesc

DiscoveyEvents lease ServerAspect

Lease UnknownLeaseException

LEASE_TIME:int item:ServiceItem disco:LookupDiscovery registrations:Hashtable codebase:String constructorProxy(String) discovered(DiscoveryEvent) discarded(DiscoveryEvent) registerWithLookup(ServiceRegistrar) createProxy():StockBrokerInterface computeSleepTime() renewLeases() run()

LookupDiscovey

Lookup ServiceRegistrar ServiceRegistration ServiceItem

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

11

Remote Authorization RemoteStockBrokerInterface register buy sell

StockHolder

Broker

Serializable

Activatable

Runnable BrokerProxy

StockBrokerService

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

12

Activation UnicastRemoteObject Activatable

ActivationException

RemoteException

ActivationID

Remote

ActivationDesc

MarshalledObject RMISecurityManager

ActivationGroup

discovery

ActivationGroupID

DiscoveryListener

ActivationGroupDesc

DiscoveryEvents lease Lease UnknownLeaseException

BrokerProxy

Serializable Runnable StockBrokerInterface

StockHolder

LookupDiscovery

StockBrokerService LEASE_TIME:int item:ServiceItem disco:LookupDiscovery registrations:Hashtable codebase:String

Authorization

Broker Lookup

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

ServiceRegistrar ServiceRegistration

Activatable Remote− Stock− Broker− Inerface

Remote

ServiceItem

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.

13

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 UnicastRemoteObject class, or by extending the Activatable class. Servers register remote objects created by extending the UnicastRemoteObject 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 the Naming class. Servers create remote activatable objects by extending the Activatable class and register them with 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 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 the UnicastRemoteObject type, and the other (Figure 10) for the Activatable type. Some client specific aspects were also written that support looking up remote objects and remotely invoking these objects.

14

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 15

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

16

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, ArgumentType and NestedObjectType) in Figure 11 are presented. The ReturnType definition is similar to the ArgumentType definition. An argument class may be a user-defined class, and it may have another user-defined class nested in it. The NestedObjectsType class in the arguments 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)2 and the XML file describing the MTD. 2

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

17

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 Language. .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 capabilities, services such as lifetime management and activation, and allows objects across the application

18

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 communication channels that can serialize and deserialize objects when they are sent across application domains. C# was chosen as the language to implement the distributed application. Two techniques were explored 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 capabilities 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 handles remoting as methods in the aspect classes was extracted. These methods 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 by the System.MarshallByRefObject class. Suppose the remote class is called Rem. A new RemWrapper was defined that inherits from System.MarshallByRefObject. The new class creates and encapsulates an object of the class

19

Rem. The remoting server registers the class RemWrapper instead of Rem with the remoting framework. A Calculator application is used to illustrate middleware transparent development of .Net applications. 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 class to 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 object on the server. It does not specify the CalculatorWrapper class name; instead it attempts to activate 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 required inheritance. However, if the remote class inherits from another application class, this would become a 20

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 programming 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.

21

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

22

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 functionality 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 authorization, the authorization aspect code will need to be woven with foo(). A new pointcut for foo() 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 JavaBeans (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. Containers typically provide such services as security and distributed transactions. Thus, containers insulate 23

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 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, 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 appropriate 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 middle24

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 limitations will be removed as the languages evolve, but the code-based approach to aspect-oriented software development will always be limited by the types of join-points that 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 applications. 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

25

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 a context-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 Generic Middleware Aspect Model − 1

PIM (MTD)

Context−specific Middleware Aspect Model − 1

Generic Middleware Aspect Model − 2

...

Generic Middleware Aspect Model − n

STEP 1

Binding

Context−specific Middleware Aspect Model − 2

...

Context−specific Middleware Aspect Model − n

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). A Generic 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 a CurrencyConverter application. The PIM (see Figure 13(a)) contains a Java server class called CurrencyConvertServer that implements an interface called CurrencyConvertInterface. This interface has a method called float convert(float 26

CurrencyConvertInterface

Remote

uses convert(float amt, String currency) CurrencyConvertClient

CurrencyConvertServer

CurrencyConvertInterface

Currency Converter PIM

(b) Context−specific aspect.

Remote



CurrencyConvertInterface

Remote

convert(float amt, String currency)

Generic Aspect uses |GenericServerInterface

CurrencyConvertClient

(a) Currency converter PIM and generic aspect.

CurrencyConvertServer

(c) Currency converter PSM.

Figure 13: Illustration of currency converter application. amt, String currency) for converting currencies. The Java client class CurrencyConvertClient 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’s CurrencyConvertInterface (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 CurrencyConvertInterface and Remote interfaces with the appropriate associations.

27

Context−specific Middleware Aspect Model − 1

PIM (MTD)

Context−specific Middleware Aspect Model − 2

Context−specific ... Middleware Aspect Model − n

Composition

STEP 2

MTD

STEP 2

PSM (MSD)

Implement

STEP 3

Context−specific Middleware Aspect Model − 1

Implement

Implement

Implementation of PIM

Code Aspect − 1

STEP 3

Context−specific Middleware ... Aspect Model − 2

Implement

Code Aspect − 2

Context−specific Middleware Aspect Model − n

...

Implement

Code Aspect − n

Aspect Compiler

Implemented Application

Implemented Application

(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.

28

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 constrained 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 identifying inconsistencies during or after composition are needed [29]. Once identified, the inconsistencies must be resolved. The technique allows one to specify composition directives that 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 impractical 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.

29

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 interface CurrencyConvertInterface with the extends Remote clause 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 business 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 30

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 aspectualize pluggable protocol frameworks for interoperability with new middleware technologies. 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 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 applications will be evaluated.

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. URL http://www.microsoft. com/com/ .

31

[3] Jim Waldo. “Alive and Well: Jini Technology Today”. IEEE Computer, 33(6):107–109, June 2000. [4] Microsoft Corporation. .Net. URL http://www.microsoft.com/net/, 2003. [5] W3C. Simple Object Access Protocol (SOAP). URL 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] L. Bergmans and M. Aksit. Composing multiple concerns using composition filters. Communications 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. In Proceedings 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 of Lecture 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 software. Communications of the ACM, 44(10):43–50, October 2001.

32

[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. In OOPSLA ’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. Communications of the ACM, 44(10):95–97, October 2001. [16] Laurent Bussard. Towards a Pragmatic Composition Model of CORBA Services Based on AspectJ. In Proceedings 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 programming principles to the design phase. In Proceedings 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 A. Haeberer, editor, Proceedings of the 7th International Conference on Algebraic Methodology

33

and Software Technology (AMAST’98), volume 1548 of Lecture 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 International Conference on Meta-Level Architectures and Separation of Concerns (Reflection), SpringerVerlag 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. In IEEE 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 platform for the construction of domain specific middleware implementations. URL http://www. ubi-core.com/, 2004. [27] Roman Pichler, Klaus Ostermann, and Mira Mezini. On Aspectualizing Component Models. Software Practice and Experience, 33(10):957–974, August 2003. 34

[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. In Proceedings 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. URL http://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. URL http://java.sun.com/products/ejb/, 2003. [35] Distributed Object Computing (DOC) Group. Real-time CCM with CIAO. URL http://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. In Proceedings Tenth OOPSLA Workshop on Behavioral Semantics: Back to the Basics, Portland, Oregon, October 2001. 35

[37] R. B. France, I. Ray, G. Georg, and S. Ghosh. “An Aspect-Oriented Approach to Design Modeling”. 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. In COMPSAC 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, September 2003.

36