Core J2EE Patterns: Best Practices and Design Strategiesby Deepak Alur, Dan Malks
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
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 an Excerpt
Chapter 3: Presentation Tier Design ConsiderationsWhen 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 ManagementThe 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 ClientSaving 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.
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,
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 FieldsAlthough 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 CookiesSimilar 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.
Security Concerns of Client-Side Session StateWhen 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 TierWhen 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.
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 AccessThere 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 ViewIn 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 ViewThere 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 ViewIn 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....
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.
and post it to your social network
Most Helpful Customer Reviews
See all customer reviews >