Effective Enterprise Java - Softcover

Neward, Ted

3.46

24 ratings by Goodreads

9780321130006: Effective Enterprise Java

Softcover

ISBN 10: 0321130006 ISBN 13: 9780321130006

Publisher: AddisonWesley Professional, 2004

View all copies of this ISBN edition:

"With this book, Ted Neward helps you make the leap from being a good Java enterprise developer to a great developer!"
—John Crupi, Sun Distinguished Engineer coauthor, Core J2EE Patterns

If you want to build better Java enterprise applications and work more efficiently, look no further. Inside, you will find an accessible guide to the nuances of Java 2 Platform, Enterprise Edition (J2EE) development. Learn how to:

Use in-process or local storage to avoid the network, see item 44
Set lower isolation levels for better transactional throughput, see item 35
Use Web services for open integration, see item 22
Consider your lookup carefully, see item 16
Pre-generate content to minimize processing, see item 55
Utilize role-based authorization, see item 63
Be robust in the face of failure, see item 7
Employ independent JREs for side-by-side versioning, see item 69

Ted Neward provides you with 75 easily digestible tips that will help you master J2EE development on a systemic and architectural level. His panoramic look at the good, the bad, and the ugly aspects of J2EE development will address your most pressing concerns. Learn how to design your enterprise systems so they adapt to future demands. Improve the efficiency of your code without compromising its correctness. Discover how to implement sophisticated functionality that is not directly supported by the language or platform. After reading Effective Enterprise Java , you will know how to design and implement better, more scalable enterprise-scope Java software systems.

"synopsis" may belong to another edition of this title.

About the Author:

Ted Neward is a software architect, consultant, author, and presenter who has consulted for such companies as Intuit and Pacific Bell, and UC Davis. He is the author of Server-Based Java Programming (Manning, 2000), and coauthor of C# in a Nutshell (O'Reilly, 2002) and SSCLI Essentials (O'Reilly, 2003). Ted was a member of the JSR 175 Expert Group. He now frequently speaks on the conference circuit and to user groups all over the world. He continues to develop and teach courses on Java and .NET.

Those who cannot remember the past are doomed to repeat it.
—George Santayana

These are heady days for Java programmers. Commercially available for less than a decade, Java has nevertheless emerged as the language of choice for enterprise systems on nearly all major computing platforms. Companies and individuals with challenging programming problems increasingly embrace the language and platform, and the question faced by those who do not use Java is often when they will start, not if. The breadth and scope of the specifications and libraries defined by and under the Java 2 Enterprise Edition Specification—which both dwarfs and subsumes that of the Java language itself—makes it possible to write rich, complex systems without sacrificing performance or implementing common algorithms or data structures from scratch. The Java language and virtual machines grow ever more powerful. Tools and environments for Java development grow ever more abundant and robust. Commercial libraries all but obviate the need to write code in many application areas.

Scott Meyers wrote much the same in his opening to More Effective C++ Meyers97 almost a decade ago. It seems a fitting tribute to use that paragraph, suitably modified, as the opening in this book. As a matter of fact, the two paragraphs are deliberately side-by-side similar. In many ways, we now find ourselves in a part of the Golden Age of Java, looking out over a landscape that stretches from horizon to horizon, with ample space and established borders that seem to have no limit. Just as C++ ruled the landscape in 1996, Java rules the landscape in 2004.

The chief aim in drawing these parallels is to recognize the scenario—not more than two years after Scott wrote that paragraph, C++ was toppled from its throne by this upstart named Java. Just as C++ developers had finally begun to "figure everything out," this new language and environment leapt forward into the fray, and almost overnight, it seemed, took over. In turn, Java now faces fierce competition from Microsoft's .NET platform. The natural concern, then, is to see that history doesn't repeat itself. To do that, Java developers must make sure that the systems they develop meet or exceed expectations set for them. To do that, Java developers need to know how to make the most of the language and platform they use.

It has been said, in many places by many people, that it takes about five years to "figure out" a technology and how best to use it. Certainly this was true for C++: in 1990, we looked at C++ as simply another object-oriented language, and therefore using it should mirror the best-usage practices discovered with Smalltalk. By 1995, we were well out of that world and starting to explore the uniqueness that C++ provides (such as templates and the STL). Certainly this was also true of HTTP: in 1995, when the browser debuted, we looked at HTTP as the means by which HTML was delivered. Now, we look at HTTP as a universal transport by which to transmit all sorts of data.

Thus, the timing is fortuitous for Java. It officially debuted in 1995; for all intents and purposes, however, Java truly entered the mindscape of the average developer in 1997 or so, having by that point built enough of a "critical mass" to win its way past the critics and skeptics. Almost a decade later, we have been writing Java applications for most of that time, and we're starting to see the practices and patterns that have emerged to assist (but not necessarily guarantee) successful deployments. As a community, we're just starting to hit our stride.

