Designing J2EE Applications
In designing J2EE applications, care must be taken to avoid many recurring problems, most of which are related to optimizing remote calls between client and the requesting service. For example, fulfilling a request by making one trip to the database is much more efficient than making several trips. This enhances the network traffic and optimizes repeated resource allocations. These recurring problems and issues in designing applications are gathered and documented in a catalog of design patterns.
Patterns are typically written in a structured format. A design pattern is identified by a name, problem statement, and the solution to that problem. Design patterns are developed to prevent reinventing the wheel; therefore, they are reusable artifacts. They exist at different levels of abstraction, and they communicate designs and best practices. In enterprise applications, you can join design patterns together to solve a larger problem.
By now, you have already been introduced to the MVC design pattern. Today, you'll learn few more patterns that can be applied in designing J2EE applications.
Note
For more details about a large catalog of design patterns, refer to the classic book, Design Patterns: Elements of Reusable Object-Oriented Software, by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (ISBN 0-201-63361-2). These four authors are also known as the GOF (Gang of Four).
Session Façade Design Pattern
The J2EE specification doesn't restrict access to entity beans by any client components. EJB clients, such as Java applications from the client tier, and servlets and JSP from the Web tier, can have direct access to entity beans. Access of entity beans directly over the network takes more remote calls and imposes network overhead. Again, in minimizing remote calls, a session bean can be used as a façade in the EJB tier to mediate access on behalf of the client (see Figure 15.6).
Figure 15.6. Session façade pattern
An EJB client accesses the session bean (Façade) instead of entity beans through a coarse-grained method call to accomplish a business process. Wrapping entity beans with a Session Façade reduces network traffic, which is reflected in positive performance.
Service Locator Design Pattern
The Service Locator pattern addresses the issue of the usage of JNDI to look up different resources and services. These resources can be any of the EJBHome objects, DataSource objects, or JMS ConnectionFactory objects. Each lookup is an expensive remote call in terms of network traffic. To minimize remote calls, a service locator object is created locally to maintain a cache of these service objects (see Figure 15.7).
Figure 15.7. Service Locator pattern.
Any lookup for a JNDI remote object is done only the first time; subsequent lookups access the local cache of service objects.
Message Façade Design Pattern
Because methods of both session and entity beans are executed synchronously, a client method call has to wait until a value is returned. Some e-commerce applications, such as checking a customer's credit, require waiting for an approval before proceeding. Using synchronous session or entity beans in such situations will not be efficient because the client has to wait for a reply. This situation can be resolved by using a message-driven bean, waiting for a reply, and delivering it to the client through an e-mail (see Figure 15.8).
Figure 15.8. Message façade pattern.
Using message-driven beans implies the use of the JMS product, which is assumed as part of the enterprise infrastructure.
Value Object Design Pattern
The Value Object design pattern is used to transfer remote, fine-grained data by sending a coarse-grained or bulk view of that data.
Note
We briefly discussed the concept of a data bean, during the discussion of JavaBeans on Day 7. A data bean is a typical implementation of this pattern.
The main advantage of this pattern is to make one trip to the remote EJB tier, and bring a coarse-grained (bulky) object of data to the local machine. Again, this reduces network traffic, and enhances your application performance (see Figure 15.9).
Figure 15.9. Value object pattern.
