Introducing Enterprise Java Application Architecture and Design
Simplifying Application Design with Patterns
Application design can be immensely simplified by applying Java EE design patterns. Java EE design patterns have been documented in Sun's Java Blueprints (http://java.com/reference/blueprints) and also in the book Core J2EE Design Pattern (Prentice Hall, 2003). They are based on fundamental object design patterns, described in the famous book Design Patterns: Elements of Reusable Object-Oriented Software (Addison Wesley, 1994). These patterns are also called Gang of Four (GOF) patterns because this book was written by four authors: Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides. The Java EE patterns catalog also takes into the account the strategies to meet the challenges of remotely accessible distributed objects besides the core object design principles.
Design patterns describe reusable solutions to commonly occurring design problems. They are tested guidelines and best practices accumulated and documented by experienced developers and designers. A pattern has three main characteristics:
- The context is the surrounding condition under which the problem exists.
- The problem is the difficult and uncertain subject area in the domain. It is limited by the context in which it is being considered.
- The solution is the remedy for the problem under consideration.
However, every solution to a problem does not qualify it as a pattern. The problem must be occurring frequently in order to have a reusable solution and to be considered as a pattern. Moreover, patterns must establish a common vocabulary to communicate design solutions to developers and designers. For example, if someone is referring to the GOF Singleton pattern, then all parties involved should understand that you need to design an object that will have only a single instance in the application. To achieve this design pattern, its description is often supplemented by structural and interaction diagrams as well as code snippets. Last but not least, each pattern description generally concludes with a benefit and concern analysis.
The Java EE Design Pattern Catalog
As stated earlier, Java EE has been the dominant enterprise development platform for nearly ten years. Over this period, thousands of successful applications and products have been built using this technology. But some endeavors have failed as well. There are several reasons for such failures, of which the foremost is inadequate design and architecture. This is a critical area because design and architecture is the bridge from requirements to the construction phase. However, Java EE designers and architects have learned their lessons from both failures and successes by drawing up a list of useful design patterns. This Java EE patterns catalog provides time-tested solution guidelines and best practices for object interaction in each layer of a Java EE application.
Just like the platform itself, the Java EE patterns catalog has evolved over time. As discussed earlier, this catalog was first formed as part of Sun's Java BluePrints and later elaborated on in the book Core J2EE Design Pattern (Prentice Hall, 2003). Table 1 presents the patterns with a brief description of each and its associated layer.
Table 1. Java EE Spring Patterns Catalog
| Layer | Pattern Name | Description |
|---|---|---|
| Presentation | View Helper | Separates presentation from business logic |
| Composite View | Builds a layout-based view from multiple smaller subviews | |
| Front Controller | Provides a single point of access for presentation tier resources | |
| Application Controller | Acts as a front controller helper responsible for the coordinations with the page controllers and view components. | |
| Service to Worker | Executes business logic before control is finally passed to next view | |
| Dispatcher View | Executes minimal or no business logic to prepare response to the next view | |
| Page Controller | Manages each user action on a page and executes business logic | |
| Intercepting filters | Pre- and post-processes a user request | |
| Context Object | Decouples application controllers from being tied to any specific protocol | |
| Business | Business Delegate | Acts as a bridge to decouple page controller and business logic that can be complex remote distributed object |
| Service Locator | Provides handle to business objects | |
| Session Facade | Exposes coarse-grained interface for entry into business layer for remote clients | |
| Application Service | Provides business logic implementation as simple Java objects | |
| Business Interface | Consolidates business methods and applies compile-time checks of EJB methods | |
| Integration | Data Access Object | Separates data access logic from business logic |
| Procedure Access Object | Encapsulates access to database stored procedure and functions | |
| Service Activator (aka Message Facade) | Processes request asynchronously | |
| Web Service Broker | Encapsulates logic to access external applications exposed as web services standards |
Table 1 is slightly altered based on the current state of Java EE. The Data Transfer Object pattern, for instance, no longer finds its place in the catalog and therefore is not listed. This pattern was used transfer data across layer and was especially useful if you used remote entity bean persistence components. But with the new Java Persistence API (part of the Java EE 5 platform) and general trend for plain old Java object (POJO) programming models, this pattern is no longer relevant.
This table is far from complete. Certain patterns can be applied across tiers. Security design patterns, for example, can be applied in the presentation layer to restrict access to web resources such as JSPs. Similarly, security patterns can be used to control method invocation on business layer EJB components. Transactional patterns, for example, can be applied at both the business and integration layers. These patterns are classified as cross-cutting patterns.
Java EE Architecture and Design with UML
Most modern-day applications are developed iteratively. The system grows gradually as more and more requirements become available. The core of such systems is a high-level design and architecture that evolves through iterations. It is also imperative that design and architecture are documented in both text and visual forms for the benefit of the development and maintenance teams. The visual representation is immensely useful because it helps developers understand runtime interactions and compile-time dependencies.
Page 5 of 7
This article was originally published on March 3, 2009