This podcast examines how to use design patterns to facilitate the design of J2EE applications.

Design Patterns allow developers to document a particular problem, return a context-based solution, and share this information with others. Patterns try to reflect a conceptual trend over time. Many theorists have defined and redefined the concept of a software pattern – these definitions, however, all conclude that patterns relate to the recurrence of a problem/solution pair in a particular context.

Patterns can be applied at different levels of abstraction and so fall into a number of categories including

• analysis

• architectural

• behavioral

• creational

• design

• structural

The majority of J2EE patterns fall somewhere between design patterns and architectural patterns. However, all J2EE patterns are classified within three logical architectural tiers:

• presentation

• business

• integration

There are many benefits in applying design patterns to a project. First, a pattern is a proven solution to a particular problem. Pattern-use saves developers and architects time, as they can use a proven solution rather than trying to create an original solution every time they encounter a particular problem.

Second, software designers have access to a common language. Designers can easily communicate their ideas to other designers by using a shared vocabulary.

Third, pattern application places a limit on a solution space. Designers are aware that they must operate within constraints – otherwise, anti-pattern behaviors develop.

J2EE applications support a range of clients. J2EE clients run on a number of platforms including laptops, desktops, palmtops, and cell phones. These clients can connect through an intranet, the Internet, a wireless network, a wired network, or a combination of wired and wireless networks. Clients can be thin, server-dependent, and browser-based or rich and stand-alone. Applications designers must make a couple of key design decisions regarding clients. They need to decide which type of client best suits their requirements. They also need to decide whether to allow access to the application by more than one type of client.

A number of other issues should be examined when designing the client tier. These issues include network, security, and platform considerations. You should remember that a client is network-dependent and that networks are unreliable. Ideally, the client should connect to the network on an ad-hoc basis, transmit the minimum amount of data necessary, and function quite well when the server is inaccessible. Client connection is impacted by network-security requirements. For example, external firewalls limit the number of protocols a client can use. Platform considerations influence client-design. For example, a mobile device would be unable to display a huge volume of data.

The J2EE platform favors thin-client architectures. However, a J2EE client will need to deal with a range of design issues including the ability to:

• contain logic for user interface presentation

• validate user inputs

• communicate with the server using a common protocol

• maintain the conversational state

Browser Clients – Design Issues

Browser clients receive all their presentation logic from web servers and cannot function independently of the server. Browser clients are relatively easy to design and implement. Browsers are widely available, and their interfaces are familiar to many users, but the functionality they provide to the user is limited.

Browser clients can perform some user interface validation, typically by using JavaScript. Validating user input on the client side reduces the validation workload on the server, but the amount of validation code that needs to be downloaded can be substantial.

The HTTP request-response mechanism is used for communications between browser client and server when browser clients connect to a J2EE application over the Web.

Web-based applications need to maintain conversational or session state for individual clients. Browsers can use cookies or URL rewriting to maintain session state. Both mechanisms are open to unauthorized access. Therefore, it is recommended that servers should maintain conversation state for browsers.

Java Clients – Design Issues

Java clients fall into three categories:

• applications

• applets

• MIDlets

Application clients are similar to standard desktop applications in that they depend less on servers than browser clients. Applet clients are now rarely used. These user-interface components run for the most part in a web browser. MIDlet clients are small applications that are used for cell phones, two-way pagers, and palmtops.

Java application and applet clients can use the Java Foundation Classes/Swing API to create sophisticated user interfaces. Java MIDlets can use the MIDP User Interface API. This is designed to cope with the limited data-input capabilities of current mobile technologies. Java applications are difficult to program, but they offer a much richer user experience. Java clients are also more responsive than thin clients and can even be used offline. Java clients use less bandwidth than a browser client that requests the same data. They can also be programmed to make fewer connections than a browser client to a server.

Java clients can be designed to handle most of the user-input validation, preventing invalid data from reaching the server in the first place and reducing the network overhead of validation calls between the client and server. Java clients are flexible in the way they can connect to J2EE applications and can connect directly to the web, Enterprise JavaBeans (EJB), and Enterprise Information System (EIS) tiers.

Java clients that connect to the web tier of a J2EE application do this using the HTTP protocol. This, however, introduces complexity because of the need to translate between HTTP requests and responses and application events. Fortunately, EJB clients do not need to be programmed to perform these functions, because the clients connect to the EJB tier directly using Remote Method Invocation (RMI) calls. However, there are restrictions on EJB clients. First, applet and application clients are the only Java clients that can access EJBs directly. Second, you cannot use an EJB client when a firewall is in place that separates a server and its clients. Although Java clients can access the EIS tier directly, it is not recommended because it would bypass the business logic and transaction management on the J2EE server.

Finally, Java clients have the facility to cache and manipulate large amounts of state in memory and can therefore manage session state independently. This is advantageous when latency is high or when each connection expends significant bandwidth. It is important to remember that the server has the power to enforce business rules regardless of a client's actions. Applications also need to enforce data synchronization schemes when Java clients manipulate enterprise data.

The purpose of the web tier within a J2EE application is to manage the interaction between web clients and the application's business logic. This tier normally produces HTML or XML content, although it can generate and serve any type of content. Business logic can be implemented entirely within this tier, although it is recommended to use enterprise beans for this task.

Servlets and JSPs

Java Servlets (servlets) and JavaServer Pages (JSP pages) are web-tier component technologies. Although they both return dynamic content in response to user requests, they are suited to different purposes.

Servlets should be used to

• implement web-application logic

• generate binary content

• act as a web-tier controller

Servlets should not be used to generate static HTML text – JSP pages are better suited for this purpose. JSP pages should be used to produce structured textual content, generate XML messages in a standard format, and act as templates that assemble textual data from multiple sources.

