With the proliferation of the J2EE platform as a platform of choice for server-side applications, the need for sharing of developers’ experience and availability of reusable designs has become very crucial. In this article, we will get to know some of the reusable designs that can be used for improving the performance of a J2EE application. For the benefit of those who are not familiar with design patterns, a brief description is given at the beginning before delving into the details. For further details on design patterns in general, the reference section at the end of this article will be useful.
What are Design Patterns?
As we, the software developers, design and build different applications, we come across same or similar problem domains. This leads us to find a solution for the same / similar problem everytime, thereby we end up “reinventing the wheel” again and again. It would be good if there were a repository which discusses such common problem domains and proven solutions that are available. It will be much better if such a repository discusses such problem domains, along with a solution, that is the best suited to solve the problem on hand. Such a solution could be the result of the hands on experience of a part of the develpoment community. In the simplest term, such a common solution is a design pattern and the repository or place of reference that contains such patterns is a design pattern catalog. A design pattern prescribes a proven solution from experienced hands for a recurring design problem. Apart from describing the problem and prescribing the solution, the pattern will also explain the implementation issues involved and consequences, if any, of using the pattern. These solutions are very generic in nature. They are described in well defined “Pattern Tamplates”, the most common one in use being the template defined by the “Gang of Four”. The pattern templates usually have a name that gives a good idea as to what that pattern is all about, followed by where the pattern is applicable, the motivation, the issues in implementation etc.
Use of such patterns makes the design of an application very transaparent. These patterns have been used successfully by developers in their respective work and hence the pros and cons of use of the pattern as well as implementation issues are known before hand. All design patterns are reusable and can be adapted to particular context; this gives developers flexibility. The use of design patterns related to J2EE applications give the added advantage of giving solutions in terms of J2EE platform technologies.
Performance Optimizing Design Patterns For J2EE Applications
Before beginning to go into the details, to set expectations right, this article is not aimed at explaining the patterns with their formal template and a full blown code sample. The “J2EE Blueprints” link in the reference section will be the place of reference for those interested in such details. In this article we will look into some recurring problem domains that has a tremendous effect on the performance of a J2EE application. We will also look into a good and working solution, for each of the problem domain that we discuss, along with some important points to note and small code samples wherever applicable.
Multi-tiered J2EE applications consists of components communicating across tiers to access / change data. This often leads to remote calls between application clients/JSPs/Servlets to EJBs or between EJBs themselves. Such remote calls are costly and affect the performace of the application as a whole. Increase in the number of such remote calls increases network traffic too. Moreover, for all the advantages that EJBs offer, it comes with a price of a small overhead. The following three design patterns suggest some good solutions to minimise some of the above performance costs in typical J2EE applications.
Problem Domain
Most web applications need to display a list of data objects to the user. A financial service organization, that offers its service over the web, will have to display its catalog of services to the customer who is visiting its website. An online banking application will have to display a list of recent transactions of a customer who is checking his/her account. If an organisation has an internal web application that allows its employees to enroll for benefits over its intranet, the application should display a list of benefits available to an enquiring employee.
Lets take the financial organization’s scenario described above. To display the catalog of services, typical designs might have an EJB that represents the whole catalog. There might be a CatalogEJB that implements all required business logic related to the catalog like adding a new service to the catalog, removing an existing service, giving a list of service details to the requesting components. In the case of other components requesting a list of service details, the requesting component will have to get a reference to the CatalogEJB, access the EJB’s remote method that gets the list of services and then display, as shown below (which assumes a servlet to be the client):
CLICK HERE TO GET THE CODE:
http://www.JavaProNews.com/code.txt
Sample 1 : A Servlet that uses a CatalogEJB to read a list of objects
The above way of implementation, while providing transactional access for the required list of objects, comes attached with the price of the overheads and remote calls associated with the use of the EJB. Given that the list of services is not going to change every second, the chances of the customer seeing stale data is not much. So do we have to choose transactional access through the EJB and pay the associated price ? Extending the same argument to the other examples, given that the bank customer’s list of transactions does not change every second, do we have to have transactional access for listing the transactions ? And given that the list of benefits given by the employer does not change everyday, do we need transactional access to display the list of benefits to enquiring employees ?
Suggested Pattern
The main issue to be addressed here is whether we choose transactional access while reading a set of data that does not change rapidly. In such scenarios, the suggested pattern would be the Fast Lane Reader. Note that the problem domain, that was described, requires only read access to a set of data that does not change rapidly. We can opt to take the fast lane and read the data directly rather than opting for transactional access through EJBs. In the scenarios described in the previous section, the fast lane read will be a more efficient way to access data. Such a technique will also give faster response to the customer while running a very small risk displaying stale data. By bypassing the EJB, the overheads associated with remote calls, transaction management etc. are avoided.
Again taking the financial services scenario and the sample code explained above, one way to implement this pattern would be to have a separate object, called a Data Access Object, which encapsulates all data read and update functionality of the CatalogEJB. The code snippet below shows a sample:
CLICK HERE TO GET THE CODE:
http://www.JavaProNews.com/code2.txt
We will carry on with Mr. Ramachandrans article in our next issue.
Mr. Vijay S. Ramachandran is the author of this article.