Some things aren't different from the C++ days. We have the same questions, modified for the Java world, as those we asked (and Scott answered) a decade ago about C++. As the language and platform have matured and our experience with Java has increased, our needs for information have changed. In 1996, people wanted to know what Java was. "It has something to do with the Internet, whatever that is" was a common explanation. Initially, developers focused on using applets, making rich browser clients, and harnessing Java's cross-platform portability. By 1998, they wanted to know how to make it work: "How do I access a relational database? How do I internationalize? How do I reach across physical machine boundaries?" Now, Java programmers ask higher-level questions: "How can I design my enterprise systems so they will adapt to future demands?

How can I improve the efficiency of my code without compromising its correctness or making it harder to use? How can I implement sophisticated functionality not directly supported by the language or platform?"

As if this weren't enough, a new dimension has arisen in the whole enterprise system arena, neatly captured in two words: Web Services. Even as Java developers are asking the hard higher-level questions about Java, they face the start of the cycle with Web Services—what is a Web Service, how does it work, and, perhaps most importantly, how does it relate to Java?

In this book, I answer these questions and many like them.

About the items

One thing I feel compelled to point out, before we get too deeply into it all, is that readers may notice a significant difference between the items in this book and those from books like Effective Java Bloch and Effective C++ Meyers95. In particular, the scope of the items in this book is much larger than that in other similar books—in here, there's less focus on language and/or APIs and more on design-level constructs and/or usage patterns.

This is not an accident; in fact, I believe that this is in keeping with the larger scope of an enterprise application as a whole. Certainly, without question, all of Effective Java also applies to building enterprise applications, but to simply remain at that level misses the larger point, that enterprise systems have much more to worry about, things outside of the scope of the language or APIs.

For example, an unsuccessful EJB application usually begins not with misuse of a particular method call or interface but with the design of entity beans that are called directly from a client. This isn't so much an implementation problem as a design problem, and solving it requires a more "high-level" view of what the entity bean is trying to provide in general. (See Item 40 for more details about entity beans and their consequences.)

As a result, the items presented in this book strive to help developers recognize efficiency not at a language level but at a systemic and architectural level. Many of these items will be familiar ground to some; many will be simple codification of something some readers "always knew." That's OK—what's "intuitive" to one reader will be new to another, and vice versa.

In addition, I have carefully tried to avoid walking on familiar territory. A number of books have been released that discuss best practices and effective use of the virtual machine and/or the language; see the Bibliography for a complete list. As a result, discussions of material covered there won't be repeated here unless it has some particular relevance or application within the enterprise space.

Toward that end, I will refer frequently to patterns already established wit in the enterprise Java literature space; in particular, I will tend to lean heavily on Fowler's Patterns of Enterprise Application Architecture (Addison-Wesley, 2002), Hohpe and Woolf 's Enterprise Application Integration (Addison-Wesley, 2004), and Alur, Crupi, and Malks's Core J2EE Patterns, 2nd ed. (Addison-Wesley, 2003), among others. (Again, see the Bibliography for a complete list.)

Where a pattern is cited by name, I use the standard Gang-of-Four pattern citation format, citing the pattern name with its page number in parentheses behind it; however, because these patterns come from different sources, I also put the author's names (or "GOF" for the Gang-of- Four book, Design Patterns) as part of the page citation. So a reference to the Data Transfer Object pattern from Fowler's Patterns of Enterprise Application Architecture book will be cited as "Data Transfer Object (Fowler, 401)".

Reporting bugs, making suggestions, and getting book updates

I have tried to make this book as accurate, readable, and useful as possible, but I know there is room for improvement. (There is always room for improvement.) If you find an error of any kind—technical, grammatical, typographical, spiritual, whatever—please tell me about it. I will try to ensure the mistake is corrected in a future printing of the book, and if you are the first person to report it, I will happily add your name to the book's acknowledgments. Likewise, if you have suggestions or ideas on how to improve the book for subsequent revisions or editions, I'm all eyes and ears.

I continue to collect guidelines for effective enterprise programming in Java. If you have ideas for new guidelines, I'd be delighted if you'd share them with me. You can either find me on one of several public Java programming mailing lists, the predominant one being the ADVANCED-JAVA list at DISCUSS.DEVELOP.COM, or you can reach me at:

Ted Neward
c/o Addison-Wesley Professional/Prentice Hall PTR
Pearson Technology Group
75 Arlington St., Suite 300
Boston, MA 02116

Alternatively, you can drop me an email at ted@neward.net.

I maintain a list of changes to this book since its first printing (including bug fixes, clarifications, commentary, and technical updates) on the book's blog, http://www.neward.net/ted/EEJ/index.jsp. Please feel free to post comments and/or errata there if you wish to share them with your fellow readers.

Enough preliminaries. On with the show!

"About this title" may belong to another edition of this title.