PreciseJava.com - Best practices to improve performance in J2EE using Patterns

EJB | JDBC | Servlets | JSP | Patterns | JMS

Best practices to improve performance using Patterns in J2EE

This topic illustrates the performance improvement best practices using Patterns in J2EE with the following sections:

Overview of Patterns
Service Locator
Session Facade
Message Facade
Value Object
Value Object Factory
Value List Handler
Composite Entity
Key Points

Pattern is a solution to a recurring problem in a context. Once Pattern (solution) is developed from a recurring problem it can be reused without reinventing the solution again. Patterns are popularized by the classic book Design Patterns: Elements of Reusable Object-Oriented Software, by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, also called as GOF (Gang of Four) representing four authors who wrote that book. Specifically for J2EE problems and solutions, we have now Core J2EE Patterns, Best Practices and Design Strategies by Sun Java Center and EJB Design Patterns by TheServerSide.com.

This section mainly focuses on performance improvement practices using Patterns in J2EE. The organization of each Pattern is as follows: initially the problem is described, a solution for that problem is mentioned and links to source code implementation for that pattern is given.

Note1: This Section assumes that reader has some basic knowledge of J2EE.

Note2: This Section does not focus on other advantages of Patterns such as flexible design, reusability etc.

Service Locator

Problem:

J2EE specification mandates the usage of JNDI (Java Naming and Directory Interface) to access different resources/services. J2EE compatible server binds these resources/services to the JNDI server so that the clients can lookup those resources/services through JNDI lookup process from anywhere in the network. The resources/services can be

1. EJBHome objects

2. DataSource objects

3. JMS ConnectionFactory

4. JMS Topic/Queue etc.

EJB Client needs to initially get EJBHome object from JNDI to manage life cycle of EJBObjects. JMS clients need to get ConnectionFactory and Topic/Queue from JNDI for processing messages. JDBC clients need to get DataSource object in order to get database connection. All these services need to bind to the JNDI services and the clients need to lookup JNDI to get those services. Clients have to go through JNDI lookup process every time to work with these services. JNDI lookup process is expensive because clients need to get network connection to the JNDI server if the JNDI server is located on a different machine and need to go through lookup process every time, this is redundant and expensive.

The figure below shows the client's JNDI lookup process.

Solution through Service Locator Pattern:

The solution for the redundant and expensive JNDI lookup process problem is to cache those service objects when the client performs JNDI lookup first time and reuse that service object from the cache second time onwards for other clients. This technique maintains a cache of service objects and looks up the JNDI only first time for a service object. This technique reduces redundant and expensive JNDI lookup process thus increasing performance significantly. Service Locator Pattern implements this technique by having a class to cache service objects, methods for JNDI lookup and methods for getting service objects from the cache.

The figure below shows the ServiceLocator class intercepting the client request and accessing JNDI once and only once for a service object.

Here the clients call ServiceLocator class to get a service object rather than calling JNDI directly. ServiceLocator acts as interceptor between client and JNDI. For source code and different flavors of implementation of this Pattern, see the following links.

Source:

You can get the source for this Pattern in two flavors

1. Service Locator:

Sun Java Center J2EE Patterns catalog has this Pattern as Service Locator (register and login to access this link)

http://developer.java.sun.com/developer/restricted/patterns/ServiceLocator.html

2. EJB Home Factory:

TheServerSide.com has online EJB Design Patterns book that has this Pattern as EJB Home Factory, it is meant mainly for EJBHome objects (register and login to access this link).

http://www.theserverside.com/resources/patterns_review.jsp

Session Facade

Problem:

EJB clients (swing, servlets, jsps etc) can access entity beans directly. If EJB clients access entity beans directly over the network, it takes more network calls and imposes network overhead. The following figure illustrates this process:

Here in the above figure, the servlet calls multiple entity beans directly to accomplish a business process, thereby increasing the number of network calls.

Solution through Session Facade Pattern:

The solution for avoiding number of network calls due to directly accessing multiple entity beans is to wrap entity beans with session bean (Facade). The EJB client accesses session bean (Facade) instead of entity beans through coarse grained method call to accomplish a business process.

The following figure illustrates how the session facade (session bean) acts as an interceptor between client and entity beans:

