Core J2EE Patterns: Best Practices and Design Strategies

Core J2EE Patterns: Best Practices and Design Strategies

by Deepak Alur, Dan Malks
     
 

View All Available Formats & Editions

Over the last few years, Java 2 Platform, Enterprise Edition (J2EE) technology has emerged and matured as a standard platform for building enterprise applications. While the platform has matured into a solid offering for developing and deploying enterprise applications, it does offer its challenges. As developers, often we confuse learning the technology with

…  See more details below

Overview

Over the last few years, Java 2 Platform, Enterprise Edition (J2EE) technology has emerged and matured as a standard platform for building enterprise applications. While the platform has matured into a solid offering for developing and deploying enterprise applications, it does offer its challenges. As developers, often we confuse learning the technology with learning to design with the technology. In this book, senior architects from the Sun Java Center, Sun's Java consulting organization share with the reader their cumulative design experience with and expertise on J2EE technology.

The primary focus of the book is on patterns, best practices, design strategies, and proven solutions using the key J2EE technologies including JavaServer Pages (JSP), Servlets, Enterprise Java Beans (EJB), and Java Message Service (J.M.S) API. Other ancillary technologies like JDBC and JNDI are also discussed as relevant to their usage in these patterns. The J2EE Patterns catalog with 16 patterns and numerous strategies is presented to document and promote best practices for these technologies.

In addition to the patterns and strategies, the book offers the following:

  • Presents various design strategies for the presentation tier and business tier design.
  • Identifies bad practices in presentation, business, and integration tiers, and offers directions to remedy them by using certain patterns, strategies, and refactorings.
  • Refactorings for various tiers and mechanics to move away from a bad implementation to a better solution.
  • Sample code and examples for patterns, strategies, and refactorings.

Core J2EE Patterns delivers:

  • Proven solutions for enterprise applications
  • J2EE Patterns Catalog with patterns for JSP technology, EJB technology, and J.M.S.
  • Identifies bad practices and recommends solutions
  • Refactorings to improve existing designs using patterns, strategies, and best practices
  • UML Diagrams illustrate structure and behavior of each pattern

Read More

Editorial Reviews

Presents 15 patterns for the Java 2 platform enterprise edition (J2EE) that solve problems typically encountered by application developers. Patterns include a data access object, a front controller for handling requests, and a business delegate to reduce coupling between presentation-tier clients and business services. The authors, who are architects with the Sun Java Center, also discuss some design considerations for Java server pages, servlets, and enterprise Javabeans. Annotation c. Book News, Inc., Portland, OR (booknews.com)

Product Details

ISBN-13:
9780130648846
Publisher:
Prentice Hall Professional Technical Reference
Publication date:
06/26/2001
Series:
Core Series
Edition description:
Older Edition
Pages:
496
Product dimensions:
7.04(w) x 9.24(h) x 1.35(d)

Read an Excerpt

Chapter 3: Presentation Tier Design Considerations

When developers apply the presentation patterns that appear in the catalog in this book, there will be adjunct design issues to consider. These issues relate to designing with patterns at a variety of levels, and they may affect numerous aspects of a system, including secu-rity, data integrity, manageability, and scalability. We discuss these issues in this chapter.

Although many of these design issues could be captured in pattern form, we chose not to do so because they focus on issues at a lower level of abstraction than the presentation patterns in the catalog. Rather than documenting each issue as a pattern, we have chosen to document them more informally: We simply describe each issue as one that you should consider when implementing systems based on the pattern catalog.

Session Management

The term user session describes a conversation that spans multiple requests between a client and a server. We rely on the concept of user session in the discussion in the following sections.

Session State on Client

Saving session state on the client involves serializing and embedding the session state within the view markup HTML page that is returned to the client.

There are benefits to persisting session state on the client:

  • It is relatively easy to implement.
  • It works well when saving minimal amounts of state.
Additionally, this strategy virtually eliminates the problem of replicating state across servers in those situations that implement load balancing across physical machines.

There are two common strategies for saving session state on the client HTML hidden fields and HTTP cookies—and we describe these strategies below. A third strategy entails embedding the session state directly into the URIs referenced in each page (for example, <form action=someServlet?var1=x&var2=y method=GET>). Although this third strategy is less common, it shares many of the limitations of the following two methods.

HTML Hidden Fields
Although it is relatively easy to implement this strategy, there are numerous drawbacks to using HTML hidden fields to save session state on the client. These drawbacks are especially apparent when saving large amounts of state. Saving large amounts of state negatively affects performance. Since all view markup now embeds or contains the state, it must traverse the network with each request and response.

Additionally, when you utilize hidden fields to save session state, the persisted state is limited to string values, so any object references must be "stringified". It is also exposed in clear text in the generated HTML source, unless specifically encrypted.

HTTP Cookies
Similar to the hidden fields strategy, it is relatively easy to implement the HTTP cookies strategy. This strategy unfortunately shares many of the same drawbacks as well. In particular, saving large amounts of state causes performance to suffer, because all the session state must traverse the network for each request and response.

