At JavaOne 2001, we launched "Core J2EE Patterns", which includes the pattern catalog for the Java 2 Platform, Enterprise Edition (J2EE). The catalog's 15 J2EE patterns provide solutions for problems typically encountered by architects and designers of software applications for the J2EE platform. The book also documents numerous bad practices and refactorings, and describes how to improve your existing designs. All the patterns documented in the catalog have been discovered in the field, where they have been used to create successful J2EE applications for our customers.

Patterns are about communicating problems and solutions. They enable us to document a known recurring problem and its solution in a particular context, and to communicate this knowledge to others. One impetus for writing "Core J2EE Patterns" is the fact that learning J2EE technologies is too often confused with learning to design with J2EE technologies. While many existing Java books do an excellent job of explaining specific aspects of the technology, there are few books that describe how to apply it. This is the niche we hoped to fill, relying on our field expertise as Java Architects with the Sun Professional Services Java Center.

That Was Then -- This Is Now

Since the time the first edition was published, we have received a tremendous amount of feedback on the original 15 patterns. The J2EE pattern community listserv has been very active over the last few years and now boasts over 2000 members. We have also been pleased to hear directly from so many readers at j2eepatterns-feedback@sun.com. Since the book's original publication, we have also continued to be involved in a number of significant large-scale J2EE architecture and development projects with our customers and we have continued to apply and harvest patterns.

Based on your feedback and our experience from our ongoing field work, we are launching "Core J2EE Patterns" 2nd Edition at JavaOne 2003. The original 15 patterns have been completely revised and updated, including many new implementation strategies and code samples, web services, and now covering J2EE 1.4. We have also documented 6 additional patterns, bringing the J2EE Pattern Catalog total to 21. The additional patterns aim to improve the pattern language and provide you with abstractions you can use to build and understand J2EE applications.

Pattern Catalog

We introduce 6 patterns in the new edition of our catalog, 2 in each tier:

PresentationTier

• Context Object
• Application Controller

Business Tier

• Application Service
• Business Object

Integration Tier

• Domain Store
• Web Service Broker

Figures 1, 2, and 3 show all 21 patterns in the catalog, categorized within their logical architectural tiers. Figure 4 shows a graphical realization of the pattern relationships.

Note that all the patterns have been fully revised and updated, including new implementation strategies with new code samples.

Figure 1: Presentation Tier Patterns

Figure 2: Business Tier Patterns

Figure 3: Integration Tier Patterns

Figure 4: Pattern Relationships

Selected Patterns

In this section, we excerpt small portions of several of the patterns that are new to the second edition of our book. For the full, detailed write-ups of these and all the other J2EE patterns, including detailed implementation strategies, UML diagrams, code samples, J2EE refactorings, bad practices and more please refer to " Core J2EE Patterns".

Context Object is a pattern that we see often in the field, though it has not been named and documented as part of any pattern catalog until now. Using a Context Object improves reusability, maintainability, extensibility, and testability. The following excerpts from the pattern provide the basic problem, solution and UML class diagrams, as well as the pattern's consequences.

Context Object

Problem

You want to avoid using protocol-specific system information outside of its relevant context.

An application typically uses system information, such as request, configuration, and security data, throughout the lifecycle of a request and response. Aspects of this system information are accessed based on their relevance to a certain processing context. When application-specific components and services are exposed to system information that is outside their context, flexibility and reusability of these components are reduced. Using a protocol-specific API outside its relevant context means exposing all the components that use this API to specific interface and parsing details. Each client component is then tightly coupled with that specific protocol.

Solution

Use a Context Object to encapsulate state in a protocol-independent way to be shared throughout your application.

Encapsulating system data in a Context Object, as shown in Figure 5, allows it to be shared with other parts of the application without coupling the application to a specific protocol. For example, an HTTP request parameter exists for each field of an HTML form and a Context Object can store this data in a protocol-independent manner while facilitating its conversion and validation. Then other parts of the application simply access the information in the Context Object, without any knowledge of the HTTP protocol. Any changes in the protocol are handled by the Context Object, and no other parts of the application need to change.

Figure 5: Context Object -- Class Diagram

Consequences

• Improves reusability and maintainability
  Application components and subsystems are more generic and can be reused for various types of clients, since the application interfaces are not polluted with protocol-specific data types.
• Improves testability
  Using Context Objects helps remove dependencies on protocol-specific code that might tie a runtime environment to a container, such as a web server or an application server. Testing is easier when such dependencies are limited or removed, since automated testing tools, such as JUnit [Junit] can work directly with Context Objects.
• Reduces constraints on evolution of interfaces
  Interfaces that accept a Context Object, instead of the numerous objects that the Context Object encapsulates, are less tied to these specific details that might constrain later changes. This is important when developing frameworks, but is also valuable in general.
• Reduces performance
  There is a modest performance hit, because state is transferred from one object to another. This reduction in performance is usually far outweighed by the benefits of improved reusability and maintainability of the application subcomponents.

In the Business Tier, one of the additional patterns added to the catalog for the 2nd edition of our book is Application Service, which addresses problems that arise with common business logic. Adding this common logic to Session Façades often results in the duplication of code, while encapsulating this logic within Business Objects may result in object bloat.

Application Service

Problem

You want to centralize business logic across several business-tier components and services.

Service facades, such as Session Façade or POJO Facades, contain little or no business logic and expose a simple, coarse-grained interface. Business Objects encapsulate cohesive behavior that is specific to a set of related business operations. Applications implement use cases that coordinate multiple Business Objects and services. However, you shouldn't implement use case-coordinating behavior specifically within Business Objects, because it increases coupling and reduces cohesion between these Business Objects. Likewise, you don't want to add this business logic to a service facade, because the business logic potentially gets duplicated among different facades, reducing the reusability and maintainability of common code.

Solution

Use an Application Service to centralize and aggregate behavior to provide a uniform service layer.

Application Service provides a central location to implement business logic that encapsulates Business Object and services. Implementing the business logic this way, extrinsically to the Business Object, is a one way to reduce coupling among Business Objects. With an Application Service, you encapsulate this higher-level business logic in a separate component that uses the underlying Business Objects and services.

Application Service is also used to provide a central business logic implementation layer even if you are not using Business Objects in your application. In this scenario, Application Services can include all the procedural business logic required to implement different services in your application and can use Data Access Objects when necessary to deal with persistent data.

Figure 6: Application Service

What's Next?

Context Object and Application Service are just two additions to the second edition of Core J2EE Patterns. We will cover more patterns in a future article.

We also encourage your involvement in the patterns community. The J2EE Patterns community listserv is a great place to discuss all your patterns-related issues.

Finally, we thank those of you who purchase the book, attend our presentations, contact us via email, participate on the listserv and support the patterns community in general. It is great to hear from each of you and we look forward to a continuing dialogue.

For More Information

Pre-Order the 2nd Edition at:

• Amazon