Here the client makes only one coarse grained method call to session bean (facade) to process a business method instead of placing fine grained calls to entity beans. The session bean in turn calls entity beans to process client request. Entity beans can be made local by implementing EJB2.0 local interfaces to reduce remote overhead between session facade and entity beans. Therefore the session facade reduces the network traffic and increases performance.

Source:

You can get the source for this Pattern in

1. Session Facade:

Sun Java Center J2EE Patterns catalog has this Pattern as Session Facade (register and login to access this link)

http://developer.java.sun.com/developer/restricted/patterns/SessionFacade.html

2. Session Facade:

TheServerSide.com has online EJB Design Patterns book that has this Pattern as Session Facade (register and login to access this link).

http://www.theserverside.com/resources/patterns_review.jsp

Message Facade

Problem:

Session bean and entity bean methods execute synchronously that means the method caller has to wait till a value is returned. In some situations like sending hundred's of mails or firing a batch process or updating processes, the client does not have to bother about return value. If you use synchronous session and entity beans in such situations, they take a long time to process methods and clients have to wait till the method returns a value.

The following figure illustrates how session bean and entity bean methods execute synchronously:

The client has to wait till all the eight synchronous steps complete. This synchronous execution takes a long time and has an impact on performance when the method process is huge.

Solution through Message Facade Pattern:

To avoid blocking of a client, use asynchronous message driven beans, so that client does not have to wait for a return value. If a client uses asynchronous messaging then the client need not wait for a return value but can continue its flow of execution after sending the message. The following figure illustrates how a client sends a message and how a message facade (Message driven bean) processes messages asynchronously.

Here the client sends a message to JMS server, gets acknowledgement from the JMS server immediately in two step process and continues it's flow of execution. Whereas JMS server delivers the messages to Message driven bean (Message Facade) without blocking client's execution and Message driven bean executes messages. You can use normal JMS consumers instead of Message driven beans. This process improves performance by reducing the client's blocking time considerably.

Source:

You can get the source for this Pattern in two flavors

1. Service Activator:

Sun Java Center J2EE Patterns catalog has this Pattern as Service Activator (register and login to access this link)

http://developer.java.sun.com/developer/restricted/patterns/ServiceActivator.html

2. Message Facade:

TheServerSide.com has online EJB Design Patterns book that has this Pattern as Message Facade (register and login to access this link).

http://www.theserverside.com/resources/patterns_review.jsp

Value Object

Problem:

When a client calls a remote method there will be process of marshalling, network calls and unmarshalling involved for the remote method invocation. If you choose fine grained approach when calling methods remotely, there will be a significant network overhead involved. For example if you call fine grained method like this,

remoteObject.getName();

remoteObject.getCity();

remoteObject.getState();

remoteObject.getZipCode();

Here, there are four network calls from client to the remote object because every method call is remote method call.

The following figure illustrates the fine grained approach when calling methods remotely :

As seen in the above figure the fine grained approach imposes a overhead on the network due to the number of calls.

Solution through Value Object Pattern:

The solution for avoiding many network calls due to fine grained method calls is to use coarse grained approach. For example :

// create an Value Object and fill that object locally

PersonInfo person = new PersonInfo();

person.setName("Ravi");

person.setCity("Austin");

person.setState("TX");

person.zipCode("78749");

// send Value Object through network

remoteObject.getPersonInfo(person);

Here, there is only one network call instead of three network calls and PersonInfo object is a Value Object. The following figure illustrates the coarse grained approach that is passing a Value Object through network.

Value Object is an object that is passed over the network rather than passing each attributes separately thus increasing performance by reducing network calls.

Source:

You can get the source for this Pattern in

1.Value Object:

Sun Java Center J2EE Patterns catalog has this Pattern as Value Object(register and login to access this link)

http://developer.java.sun.com/developer/restricted/patterns/ValueObject.html

2.Value Object:

TheServerSide.com has online EJB Design Patterns book that has this Pattern as Value Object(register and login to access this link).

http://www.theserverside.com/resources/patterns_review.jsp

ValueObjectFactory

Problem:

For a single request, a client might need to access multiple server side components such as different session beans and entity beans. In such situations the client accesses multiple components over the network, this increases the network traffic and has an impact on the performance. The following figure illustrates this problem :

Solution through ValueObjectFacory Pattern:

