Design patterns make for
better J2EE apps
Tutorial Details:
Design patterns make for better J2EE apps
Design patterns make for better J2EE apps
By: By Walter Hurst
Standardize the J2EE architectural layer using the Java community's accumulated knowledge
ince its inception, J2EE (Java 2 Platform, Enterprise Edition) has simplified enterprise application construction in Java. As J2EE becomes more broadly adopted, however, developers are realizing the need for defined approaches that both simplify and standardize application building. You can begin achieving that goal by standardizing your application's architectural layer.
The architectural layer generally encapsulates an application's technical complexities independent of the business logic, thereby providing a loose coupling between the business functionality and the underlying technical infrastructure. In this article, I explain an emerging method for building the application architecture for J2EE projects?one that employs design patterns to provide the standardization and simplicity that good architecture demands.
Application architecture and J2EE
J2EE is a great infrastructure technology. It provides a uniform standard for the technology stack's lower-level tasks, such as database communication or application distribution. J2EE does not, however, lead developers to build successful applications. J2EE's creators, looking down into the technology stack, wondered: "How can we standardize these APIs?" They should have looked up at the application developers and asked: "How can I give developers the building blocks they need to focus on their business application?"
When beginning a new J2EE project, some team members often ask: "If J2EE is itself an architecture, why do we need more?" Many developers held that misconception in J2EE's early days, but seasoned J2EE developers understand that J2EE fails to provide the application architecture necessary to consistently deliver high-quality applications. These developers often use design patterns to fill that gap.
Design patterns
In programming, design patterns let you leverage the developer community's collective experience by sharing problems and solutions that benefit everyone. A design pattern must capture a problem's definition and context, a possible solution, and the solution's consequences.
For the purposes of J2EE application architecture, design patterns fall into two categories: general software development patterns and those patterns that identify specific J2EE challenges. J2EE-specific design patterns identify the minimal set of known problems that a solid application architecture should solve. The former group, that of software development patterns not specific to J2EE, proves equally powerful?not for identifying problems, but for guiding architecture construction.
Let's examine each area in more detail.
J2EE design patterns
J2EE design patterns have been evolving over the last few years as the Java community has gained J2EE experience. These design patterns identify potential problems encountered when using the various J2EE-specified technologies and help developers construct an application architecture's requirements. The popular Front Controller design pattern, for example, transforms unstructured servlet code into a controller reminiscent of the refined GUI (graphical user interface) development.
J2EE design patterns identify those domain problems most likely to appear in your J2EE projects. Indeed, if the problems were rare, the design patterns would not have evolved to meet them. With that in mind, you'll benefit from addressing each domain problem in your architecture. To solve them all, create a checklist to validate your architecture for completeness. That process contrasts with the process for the software development design patterns I discuss next, as you need apply those patterns only when and if appropriate.
So where do you find J2EE design patterns? Sun Microsystems offers two books that contain many J2EE patterns:
The J2EE BluePrint Group's Designing Enterprise Applications with the Java 2 Platform (Enterprise Edition), Nicholas Kassem et al. (Addison-Wesley, 2000; ISBN: 0201702770)
The Sun Professional Services Group's Core J2EE Patterns: Best Practices and Design Strategies, Deepak Alur, John Crupi, and Dan Malks (Prentice Hall, 2001; ISBN: 0130648841)
(See Resources for links to both books.)
Beyond Sun's resources, other publications offer J2EE design pattern information, including various Java industry magazines or Websites (such as JavaWorld ), as well as numerous books. (See Resources for links to some of these sites, including JavaWorld' s Design Patterns Topical Index page.)
Software development design patterns
Also be aware of the software development design patterns, split into general object-oriented (OO) design patterns and Java-specific design patterns. The Factory pattern, for example, represents a powerful OO design pattern for encapsulating object creation to enable reuse and meet a system's changing requirements. For their part, Java-language design patterns account for Java language specifics. Some are unique to Java and are usually informal (for example, exceptions and primitives), while others are OO patterns refined to apply to Java. The famous Gang of Four book, Design Patterns by Eric Gamma et al., details numerous general software development patterns useful to all programmers.
Don't dismiss these patterns simply because they are not J2EE specific. On the contrary, such patterns can prove just as powerful, if not more so, than J2EE design patterns, because:
While the J2EE design patterns are new and evolving (because J2EE is new and evolving), the other patterns benefit from age, since the industry has had more time to review and refine them.
They often serve as the basis from which the J2EE design patterns stem.
They build the foundation upon which the J2EE-specific solutions are implemented. Constructing this foundation correctly widely affects the entire architecture's robustness and extensibility. If not constructed correctly, the foundation would minimize the architecture's usefulness regardless of how many J2EE problems it solves.
Don't make a checklist covering the software development patterns your architecture requires, as you would with the J2EE patterns. Instead, employ such patterns where appropriate based on your project's specific challenges. Many developers mistakenly believe that their products will improve if they use more patterns?or if they use all of them! That, however, is not the case. Use discretion and finesse when deciding which patterns to employ and how to use them together.
Design patterns: Where is the code?
Keep in mind that design patterns do not come with the exact implementation, or source code, you will use. Design pattern offerings range from sparse textual descriptions to rich documentation to possibly some sample code. The challenge comes in applying the patterns' powerful ideas. These ideas must be applied to the environment in which they will be used; the environment defines the correct implementation.
As an analogy, consider a design pattern for building a house's foundation. The design pattern identifies the problem, the context, and the possible solution for constructing the foundation?information immensely valuable to the construction worker in the field. The worker must still, however, build the foundation. Wouldn't that construction worker benefit more from being given the foundation (similar to the software developer being given the implementation)? Maybe this foundation would just be a slab of concrete that the house could be built on. The problem: The foundation must integrate with the house itself and the land where the house will reside. How can such a prebuilt foundation accommodate all the possible house floor plans (rectangle, square, and other odd shapes) and all the possible landscapes (on top of a hill, in the middle of a forest, and so on)?
Back in the software world, the feasibility of using prebuilt design patterns hinges on two factors:
The implementation, not individual design patterns, represents a solution. The solution could incorporate multiple design patterns, and, in doing so, would know how the individual design patterns play together.
The solution must be adaptable, which answers the final question from the analogy of the prebuilt foundation: the foundation must be able to adapt to the terrain and the floor plans. As you can imagine, it would take an extremely skilled artisan to build the adaptable foundation as opposed to the standard foundation.
Common design patterns
The table below lists some common design patterns from both J2EE sources and broader OO patterns.
Common design patterns
J2EE design patterns
Software development patterns
Session Facade
Singleton
Value Object Assembler
Bridge
Service Locator Pattern
Prototype
Business Delegate
Abstract Factory
Composite Entity
Flyweight
Value List Handler
Mediator
Service Locator
Strategy
Composite Entity
Decorator
Value Object
State
Service to Worker
Iterator
Data Access Object
Chain of Responsibility
Intercepting Filter
Model View Controller II
View Helper
Memento
Composite View
Builder
Dispatcher View
Factory Method
Let's look at two J2EE design pattern examples: the Session Facade and Value Object patterns. Both demonstrate how J2EE design patterns focus on problems particular to the J2EE environment, as opposed to the software development design patterns that generally apply to any application development effort.
Example: The Session Facade J2EE pattern
The Session Facade pattern evolved from experiences with Enterprise JavaBeans (EJBs). Systems built on the newly introduced entity EJBs (which communicate with a database) were slowing to a crawl. Performance testing revealed problems stemming from multiple network calls made when communicating with the entity EJBs, which added overhead for establishing the network connection, seri
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: Design patterns make for
better J2EE apps
View Tutorial: Design patterns make for
better J2EE apps
Related
Tutorials:
 Accelerate your Java apps! - JavaWorld - September 1998
