WebSphere - Creating a Framework

Authors: Lloyd Hagemo & Ravi Kalidindi
Contributed by Candle Corporation

Many patterns have been published for J2EE applications. By developing and connecting multiple patterns, developers can create a framework that improves the stability, performance, and scalability of their J2EE application architectures. Because the number of patterns continues to expand, it can be difficult for developers to select the best combination of patterns to create frameworks that optimize J2EE applications and fulfill specific IT or business requirements.

Similar to individual patterns, frameworks serve as development process templates that enable organizations to streamline development while ensuring high performance levels. The ability to create a solid blueprint is critical to J2EE application development success. Industry analyst Giga Information Group, Inc., reports that up to 75% of all application development projects fail due to inadequate planning, tools, training, or related factors. 

This paper includes a summary of common J2EE patterns to use as a guide when developing applications. Each pattern is typically implemented in each individual class. We have used the term “pattern” throughout the column to minimize any potential confusion between “pattern” and “class.” 

This paper also highlights four pattern frameworks designed to manage specific J2EE functions. 

Summary of J2EE Patterns

To simplify the task of identifying appropriate patterns for IT and business requirements, a list of common J2EE patterns follows. The patterns are segmented according to the following industry-accepted and functionality-based categories created by Sun Microsystems, Inc. • Presentation tier patterns: Contain patterns related to presentation components 

• Business tier patterns: Contain patterns related to business components

• Data/integration tier patterns: Contain patterns related to integration or data resources

Table 1 summarizes the basic patterns that are used in the frameworks.

Connecting J2EE Patterns

Frameworks can be designed with various combinations of patterns to address application requirements. Following are four pattern frameworks for the most common types of applications used in J2EE environments:

1. Web container pattern framework 

2. Command pattern framework

3. Session bean pattern framework

4. Entity bean pattern framework

The first two pattern frameworks are designed for simple Web applications developed with servlets and JSPs deployed in a Web container. The third and fourth pattern frameworks are used in Web and EJB containers.

The Web Container Pattern Framework

This architecture is used for database access from a Web container. The Intercepting Filter is the first point of contact for all client requests. It is used to control access and authentication. Once requests are received and filtered using the Intercepting Filter, they are forwarded to the Front Controller, which is the central dispatcher for the application. The Front Controller dispatches the request to the appropriate View Helper. A View Helper is a set of helper functions used to collect specific data. The Composite View is used to build the response to the client, and is also responsible for calling the appropriate Business Object, which calls the Data Access Object pattern to get the related data. This framework is shown in Figure 1.

Figure 1 outlines how the Web Container pattern framework is used for an inventory requirement. If a client requests a list of inventory, the Intercepting Filter checks for authentication and forwards the request to the Inventory Controller (Front Controller), which in turn dispatches the request to the Inventory Helper (View Helper). The Inventory Helper can be a normal JavaBean or a bean that will talk to the Inventory Business Object to get the appropriate inventory data. The Inventory Business Object contains business logic to process the inventory and asks the Inventory Data Access Object (DAO) to get the data from the database. The Inventory DAO contains database communication and SQL code to get the inventory-related data. This simple example shows how you can apply this pattern framework easily for inventory functionality. The advantage is that the application architecture is well documented and can be easily understood.

The Command Pattern Framework

The second framework is similar to the Web Container pattern framework, but uses the Command pattern, as shown in Figure 2. The Command pattern provides decoupling, which can make it easier to add more functionality to an application in the future. The controller requests the command, gets the results, and forwards them to the Composite View.

If you apply this framework to the Inventory example, there would be an Inventory Command pattern that contains business logic to process the inventory request. The Inventory Command pattern calls the Inventory DAO to get the related data. When using the command it is an advantage to use the Command Helper and Command Factory patterns to call and create appropriate commands.

The Session Bean Pattern Framework

The third framework adds Session Bean patterns to the Web Container pattern framework, as shown in Figure 3. While this framework adds more complexity to the architecture, using this pattern-oriented architecture allows greater flexibility for adding features to the application. Session Bean patterns are used to simplify the J2EE container development when introducing session beans in an application. The Command pattern framework can also be used instead of the Web Container pattern framework, depending on flexibility and maintenance requirements. As a Web site becomes more complex and requires handling of multiple transactions, the introduction of a command factory provides the application developer with a single location to modify existing features and introduce new functions. This allows features to be incrementally added to Web sites with little effect on the existing function.

