Buletinul Stiintific al Universitatii “Politehnica” din Timisoara, ROMANIA Seria AUTOMATICA si CALCULATOARE PERIODICA POLITECHNICA, Transactions on AUTOMATIC CONTROL and COMPUTER SCIENCE Vol.49 (63), 2004, ISSN 1224-600X

Using Aspect Oriented Programming for Performance Improving of J2EE Applications Lucian Gabor1 and John Murphy2 1

Performance Engineering Laboratory, School of Electronic Engineering, Dublin City University, Glasnevin, Dublin 9, Ireland Phone: +353 1 700 7645, Email: [email protected]

2

Performance Engineering Laboratory, Department of Computer Science, University College Dublin, Belfield, Dublin 4, Ireland Phone: +353 1 716 2921, Email: [email protected]

are very well served in AOP. One technology that offers such services is Enterprise Java Beans (EJB), a component based technology. Being a mature technology, collections of design patterns are already proposed. One of the first collections of design patterns for EJB has been developed at Sun Java Center (SJC) [2]. A more recent publication on this topic has been developed by the “TheServerSide” [3], a J2EE Community. These books follow the path that commenced with the Gang of Four's (GoF) book [4] and continued with other more recent publications [5], [6].

Abstract: This paper presents the performance improvements that could be achieved using AspectOriented Programming (AOP) in Java 2 Enterprise Edition (J2EE) applications. The focus is on extending the services that an EJB server offers with services defined through design patterns. The paper proposes a library of AOP implementations for design patterns. It also contributes to the design pattern-oriented development process.

Keywords: Design patterns, Aspect-oriented programming, J2EE applications, Middleware The use of design patterns is a recommended practice for building large software systems in order Performance to increase productivity and to avoid making bad design decisions or reinventing the wheel. Another benefit of a design pattern is the power to I. INTRODUCTION communicate its intent. The name of the design pattern is a sign that tights together the pattern's It is well established that object-oriented solution with the pattern's intent [7]. programming (OOP) has been one of the most important programming paradigms. In this model all real-world entities are mapped to software II. ASPECT ORIENTED DESIGN PATTERNS abstractions called objects. With each object being self-contained, it encapsulates all the state and behaviour of the associated real-world entity. This section details our approach on using design patterns and AOP to improve the performance of J2EE applications. The key aspect of the approach is to select design patterns which are suitable to be implemented in separate modules. This means that the participants in the design pattern do not need to be aware of their roles in the design pattern.

Aspect-oriented programming (AOP) is a modern technology that extends OOP paradigm with the new concept of aspects (or concerns). An aspect encapsulates state and behaviour that are not an intrinsic part of a real-world entity. In an OOP approach, such functionality would be encapsulated in an object and could be scattered over a series of objects. One way to differentiate between objects and aspects is the functional/non-functional part of the problem. While the notion of functional part has never been precisely defined, mechanisms such as transactions, security or pooling are considered nonfunctional parts of a program [1]. These mechanisms

A.

Overview

Each of the previously mentioned references propose a system of design patterns that addresses comprehensively the problems that an software architect might encounter while designing a product.

1

Buletinul Stiintific al Universitatii “Politehnica” din Timisoara, ROMANIA Seria AUTOMATICA si CALCULATOARE PERIODICA POLITECHNICA, Transactions on AUTOMATIC CONTROL and COMPUTER SCIENCE Vol.49 (63), 2004, ISSN 1224-600X

design patterns and other language limitations that will be documented per case.

Our focus is on the performance issues of a software system and there are quite a large number of design patterns from those books addressing this problem, even if the main purpose could be different.

C. Performance Issues of J2EE Applications A recent study [9] demonstrated that J2EE applications spend most of their execution time in communication control, thereby causing most of their performance problems. There are several patterns that address the problem of minimising network traffic that are caused by remotely invoking methods.

Another aspect is that a major part of the design patterns presented in the already mentioned references have a crosscutting structure. This is caused by the roles that different objects play in various design pattern collaborations. This structure is well supported by AOP with several modularity properties enhanced such as locality, reusability, transparency and (un-) pluggability [8]. Our research focuses on the last aspect.

A further issue is the optimization of the deployment of a J2EE application. This problem is related to the main network traffic problem. Ideally, all components that communicate intensively should be placed in the same container or be “facaded”.

Summarising, this paper consists of selecting performance related design patterns that can be dynamically plugged and unplugged. These patterns will form a design pattern library and will be used in a development tool that will facilitate their usage.