When using JSP pages, it is recommended to use custom tags instead of scriptlets because :

• scriptlet code appears in only one place, so it is not easily reusable

• scriptlets mix programming with web content

• scriptlets make JSP pages difficult to read and update

• scriptlet errors can be difficult to interpret

• scriptlet code is difficult to test on a unit-by-unit basis

Web-Tier Application Frameworks

Web-tier applications have a number of common requirements that are not met by the actual J2EE platform. An application framework or software layer can meet these requirements and be used by many different applications. This application framework resides on top of the J2EE platform. It performs a number of functions such as dispatching requests, invoking model methods, and compiling views. Application developers can use this structural framework to extend, use, or implement framework classes and interfaces to perform a range of application-oriented functions. It is recommended that you use a ready-built web-tier application framework for a J2EE application rather than designing an original framework layer. Three ready-made frameworks that you might consider using include:

• J2EE BluePrints Web Application Framework (WAF)

• Apache Struts

• JavaServer Faces

Model View Controller (MVC)

The MVC design pattern works well for interactive applications such as web applications. MVC divides an application into three separate modules. The first module contains data representation and business logic. The second module contains views that provide data presentation and user input. The third module contains a controller that sends requests and controls information flow. Most web-tier application frameworks use the MVC pattern.

The benefits of MVC include a number of design benefits, including

• the separation of design and implementation efforts

• decreased code duplication

• centralized control of application services

• a more easily altered application

MVC is particularly applicable to web applications because servlets are ideal for implementing web-tier controllers. Controller servlets receive all incoming client requests and direct them to the appropriate business-logic component. When the request is processed, the controller then selects the correct view to return to the client.

Model 1 and Model 2

Model 1 and Model 2 are web-application usage patterns that refer to the absence or presence of a controller servlet. A Model 1 application accesses web-tier JSP pages directly via a browser. The application is decentralized, and the pages display statically. A Model 2 architecture introduces a controller servlet between the browser and the JSP pages being delivered.

Model 2 applications are favored because they are easy to maintain and extend and provide a single port of call for security and logging. However, Model 1 is a simpler design option for smaller, static applications.

The EJB tier hosts the business logic of a J2EE application and provides system-level services to the business components. This model allows developers to focus on business-logic problems while the J2EE platform handles more complex system-related problems. The EJB container solves a lot of the problems typically encountered by business components. These problems include state maintenance, transaction management, and availability to local and remote clients.

Business components, or EJBs, form a vital link between presentation components situated in the web-tier and business data and systems that reside in the EIS tier. There are three types of EJB – entity, session, and message-driven.

Remote And Local Interfaces

When implementing enterprise beans, you need to decide whether to use local or remote interfaces. An enterprise bean typically provides a remote client view because they are designed for use in a distributed environment. Remote method calls are hard on network resources and can have performance limitations. And the same overhead is incurred even if the client and bean reside in the same Java Virtual Machine (JVM).

These design limitations can be minimized through good design. For instance, you can use a local client to avoid the performance overhead of RMI. However, for this to work properly, the enterprise bean and its clients must reside in the same JVM.

You should consider using local interfaces when

• a session or entity bean needs to be located in the same container as its clients

• a bean and its clients should be tightly coupled

• the parameters passed between a bean and its client require pass-by-reference semantics

• entity beans provide fine-grained access to underlying data objects

Entity-Bean Decisions

There are a number of factors to consider before deciding to model a business object as an entity bean.

You should model a business object as an entity bean when

• a business object represents persistent data and requires persistent storage

• accessing an object by a unique identity is pertinent to an application

• multiple clients need equal access to the state and behavior of a business object

• persistent data needs to be accessed in a portable manner

• query capability is pertinent

• server-managed transaction handling is preferable

When you use entity beans, you also need to decide whether to manage persistence yourself or to allow the EJB container to manage persistence for the bean.

Session-Beans Decisions

Session beans can be stateless or stateful, so you need to decide which to use. A stateful session bean works on behalf of the client to maintain conversational state. You should model a business object as a stateful session bean when you want to represent client-centric business logic and when business objects are relatively short-lived and non-persistent.

Stateless Session Beans

Stateless session beans are used to provide server-side behavior. They do not maintain state information for a specific client. You should model a business object as a stateless session when you are modeling reusable service objects, when you wish to minimize resources and support a large number of clients, and when a business object does not operate on instance variables.

The EIS stores data for enterprise applications. EISs include enterprise-resource planning systems, relational databases, mainframe transaction processing systems, and other database systems. EISs must be integrated with the J2EE applications that use their data. The J2EE platform addresses this concern by providing various EIS technologies. Some of these technologies include

• the J2EE Connector Architecture, which is a standard architecture that integrates J2EE applications with existing EISs using resource adapters that can be plugged into J2EE servers

• Java Message Service, which is a Java API defined for use with enterprise messaging systems

• JDBC which integrates J2EE applications with relational database systems

EIS integration approaches can be divided into four categories:

• data integration using either JDBC or the connector architecture

• asynchronous, message-based integration using JMS

• tightly-coupled, synchronous integration using the connector architecture

• legacy connectivity using the connector architecture

Synchronous and asynchronous integration approaches are viable for EIS integration. Asynchronous systems are suitable for delivering a high-quality and reliable message-delivery service and can also provide a higher volume of messaging. However, this approach requires more work from developers. A synchronous approach is more suitable when handling two or more EISs synchronously.

Summary

Design patterns enable developers to record a specific problem, return a context-based solution, and share this information with others. The majority of J2EE patterns fall somewhere between design patterns and architectural patterns. There are many benefits to applying design patterns to a project. When designing the client tier, the web tier, the EJB tier, and the EIS tier, there is a range of options available to the designer. The designer will have to consider systems requirements and balance potential benefits against potential trade offs.