Accelerate your Java apps! - JavaWorld - September 1998
|
Make room for JavaSpaces, Part 6 - JavaWorld October 2000
Make room for JavaSpaces, Part 6 - JavaWorld October 2000
|
Frameworks save the
day - JavaWorld September 2000
Frameworks save the
day - JavaWorld September 2000
|
J2EE project
dangers! - JavaWorld March 2001
J2EE project
dangers! - JavaWorld March 2001
|
Language improvements
and models make
great Java - JavaWorld
Language improvements
and models make
great Java - JavaWorld
|
Create email-based apps with JAMES
Create email-based apps with JAMES
|
Take control with the Proxy design pattern
Take control with the Proxy design pattern
|
Step into
the J2EE architecture and process
Step into
the J2EE architecture and process
|
Design patterns make for
better J2EE apps
Design patterns make for
better J2EE apps
|
Rumble in the
jungle: J2EE versus .Net, Part
1
Rumble in the
jungle: J2EE versus .Net, Part
1
|
Effort on the
edge, Part 1
Effort on the
edge, Part 1
|
Get the inside
track on J2EE architect certification
Get the inside
track on J2EE architect certification
|
Create client-side user interfaces in HTML, Part
2
Create client-side user interfaces in HTML, Part
2
|
To my
mind, of few interest
To my
mind, of few interest
|
Worth
reading
Worth
reading
|
good
design pattern
good
design pattern
|
Object-relation mapping without the container
If you follow the latest developer buzz then you\\\\\'ve likely heard of IOC (Inversion of Control) containers and AOP (aspect-oriented programming).
|
J2EE application performance optimization
J2EE application performance optimization
How to extract maximum performance from your J2EE Web applications
In this article, Rahul Kuchhal demonstrates how to identify and resolve bottlenecks in a J2EE application. This article covers all the step
|
Java theory and practice: Kill bugs dead
Inspection tools like FindBugs provide a second layer of defense against common coding errors.
|
A first look at Apache Geronimo
Start developing and deploying J2EE apps on the first open source J2EE server. When released, Geronimo will be the first J2EE-certified open source server. This article will give you the basics you need for developing and deploying J2EE applications on Ge
|
|
|
|