B.

The scaling of an application is a performance issue that might be solved using asynchronous messages. Being a java application, a J2EE applic ation inherits other type of performance problems such as inefficient memory usage, multiple levels of indirection, long initialising time, etc.

Motivation

There is a list of advantages that our approach will bring in order to obtain high performance J2EE applications.

D. Design Pattern Library The pattern library presented in this paper contains performance related design patterns from previously mentioned collections. The key requirement for a design pattern in our library is to have a solution that does not require any code changes in the participants to the collaboration. All design patterns that belong to the EJB-specific pattern systems [2], [3] have been analysed and the candidates selected are:

1. Declarative use of design patterns – the developer will only have to select the participants in a design pattern. 2. Late design decisions – due to the independence between the design pattern implementation (encapsulated in an aspect) and the participants to the design pattern, the decision to use a design pattern can be postponed or corrected. This property is tightly related to the next two properties.

• • • • • •

3. Performance tweaking – the developer can tweak the performance of its application in a cycle of adding/removing a design pattern and testing.

Message Facade [2] EJB Command [2] Generic Attribute Access [2] Data Transfer HashMap [2] EJBHomeFactory [2] Service Locator [3]

From the other sources [4], [5] some candidates have been selected in order to exemplify particular cases of performance improvements, but a complete analysis of those pattern systems is outside the scope of this current paper. Some of those patterns were selected due to their collaboration with previously selected design patterns. The proposed list is:

4. Avoid the overuse of design patterns – this is an anti-pattern. Beside these generic benefits, using an AOP implementation will eliminate some drawbacks of an OOP implementation such as more levels of indirection, type safety compromises of particular

2

Buletinul Stiintific al Universitatii “Politehnica” din Timisoara, ROMANIA Seria AUTOMATICA si CALCULATOARE PERIODICA POLITECHNICA, Transactions on AUTOMATIC CONTROL and COMPUTER SCIENCE Vol.49 (63), 2004, ISSN 1224-600X

• • • • •

E.

Proxy [4] Flyweight [4] Singleton [4] Object Pool Object Pool Client-Dispatcher-Server [5]

The Tool

The tool that will provide the interface between a developer and the design pattern library is in the early stages of development.

1. Example 1: “EJBHomeFactory”

Requirements

Being a proof-of-concept product the requirements are less complex and presented as a list of features.

Problem: An EJB client needs to look up an EJBHome Object, but multiple lookups of the same home are redundant.

1. The tool integrates with a java/J2EE development environment in order to be able to test the result of applying a design pattern.

Solution: Abstract EJBHome lookup code into a reusable EJBHomeFactory which can cache EJBHomes for the lifetime of a client application.

2. The tool provides a wizard to apply a design pattern. The user has to select the participants to the pattern from existing objects and name the different roles that a pattern introduces. It also has to set values for different properties that a design pattern implies.

The two participants in the pattern are: (i) EJBHomeFactory (auto-generated) (ii) Multiple clients (picked by the developer). The parameters for the pattern are the list of initial context properties and the list of EJBHome – JNDI name pairs. In order to ensure that the clients obtain a reference to an EJBHome through the factory, a restriction is imposed. Using constructs provided by AspectJ, an AOP extension to java, any call on a method that returns an EJBHome object from within the client code is replaced with a call on the specific factory method. Being comprehensive, this construct ensures that changes in the client code will not affect the use of the pattern.

3. The tool provides access to the properties of a design pattern. The user can modify those properties in order to change one or more participants in the pattern or to change various parameters that a pattern implies or the names of the roles played by participants. 4. The tool provides access to a list of applied design patterns. The actions that a user can take are: delete, list participants and describe the design pattern and the role that each participant plays.

Example 2: “Flyweight” Problem: An object or a group of objects takes too long or too much memory to create and their need is uncertain.

5. The tool provides access to a list of design patterns in which an object plays a role.

Solution: Create a proxy object that will create the actual object when needed.

2.

The participants in the pattern are one service and multiple clients, which are picked by the developer, and one proxy which is auto-generated. There are no parameters for this pattern. Using AOP constructs, the design pattern implementation has the following structure: •

•

Implementation Issues

Each design pattern from the library will have an AspectJ implementation. The design patterns are be stored as templates. Using the Velocity Template Engine all the necessary code will be generated. In order to keep the implementation as simple as possible, the generated code will not be used in any other collaboration.

