Improve your j2ee application performace implementing proper design patterns

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.

 Dramil Dodeja

Solution via Service Locator:

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.

Dramil Dodeja

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.


  

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:

dramil dodeja

Dramil

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:

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:

Know more about pattern

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.


 

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.


 

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 Dramil Dodeja

        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.

 

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.


 

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.


 

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.

Dramil Dodeja

 Get more details with source code

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


 

 

 

 

 

 

dramildodeja.webnode.com/ >>>>>> dramildodeja.webnode.com/about-us


Dramil Dodeja - Free SourceCode | Dramil Dodeja - Google Profile | Dramil Dodeja - Java Blog | Dramil Dodeja - MSN | Dramil Dodeja - Siliconindia | Dramil Dodeja - J2ee Blog | Google India | Google USA