To reduce the network traffic due to accessing multiple components by a client for a single request, let ValueObjectFactory hold different ValueObjects as place holders and respond with a single ValueObject for a client request. Here ValueObjectFactory holds creation and delegation logic of ValueObjects for different client requests. The following figure illustrates how ValueObjectFactory intercepts client request and delegates to different components to respond to a client request:

This Pattern reduces network calls and increases performance.

Source:

You can get the source for this Pattern in two flavors

1.Value Object Assembler:

Sun Java Center J2EE Patterns catalog has this Pattern as Value Object Assembler (register and login to access this link)

http://developer.java.sun.com/developer/restricted/patterns/ValueObjectAssembler.html

2.Value Object Factory:

TheServerSide.com has online EJB Design Patterns book that has this Pattern as Value Object Factory (register and login to access this link).

http://www.theserverside.com/resources/patterns_review.jsp

Value List Handler

Problem:

J2EE applications generally have the search facility and have to search huge data and retrieve results. If an application returns huge queried data to the client, the client takes long time to retrieve that large data and If that application uses entity bean to search data, it has an impact on performance largely because EJB by nature has an overhead when compared to normal java object (see Choosing between EJB and non-EJB and Entity bean life cycle to know overhead involved with entity beans).

This process has an impact on performance for two reasons,

1. Application returns large amount of data to the client

2. Entity beans are used to retrieve huge data.

The following figure illustrates this process.

Solution through Value List Handler Pattern:

The solution to reduce overhead due to entity beans and huge data being returned to the client is

1. Use Data Access Objects (DAO) rather than Entity beans

2. Return small quantity of data multiple times iteratively rather than returning large amount of data at once to the client.

Data Access Object encapsulates JDBC access logic. ValueListHandler caches list of Value objects that are retrieved through DAO. When client wants to search data, It calls ValueListHandler that is in turn responsible for caching data and returning data to the client iteratively. The following figure illustrates how Value List Handler intercepts client search request and returns data iteratively.

The Value List Handler Pattern improves performance significantly when the application searches huge data.

Source:

You can get the source for this Pattern in Sun Java Center J2EE Patterns catalog that has this Pattern as Value List Handler (register and login to access this link)

http://developer.java.sun.com/developer/restricted/patterns/ValueListHandler.html

Composite Entity

Problem:

Entity beans have more overhead associated than a normal java object. See Choosing between EJB vs non-EJB and Entity bean life cycle to know about overhead involed with entity beans. Entity beans are not meant for representing every persistent object in object model or table in database schema. If you convert object model or database schema into entity beans that has relationships (parent-child), it will be converted into fine grained entity beans and many entity beans will exist in your application. This approach imposes a lot of overhead on network and memory resources. The following figure illustrates this fine grained entity beans approach.

Solution through Composite Entity Pattern:

The solution is make coarse grained entity beans that is to make parent as entity bean and children as normal java objects. This coarse grained approach reduces inter entity bean communication and existence of number of entity bean in an application thus reducing overall network and memory overhead that occur due to fine grained entity beans.

The following figure illustrates how Composite Entity bean (parent bean) contains normal java objects (children) in relationship.

The Composite Entity Pattern improves performance significantly by reducing number of entity beans in an application.

Source:

You can get the source for this Pattern in Sun Java Center J2EE Patterns catalog that has this Pattern as Aggregate Entity Pattern (register and login to access this link)

http://developer.java.sun.com/developer/restricted/patterns/AggregateEntity.html

Key Points

Use ServiceLocator/EJBHomeFactory Pattern to reduce expensive JNDI lookup process.

Use SessionFacade Pattern to avoid direct client access to Entity beans thus reducing network calls.

Use MessageFacade/ServiceActivator Pattern to avoid large method execution process.

Use ValueObject Pattern to avoid fine grained method calls over network.

Use ValueObjectFactory/ValueObjectAssembler Pattern to avoid multiple network calls for a single client request.

Use ValueListHandler Pattern to avoid using Entity beans and send data iteratively to the client.

Use CompositeEntity Pattern to avoid inter Entity bean overhead.

Feed back

We appreciate and welcome your comments on this section. Email commentsZZZ@precisejavaZZZ.com (remove ZZZ which is placed to prevent spam). Please note that we may not be able to reply to all the emails due to huge number of emails that we receive but we appreciate your comments and feedback.