Java Reference
In-Depth Information
However, J2EE was not perfect. Soon enough, the complex structure of the platform with its heavy
use of XML coni gurations created the perfect problem‐ridden environment.
The Emergence of Enterprise Java Patterns
The complex programming models of J2EE soon led many projects into deep waters. Applications
developed with J2EE technologies tended to contain excessive amounts of “plumbing” code such as JNDI
lookup code, XML coni guration i les, and try/catch blocks that acquired and released JDBC resources.
Writing and maintaining such code proved a major drain on resources and was the source of many bugs
and performance issues. The EJB component model aimed to reduce complexity when implementing
business logic, but it did not succeed in this aim. The model was simply too complex and often overused.
After just a few years from the i rst release at the JavaOne conference in 2000, Deepak Alur, John
Crupi, and Dan Malks gave a talk titled “Prototyping Patterns for the J2EE Platform,” which
introduced several patterns targeted at common problems experienced in the design of J2EE
applications. This talk would become a book. The following year, they published a book called
Core J2EE Patterns: Best Practices and Design Strategies
.
4
In addition to the 15 already well‐known
patterns, the authors introduced 6 new J2EE design patterns. The new patterns included Context
Object and Application Controller for the Presentation tier, Application Service and Business Object
for the Business tier, and Domain Store and Web Service Broker for the Integration tier.
Some of those patterns evolved from the “classic” GoF patterns, whereas others were new and
addressed the l aws of J2EE. In the following years, several projects and frameworks such as Apache
Camel were released that made the life of enterprise developers easier. Even some, led by Rod
Johnson,
5
made a bold step by moving away from J2EE and releasing the Spring Framework. Spring
soon became popular, and its popularity inl uenced great changes in the new programming model
behind Java EE. Today most of those patterns are still valid and in use. However, some are obsolete
and no longer required thanks to the simplii ed programming model of Java EE.
Design Patterns Versus Enterprise Patterns
Enterprise patterns differ from design patterns in that enterprise patterns target enterprise software
and its problems, which greatly differ from the problems of desktop applications. A new approach,
Service Oriented Architecture (SOA), introduced several principals to follow when building well‐
organized, reusable enterprise software. Don Box's
6
four tenets of SOA formed the basis of these
fundamental principles. That set of principles addressed common needs of enterprise projects.
DON BOX'S FOUR TENETS OF SOA
1. Boundaries are explicit. 2. Services are autonomous. 3. Services share schema
and contract, not class. 4. Service compatibility is determined based on policy.
However, “classical” patterns still have something to offer. With the release of Java EE 5, Enterprise
Java was back in the spotlight, something that third‐party frameworks such as Spring and Struts
had hogged for too long. The release of Java EE 6 was an even greater step forward and made the
platform more competitive.
