- Shopping Bag ( 0 items )
Ships from: acton, MA
Usually ships in 1-2 business days
"The Java landscape is littered with libraries, tools, and specifications. What's been lacking is the expertise to fuse them into solutions to real-world problems. These patterns are the intellectual mortar for J2EE software construction."
--John Vlissides, co-author of Design Patterns, the "Gang of Four" book
"The authors of Core J2EE Patterns have harvested a really useful set of patterns. They show how to apply these patterns and how to refactor your system to take advantage of them. It's just like having a team of experts sitting at your side."
--Grady Booch, Chief Scientist, Rational Software Corporation
"The authors do a great job describing useful patterns for application architectures. The section on refactoring is worth the price of the entire book!"
--Craig McClanahan, Struts Lead Architect and Specification Lead for JavaServer Faces
"Core J2EE Patterns is the gospel that should accompany every J2EE application server...Built upon the in-the-trenches expertise of its veteran architect authors, this volume unites the platform's many technologies and APIs in a way that application architects can use, and provides insightful answers to the whys, whens, and hows of the J2EE platform."
--Sean Neville, JRun Enterprise Architect, Macromedia
Developers often confuse learning the technology with learning to design with the technology. In this book, senior architects from the Sun Java Center share their cumulative design experience on Java 2 Platform, Enterprise Edition (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(TM) (JSP(TM)), Servlets, Enterprise JavaBeans(TM) (EJB(TM)), and Java(TM) Message Service (JMS) APIs. The J2EE Pattern Catalog with 21 patterns and numerous strategies is presented to document and promote best practices for these technologies.
Core J2EE Patterns, Second Edition offers the following:
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.
There are benefits to persisting session state on the client:
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.
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.
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.
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.
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.
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.
Foreword Grady Booch.
Foreword Martin Fowler.
I. PATTERNS AND J2EE.
2: Presentation Tier Design Considerations and Bad Practices.
3: Business Tier Design Considerations and Bad Practices.
4: J2EE Refactorings.
II. J2EE PATTERN CATALOG.
5: J2EE Patterns Overview.
6: Presentation Tier Patterns.
7: Business Tier Patterns.
8: Integration Tier Patterns.
The Apache Software License, Version 1.1
This book is about patterns for the Java 2 platform, Enterprise Edition (J2EE). These J2EE patterns provide solutions for problems typically encountered by designers of software applications for the J2EE platform. 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.
This book describes proven solutions for the J2EE platform with a particular emphasis on such key J2EE technologies as: Java Server Pages (JSP), Servlets, Enterprise JavaBeans (EJB) components, Java Message Service (JMS), JDBC, and Java Naming and Directory Interface (JNDI). We offer solutions for recurring problems for the J2EE platform through the J2EE pattern catalog and J2EE refactorings. You can apply these ideas when developing new systems or when improving the design of existing systems. The patterns in this book will help you quickly gain the proficiency and skills to build robust, efficient enterprise applications.
Today, as in the past, many of us naively assume that learning a technology is synonymous with learning to design with the technology. Certainly learning the technology is an important part to being successful in designing with the technology. Many existing Java books are excellent at explaining technology details, such as API specifics and so forth, but at the same time they give no insight on applying the technology. Learning to design comes from experience and from sharing knowledge on best practices and bad practices.
The experiences we have conveyed in this book are derived from the work we have done in the field. We are part of Sun Microsystems, Inc.'s Sun Java Center (SJC) consulting organization. In our work, we often encounter situations where, because technology is moving so quickly, designers and developers are still struggling to understand the technology, let alone how to design with the technology.
It is not good enough to tell designers and developers to write good code, nor is it sufficient to suggest using Servlets and JSP for developing the presentation tier and EJB components for developing the business tier.
So, given this scenario, where does an aspiring J2EE architect learn not only what to do, but what not to do? What are the best practices? What are the bad practices? How do you go from problem to design to implementation?
Since its inception, SJC architects have been working with clients all over the world to successfully design, architect, build, and deploy various types of systems based on Java and J2EE. The SJC is a rapidly growing consulting organization constantly adding new hires to its ranks of experienced architects.
Recognizing the need to capture and share proven designs and architectures, we started to document our work on the J2EE platform in the form of patterns in 1999. Although we looked in the existing literature, we could not find a catalog of patterns that dealt specifically with the J2EE platform. We found many books dealing with one or more of the J2EE technologies, and these books do an excellent job of explaining the technology and unraveling the nuances of the specifications. Some books offered extra help by providing some design considerations.
Since we first publicly presented our ideas on J2EE patterns at the JavaOne Conference in June 2000, we have received an overwhelming response from architects and developers. While some individuals expressed great interest in learning more about the patterns, others confirmed that they had applied the patterns, but had never named or documented them. This interest in patterns for the J2EE platform further motivated us to continue our work.
Thus, we put together the J2EE Pattern Catalog., which was initially made available to the entire J2EE community in beta form via the Java Developer Connection in March, 2001. Based largely on community feedback, the beta documentation evolved into the release you see in this book.
We hope these patterns, best practices, strategies, bad practices, and refactorings for the J2EE platform, provide the same benefits to you as they do for us.
This book is about:
This book is not about:
This book is for all J2EE enthusiasts, programmers, architects, developers, and technical managers. In short, anyone who is remotely interested in designing, architecting, and developing applications for the J2EE platform.
We have attempted to distinguish this book as a training guide for J2EE architects and designers. We all recognize the importance of good designs and well-architected projects, and that we need good architects to get there.
The use of well-documented patterns, best practices, and bad practices to share and transfer knowledge and experience can prove invaluable for teams with varied experience levels, and we hope that this book answers some of these needs.
This book is organized into three parts.
Part 1—"Patterns and J2EE," consists of Chapter 1 and Chapter 2.
Chapter 1: "Introduction" on page 4 is a brief discussion on various topics, including patterns, J2EE platform, defining a pattern, and pattern categorization. It ends by introducing the J2EE patterns catalog.
Chapter 2: "J2EE Platform Overview" on page 16 provides a high level overview of the J2EE platform for those readers unfamiliar with J2EE, or who wish to refresh their knowledge of the J2EE platform.
Part 2—"Design Considerations, Bad Practices, and Refactorings" deals with design considerations for JSP, Servlets, and enterprise beans. This part also includes bad practices and refactorings for the J2EE platform. This part is comprised of Chapter 3, 4, and 5.
Chapter 3: "Presentation Tier Design Considerations and Bad Practices" on page 34 and Chapter 4: "Business Tier Design Considerations and Bad Practices" on page 54 discuss the design considerations and bad practices for the presentation tier and business/integration tiers respectively. The design considerations are issues that a J2EE developer/designer/architect needs to consider while working with the J2EE platform. The topics presented in these chapters point the reader to other sources (such as official specifications and well written books on these topics) for more detailed information on these issues.
Chapter 5: "J2EE Refactorings" on page 72 includes some of the refactorings we have experienced in our work in the field that has enabled us to move our design from a less optimal solution to a better solution. The refactorings provide another way to think about the material in the rest of the book, providing what we believe to be valuable companion material to the pattern catalog. This chapter shows how we have been influenced by Martin Fowler and his book "Refactoring" Fowler. For those readers who are familiar with the Refactoring book, the format of this chapter will be very familiar. However, the content of this chapter is entirely in the context of J2EE technologies, whereas Martin Fowler addresses refactoring at a different level.
Part 3—"J2EE Pattern Catalog" presents the J2EE pattern catalog. The catalog contains the fifteen patterns that form the core of this book. This part is comprised of Chapter 6, 7, 8, and 9.
Chapter 6: "J2EE Patterns Overview" on page 124 provides an overview of the J2EE pattern catalog. This chapter begins with a high level discussion of the pattern ideas and explains the way the patterns are categorized into tiers. It also explains the J2EE pattern template, which is used to present all patterns in this book. The chapter discusses all the J2EE patterns and uses a diagram to show their inter-relationships. It also provides what we have termed a roadmap to the pattern catalog. This roadmap presents common J2EE design and architecture-related questions with references to patterns or refactorings that provide solutions to these questions. Understanding the pattern relationships and the roadmap is key to using these patterns.
Chapter 7: "Presentation Tier Patterns" on page 150 presents six patterns that pertain to using Servlets, JSP, JavaBeans, and custom tags to design web-based applications for the J2EE platform. The patterns describe numerous implementation strategies, and address common problems such as request handling, application partitioning, and generating composite displays.
Chapter 8: "Business Tier Patterns" on page 246 presents seven patterns that pertain to using EJB technology to design business components for the J2EE platform. The patterns in this chapter provide the best practices for using the EJB and JMS technologies. Where relevant, these patterns include discussion on other technologies, such as JNDI and JDBC.
Chapter 9: "Integration Tier Patterns" on page 388 presents two patterns that pertain to integrating J2EE applications with the resource tier and external systems. The patterns deal with using JDBC and JMS to enable integration between business tier and resource tier components.
Epilogue: "J2EE Patterns Applied" on page 422 discusses realizing sample use cases with the patterns. This chapter discusses and demonstrates how patterns are combined and work together. This chapter reinforces the idea that patterns exist in a community, and that each pattern supports, and is supported by, other patterns.
Posted July 21, 2003
Martin Fowler's 'Refactoring' book quickly became a classic on the subject of improving an existing body of java code. The patterns were described at a general enough level that you could hope to apply them against code, regardless of its application, be it scientific, business or whatever. But one of the boundaries was that Fowler did not discuss patterns when java is used in a narrower but very important context - enterprise computing. This covers cases where you have a web server using java for dynamically generate web pages, and it interacts with a backend database in a multitier structure. Various extensions to java have been made to handle these - servlets, Java Beans, Enterprise Java Beans, Java Server Pages, Data Access Objects. Typically, each has grown in power and complexity such as to have books dedicated solely to its explication. Much more specialised than generic java. The authors of this book discovered that when you code using these enterprise extensions, often similar problems or patterns recur. They ask, can these problems and solutions be systematically elucidated in a form akin to a taxonomy? Their answer is yes, and that answer is this book. It assumes that you already have a fairly high level of competence in the enterprise extensions like EJBs. For example, the book often mentions HttpServlet in the context of JSPs. You need to know what this is. The book wastes no time in describing such things. There are perfectly adequate other texts that do so. At the level of treatment in this book, those are mundane details. The value added by this book is in describing how to optimise the design when you combine the various enterprise extensions into a real product. It has the flavour of Fowler's Refactoring, and in the context of J2EE, may be just as influential.Was this review helpful? Yes NoThank you for your feedback. Report this reviewThank you, this review has been flagged.