The Business Delegate, Session Facade, Service Locator, and Value Object patterns are introduced in this framework. The View Helper pattern calls the Business Delegate pattern to delegate the request to the Session Facade pattern. The Business Delegate pattern is responsible for looking up the Session Facade pattern using the Service Locator pattern. The data is transferred from the Business Delegate pattern to the Session Facade pattern using the Value Object pattern. The Session Facade pattern calls the DAO to get the data from the persistent store. Applying this framework to the Inventory example, there will be Inventory Delegate, Inventory Facade, Service Locator, and Inventory Value Object pattern.

The Session Bean pattern framework takes full advantage of the capabilities provided by Web and J2EE containers. It provides a set of common functions that relieve the programmer of the responsibility of looking up and calling specific EJBs. Instead, this pattern framework includes a set of commonly used design patterns that  make it easier to develop EJB-based solutions.

The Entity Bean Pattern Framework

This framework (see Figure 4) adds entity bean patterns to the Session Bean pattern framework. The Entity Beans pattern can be used, as shown here, when choosing entity beans in an application. The general recommendation for entity beans is to use container-managed entity beans. This process removes the SQL from the Java code and places it in the XML definitions. The coding of SQL in XML takes time to learn and understand. This pattern also includes the Value List Handler pattern, which is very important when dealing with large database records.

We introduce the Composite Entity pattern and the Value List Handler pattern in this framework to improve the performance of the application. In this framework, the Session Facade pattern calls composite entities and/or DAOs. When dealing with large database results, the framework uses the Value List Handler pattern to send a small set of processed results iteratively to the client. The implementation of the Value List Handler framework is done using a normal Java class that contains the SQL. For example, when inventory functionality is implemented, you can have Inventory Entity and All Inventory Handler patterns.

The Inventory Entity pattern acts as a Composite Entity pattern and the All Inventory Handler pattern acts as a Value List Handler pattern to deal with a large inventory search. 

Intercepting Filter Allows handling of non–application specific services such as logging and authentication by encapsulating intercepting logic for requests and responses. An intercepting filter is typically implemented as a pluggable filter using servlet filters.

Front Controller Encapsulates all request and response control logic and avoids duplicate control logic in multiple JavaServer Pages (JSPs). One can have multiple controllers depending on application functionality. 

View Helper Separates processing logic from JSPs; puts processing logic in a reusable helper class.

Composite View Aggregates multiple subviews (e.g., header, footer, navigator, and body views) into a single composite view. It provides visibility into the View Helper pattern.

Business Delegate Decouples presentation and business tiers; also encapsulates business tier access facility and hides those details from presentation-tier classes. 

Business Object Encapsulates business logic and business data.

Command Provides a common interface to the clients and decouples presentation and business tiers.

Service Locator Encapsulates Java Naming and Directory Interface (JNDI) lookup code to look up EJB homes and other JNDI-registered services. It can cache these services to avoid redundant JNDI calls.

Session Facade Encapsulates core application business logic by calling multiple data sources or entity beans; also acts as an entity bean wrapper to avoid fine-grained method calls.

Value Object Holds the data that needs to be exchanged between clients and remote EJBs. Without the value object, clients have to make multiple method calls to get the required data.

Value Object Assembler Makes a composite value object by accessing different business components, which allows clients to get a composite value object in a single method call.

Value List Handler Iterates through a large result set and gives the client a small set of results upon each request. It can cache the subset of a large result set to improve performance.

Data Access Object Encapsulates relational database management system access code and other data sources, such as object-oriented databases. 

Composite entity Avoids inter-entity bean communication and fine grained entity beans. A composite entity bean represents a coarse-grained entity bean by having a plain Java object as the dependent object instead of another entity bean.

Conclusion

Pattern frameworks enable developers to achieve highly functional, modular architectures for their applications. They also enable developers to implement pattern oriented architectures that clearly identify where requirements can be implemented. 

We have presented four types of frameworks by connecting different patterns depending on two common types of J2EE applications. We encourage developers to leverage the power of pattern frameworks by taking the examples presented here as a base and extending them as needed, or by building new pattern frameworks that meet unique application requirements.

About the Authors:

Lloyd Hagemo is a senior director for Candle Corporation’s Application Infrastructure Management Group. He is responsible for WebSphere tools development. Lloyd has led the successful development of more than 20 products for the WebSphere environment, including operating system utilities, network performance and tuning products, WebSphere MQ configuration and management tools, and application integration solutions.

Ravi Kalidindi is a senior software engineer in Candle’s Application Infrastructure Management Group. Ravi has worked with Java since its inception and has published several articles that focus on J2EE best practices.