replace any creation of a service object with a creation of a proxy object create within the proxy a service object when any access occurs

The integration environment for our tool will be the Eclipse platform and it will consist of several Eclipse Views and one Eclipse Editor:

3

Buletinul Stiintific al Universitatii “Politehnica” din Timisoara, ROMANIA Seria AUTOMATICA si CALCULATOARE PERIODICA POLITECHNICA, Transactions on AUTOMATIC CONTROL and COMPUTER SCIENCE Vol.49 (63), 2004, ISSN 1224-600X

context is a group of objects, their relations and interactions.

1. Design Pattern Browser View – provides access to all design patterns that are present in the active Eclipse project. Presented as a tree, its structure is the following – Eclipse project, design patterns, design pattern instances, participants. 2. Design Pattern Description View – provides access to the active design pattern or participant. This view is linked with Design Pattern Browser View and Related Pattern View. 3. Related Pattern View – provides access to the list of design patterns that are related with the active design pattern or participant. Two design patterns are related if one object plays a role in both collaborations. A design pattern is related to an object if that object plays a role in design pattern's collaboration. This view is linked with Design Pattern Browser View.

Anti-patterns are similar to patterns. They document recurring solutions to common design problems. The difference is that their result is negative.

3.

AspectJ is a seamless aspect-oriented extension to Java.

4.

Eclipse is a platform that integrates software development tools.

5.

Eclipse Views support editors and provide alternative presentations of or ways to navigate the information in Eclipse Development Environment.

6.

Velocity is a Java-based template engine. It permits anyone to use the simple yet powerful template language to reference objects defined in Java code.

REFERENCES [1] J. Kienzle, R. Guerraoui: AOP: Does It Make Sense? The Case of Concurrency and Failures, Proceedings of ECOOP 2002 – Object-Oriented Programming the 16th European C onference, June 2002

4. Design

Pattern Properties Editor – provides access to the properties, roles and participants of a design pattern. This editor is linked with Design Pattern Browser View and Related Pattern View.

[2] D. Alur, J. Crupi, D. Malks: Core J2EE Patterns Best Practices and Design Strategies, Sun Microsystems Press, 2001

III. CONCLUSIONS

[3] F. Marinescu: EJB Design Patterns – Advanced Patterns, Processes and Idioms, John Wiley & Sons, Inc, 2002

This paper has presented some examples of performance improvements that could be achieved using Aspect-Oriented Programming (AOP) in Java 2 Enterprise Edition (J2EE) applications. While the implementation is at an early stage of extending the services that an EJB server offers, there is a proposed library of AOP implementations for design patterns. This further contributes to the design pattern-oriented development process.

[4] E. Gramma, R. Helm, R. Johnson, J. Vlissides: Design Patterns - Elements of Reusable ObjectOriented Software, Addison-Wesley, 1995 [5] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal: Pattern-Oriented Software Architecture A System of Patterns, John Wiley and Sons, 1996 [6] D.C Schmidt, M. Stal, H. Rohnert, F. Buschmann.: Pattern-Oriented Software Architecture Patterns for Concurrent and Networked Objects, John Wiley and Sons, 2000

IV. ACKNOWLEDGEMENTS

[7] J. Noble, R. Biddle: Patterns as Signs, Proceedings of ECOOP 2002 – Object-Oriented Programming the 16th European Conference, June 2002

The support of both the Research Innovation Fund and the Informatics Research Initiative of Enterprise Ireland is gratefully acknowledged.

[8] J. Hannemann, G. Kiczales: Design Pattern Implementation in Java and AspectJ, Proceedings of OOPSLA 2002, 2002

V. DEFINITIONS 1.

2.

[9] E. Cecchet, J. Marguerite, W. Zwaenepoel: Performance and Scalability of EJB Applications, Proceedings of the 17th Annual ACM Conference

A design pattern is a recurring solution to a problem that appears in a specific context. The

4

Buletinul Stiintific al Universitatii “Politehnica” din Timisoara, ROMANIA Seria AUTOMATICA si CALCULATOARE PERIODICA POLITECHNICA, Transactions on AUTOMATIC CONTROL and COMPUTER SCIENCE Vol.49 (63), 2004, ISSN 1224-600X

on Object-Oriented Programming, Languages and Applications, 2002

Systems,

Patterns: A Refactoring Approach, Doctor of Philosophy Thesis, University of Dublin, Trinity College, 2000

[10] M. Ó Cinnéide: Automated Application of Design

5