We also run into size and type limitations when saving session state on the client. There are limitations on the size of cookie headers, and this limits the amount of data that can be persisted. Moreover, as with hidden fields, when you use cookies to save session state, the persisted state is limited to stringified values.

Security Concerns of Client-Side Session State

When you save session state on the client, security issues are introduced that you must consider. If you do not want your data exposed to the client, then you need to employ some method of encryption to secure the data.

Although saving session state on the client is relatively easy to implement initially, it has numerous drawbacks that take time and thought to overcome. For projects that deal with large amounts of data, as is typical with enterprise systems, these drawbacks far outweigh the benefits.

Session State in the Presentation Tier

When session state is maintained on the server, it is retrieved using a session ID and typically persists until one of the following occurs:
  • A predefined session timeout is exceeded.
  • The session is manually invalidated.
  • The state is removed from the session.
Note that after a server shutdown, some in-memory session management mechanisms may not be recoverable.

It is clearly preferable for applications with large amounts of session state to save their session state on the server. When state is saved on the server, you are not constrained by the size or type limitations of client-side session management. Additionally, you avoid raising the security issues associated with exposing session state to the client, and you do not have the performance impact of passing the session state across the network on each request.

You also benefit from the flexibility offered by this strategy. By persisting your session state on the server, you have the flexibility to trade off simplicity versus complexity and to address scalability and performance.

If you save session state on the server, you must decide how to make this state available to each server from which you run the application. This issue is one that requires you to deal with the replication of session state among clustered software instances across load-balanced hardware, and it is a multidimensional problem. However, numerous application servers now provide a variety of out-of-the-box solutions. There are solutions available that are above the application server level. One such solution is to maintain a "sticky" user experience, where you use traffic management software, such as that available from Resonate [Resonate], to route users to the same server to handle each request in their session. This is also referred to as server affinity.

Another alternative is to store session state in either the business tier or the resource tier. Enterprise JavaBeans components may be used to hold session state in the business tier, and a relational database may be used in the resource tier. For more information on the business-tier option, please refer to "Using Session Beans" on page 55.

Controlling Client Access

There are numerous reasons to restrict or control client access to certain application resources. In this section, we examine two of these scenarios.

One reason to restrict or control client access is to guard a view, or portions of a view, from direct access by a client. This issue may occur, for example, when only registered or logged-in users should be allowed access to a particular view, or if access to portions of a view should be restricted to users based on role.

After describing this issue, we discuss a secondary scenario relating to controlling the flow of a user through the application. The latter discussion points out concerns relating to duplicate form submissions, since multiple submissions could result in unwanted duplicate transactions.

Guarding a View

In some cases, a resource is restricted in its entirety from being accessed by certain users. There are several strategies that accomplish this goal. One is including application logic that executes when the controller or view is processed, disallowing access. A second strategy is to configure the runtime system to allow access to certain resources only via an internal invocation from another application resource. In this case, access to these resources must be routed through another presentation-tier application resource, such as a servlet controller. Access to these restricted resources is not available via a direct browser invocation.

One common way of dealing with this issue is to use a controller as a delegation point for this type of access control. Another common variation involves embedding a guard directly within a view. We cover controller-based resource protection in "Presentation Tier Refactorings" on page 73 and in the patterns catalog, so we will focus here on view-based control strategies. We describe these strategies first, before considering the alternative strategy of controlling access through configuration.

Embedding Guard Within View
There are two common variations for embedding a guard within a view's processing logic. One variation blocks access to an entire resource, while the other blocks access to portions of that resource.

Including an All-or-Nothing Guard per View
In some cases, the logic embedded within the view processing code allows or denies access on an all-or-nothing basis. In other words, this logic prevents a particular user from accessing a particular view in its entirety. Typically, this type of guard is better encapsulated within a centralized controller, so that the logic is not sprinkled throughout the code. This strategy is reasonable to use when only a small fraction of pages need a guard. Typically, this scenario occurs when a nontechnical individual needs to rotate a small number of static pages onto a site. If the client must still be logged into the site to view these pages, then add a custom tag helper to the top of each page to complete the access check, as shown in Example 3.1....

Read More

Meet the Author

Deepak Alur is an Enterprise Java Architect with the Sun Java Center. He has over 12 years of experience in the software industry. He has been focused on design and implementation of enterprise applications using Object-Oriented technologies, patterns, Java technology, and J2EE technology.

John Crupi is the Chief Java Architect of the Sun Java Center. He has over 15 years of experience in distributed object computing and remains focused on creating reusable, scalable architectures for J2EE technology. He is also a JavaReport columnist for the Architect's Corner.

Dan Malks is an Enterprise Java Architect with the Sun Java Center. He has over 14 years of experience in the software industry and focuses on Object-Oriented technologies. He has been published in numerous industry periodicals and books on Java technology, J2EE technology, and patterns.

Customer Reviews

Average Review:

Write a Review

and post it to your social network

     

Most Helpful Customer Reviews

See all customer reviews >