Expert One-on-One J2EE Development without EJB

( 2 )


What is this book about?

Expert One-on-One J2EE Development without EJB shows Java developers and architects how to build robust J2EE applications without having to use Enterprise JavaBeans (EJB). This practical, code-intensive guide provides best practices for using simpler and more effective methods and tools, including JavaServer pages, servlets, and lightweight frameworks.

What does this book cover?

The ...

See more details below
Other sellers (Paperback)
  • All (23) from $1.99   
  • New (7) from $16.66   
  • Used (16) from $1.99   
Sending request ...


What is this book about?

Expert One-on-One J2EE Development without EJB shows Java developers and architects how to build robust J2EE applications without having to use Enterprise JavaBeans (EJB). This practical, code-intensive guide provides best practices for using simpler and more effective methods and tools, including JavaServer pages, servlets, and lightweight frameworks.

What does this book cover?

The book begins by examining the limits of EJB technology — what it does well and not so well. Then the authors guide you through alternatives to EJB that you can use to create higher quality applications faster and at lower cost — both agile methods as well as new classes of tools that have evolved over the past few years.

They then dive into the details, showing solutions based on the lightweight framework they pioneered on SourceForge — one of the most innovative open source communities. They demonstrate how to leverage practical techniques and tools, including the popular open source Spring Framework and Hibernate. This book also guides you through productive solutions to core problems, such as transaction management, persistence, remoting, and Web tier design. You will examine how these alternatives affect testing, performance, and scalability, and discover how lightweight architectures can slash time and effort on many projects.

What will you learn from this book?

Here are some details on what you'll find in this book:

  • How to find the simplest and most maintainable architecture for your application
  • Effective transaction management without EJB
  • How to solve common problems in enterprise software development using AOP and Inversion of Control
  • Web tier design and the place of the Web tier in a well-designed J2EE application
  • Effective data access techniques for J2EE applications with JDBC, Hibernate, and JDO
  • How to leverage open source products to improve productivity and reduce custom coding
  • How to design for optimal performance and scalability
Read More Show Less

Editorial Reviews

From the Publisher
“…practical and deep…you have to read if you have any interest in J2EE, with or without EJB…” (VSJ—Visual Systems Journal, December 2004/January 2005)

“…a valuable learning experience all round” (Application Development Advisor, 1st September, 2004)

Read More Show Less

Product Details

  • ISBN-13: 9780764558313
  • Publisher: Wiley
  • Publication date: 6/21/2004
  • Edition number: 1
  • Pages: 576
  • Sales rank: 1,290,190
  • Product dimensions: 8.86 (w) x 9.78 (h) x 0.98 (d)

Meet the Author

Rod Johnson is an enterprise Java architect with extensive experience in the insurance, dot-com, and financial industries. He was the J2EE architect of one of Europe's largest web portals, and he has worked as a consultant on a wide range of projects.
Rod has an arts degree majoring in music and computer science from the University of Sydney. He obtained a Ph.D. in musicology before returning to software development. With a background in C and C++, he has been working with both Java and J2EE since their release. He is actively involved in the Java Community Process as a member of the JSR-154 (Servlet 2.4) and JDO 2.0 Expert Groups. He is the author of the best-selling Expert One-on-One J2EE Design and Development (Wrox, 2002) and has contributed to several other books on J2EE since 2000.
Rod is prominent in the open source community as co-founder of the Spring Framework open source project (, which grew out of code published with Expert One-on-One J2EE Design and Development. He speaks frequently at leading industry conferences. He is currently based in London.
Rod can be contacted at

Juergen Hoeller is a Senior Systems architect and Consultant at werk3AT, a company that delivers complex web solutions and provides J2EE-based consulting in Austria.
Juergen has a masters degree in Computer Science from the University of Linz, specializing in Java, OO modeling, and software engineering. He has worked on a wide range of projects with numerous J2EE application servers, ranging from enterprise application integration to web-based data visualization.
Juergen has particular experience in developing J2EE web applications, O/R mapping, and transaction management. Juergen is co-lead of the Spring Framework and active in many community forums, including TheServerSide.

Read More Show Less

Table of Contents

About the Authors.


Chapter 1: Why “J2EE without EJB”?

Chapter 2: Goals.

Chapter 3: Architectures.

Chapter 4: The Simplicity Dividend.

Chapter 5: EJB, Five Years On.

Chapter 6: Lightweight Containers and Inversion of Control.

Chapter 7: Introducing the Spring Framework.

Chapter 8: Declarative Middleware Using AOP Concepts.

Chapter 9: Transaction Management.

Chapter 10: Persistence.

Chapter 11: Remoting.

Chapter 12: Replacing Other EJB Services.

Chapter 13: Web Tier Design.

Chapter 14: Unit Testing and Testability.

Chapter 15: Performance and Scalability.

Chapter 16: The Sample Application.

Chapter 17: Conclusion.

Last words.


Read More Show Less

First Chapter

Expert One-on-One J2EE Development without EJB

By Rod Johnson Juergen Hoeller

John Wiley & Sons

ISBN: 0-7645-5831-5

Chapter One

Why "J2EE Without EJB"?

The traditional approach to J2EE architecture has often produced disappointing results: applications that are more complex than their business requirements warrant, show disappointing performance, are hard to test, and cost too much to develop and maintain.

It doesn't need to be so hard. There is a better way for most applications. In this book, we'll describe a simpler, yet powerful architectural approach, building on experience with J2EE and newer technologies such as Inversion of Control and AOP. Replacing EJB with lighter-weight, more flexible, infrastructure typically produces significant benefits. We and many others have used this approach in many production applications, with better results than are usually produced from traditional architectures.

Let's begin with a quick tour of the topics we'll examine in more detail in later chapters.

EJB Under the Spotlight

Like most of my colleagues, I was excited by the promise of EJB when it first appeared. I believed it was the way forward for enterprise middleware. However, I've since revised my opinions, in the light of my experiences and those of many colleagues.

Much has changed since the EJB specification was conceived:

Parts of the specification's design now seem dated. For example, dynamic proxies, introduced in J2SE 1.3, call into question the container code generation envisaged in the EJB specification and the multiple source files needed to implement every EJB.

The traditional link between EJB and RMI remoting is looking dated, because of the emergence of web services and the recognition that EJBs sometimes need only local interfaces. EJB is a heavyweight model for objects that don't need to offer remote access.

This is a special case of the fact that basing typical applications around distributed business objects-the architectural choice EJB implements best-has proved problematic.

Usage of EJB indicates its strengths and weaknesses. Most developers and architects have restricted their use of EJB to stateless session beans and (if asynchronous calls are needed) message-driven beans. The relative simplicity of the services provided by the EJB container to support SLSBs means that the overhead of an EJB container is hard to justify in such applications.

Although EJB has been around for five years, and its use is a given in many J2EE projects, it has become apparent that its complexity means that many developers still don't understand it. For example, many developer candidates I interview can't correctly describe how EJB containers handle exceptions and how this relates to transaction management.

The EJB specification is becoming more and more complex in an attempt to address problems with EJB. It's now so long and complex that few developers or architects will have time to read and understand it. With specifications, as with applications, the need for continual workarounds and constantly growing complexity suggests fundamental problems.

The complexity of EJB means that productivity in EJB applications is relatively poor. A number of tools try to address this, from "Enterprise" IDEs to XDoclet and other code generation tools, but the complexity still lurks under the surface and imposes ongoing costs.

Rigorous unit testing and test driven development have become increasingly, and deservedly, popular. It's become clear that applications making heavy use of EJB are hard to test. Developing EJB applications test first requires a lot of fancy footwork; essentially, minimization of the dependence of application code on the EJB container.

The emergence of Aspect Oriented Programming (AOP) points the way to more powerful-yet potentially simpler-approaches to the middleware problems addressed by EJB. AOP can be viewed in part as a more general application of the central EJB concepts, although of course it's much more than a potential replacement to EJB.

Source level metadata attributes, as used in .NET, suggest a superior alternative in many cases to the verbose XML-based deployment descriptors used since EJB 1.1. EJB 3.0 looks like it's heading down that road as well, but it's a way off and will carry a lot of baggage.

Experience has also shown EJB to incur greater cost and deliver fewer benefits than were initially predicted. Developers have encountered intractable problems that weren't apparent when EJB first appeared. Experience has shown that EJB fails to deliver in several areas:

It doesn't necessarily reduce complexity. It introduces a lot of complexity.

The entity bean experiment for persistence has largely failed.

Applications using EJB tend to be less portable between application servers than applications using other J2EE technologies, such as servlets.

Despite the promises that EJB would prove the key to scalability, EJB systems often perform poorly and don't necessarily scale up well. Although statistics are hard to come by, anecdotal evidence suggests that the overhead of excessive use of EJB necessitates re-architecture or causes outright failure in a significant number of projects.

EJB can make simple things hard. For example, the Singleton design pattern (or alternatives) is hard to implement in EJB.

All of these issues suggest that it's wise to analyze exactly what the value proposition is before using EJB. I hope to equip you with the tools to do this effectively and dispassionately.

In Chapter 5, we'll talk more about EJB and its problems. In the meantime, let's look at where J2EE is today, where I feel it's going, and how this book will help you deliver real solutions on time and budget.

What's Left of J2EE?

You may be wondering, "What's left of J2EE without EJB?"

The answer is: a great deal. J2EE is much more than EJB. Many J2EE developers believe otherwise, and will tell you so when they see this book on your desk, but a dispassionate analysis of what EJB does, and what J2EE does overall, shows that EJB is only a part of a much bigger and more important picture.

J2EE is essentially about standardizing a range of enterprise services, such as naming and directory services (JNDI), transaction management offering a standard API potentially spanning disparate transactional resources (JTS and JTA), connection to legacy systems (JCA), resource pooling, and thread management. The true power of J2EE lies in these services, and this standardization has done great service to the industry.

EJB, on the other hand, is merely one way of leveraging those valuable services, through a particular component model.

We can still access JNDI, JTA, JCA, resource pooling, and other core J2EE services without using EJB. We can do this by writing code that uses them directly (not as hair-raising as it may seem) or-better-using proven libraries and frameworks that abstract their use without imposing the complexity of EJB.

Only a few EJB container services are unique to EJB, and there are good alternatives to those. For example:

Entity beans are the only dedicated data access components in J2EE. However, they're also the most questionable part of J2EE, and there are much better non-J2EE alternatives, such as Hibernate and JDO. In some applications, JDBC is a better option.

Container Managed Transactions (CMT): EJBs are the only part of J2EE to enjoy declarative transaction management. This is a valuable service, but as we'll see in Chapters 8 and 9 we can also achieve declarative transaction management using AOP. CMT is a relatively thin layer over the underlying J2EE JTA service. It would be hard (and foolhardy to attempt) to replace an application server's global transaction management, but it's not so hard to access it to develop an alternative form of CMT.

Thread pooling for business objects: We usually don't need this if we're supporting only web clients (or web services clients going through a servlet engine), because a web container provides thread pooling and there's no need to duplicate it in the business object tier. We do need thread pooling to support remote clients over RMI/IIOP, one case in which EJB remains a good, simple technology choice.

(Related) Thread management for business objects: the ability to implement EJBs as though they are single-threaded. In my experience this is overrated for stateless service objects (the most useful kinds of EJB). EJB can't eliminate all threading complexity anyway, as problems can remain with objects used by EJB facades. There are good alternatives to EJB thread management, discussed in Chapter 12.

Only in the area of remoting is EJB the only way to implement such functionality in standard J2EE. As we'll see, only in RMI/IIOP remoting is EJB clearly an outstanding remoting technology; there are better alternatives for web services remoting.

There's a strong argument that EJB attempts to address a lot of issues it shouldn't. Take O/R mapping. This is a complex problem to which EJB provides a complex yet under-specified solution (entity beans) that simply ignores some of the central problems, such as mapping objects with an inheritance hierarchy to relational database tables. It would have been better for the designers of the EJB specification to leave this problem to those with much more experience of the issues around object persistence.

J2EE at a Crossroads

J2EE is at a fascinating point in its evolution. In many respects it's a great success. It has succeeded in bringing standardization where none existed; it has introduced a welcome openness into enterprise software. It has achieved fantastic industry and developer buy-in.

On the other hand, I feel it has come up short on a number of measures. J2EE applications are usually too expensive to develop. J2EE application projects are at least as prone to failure as pre-J2EE projects. (Which means that the failure rate is unacceptably high; developing software is far too hit-and-miss an affair.) In the areas where J2EE has failed, EJB has usually played a significant part.

J2EE has significant issues with ease of development. As I've said, J2EE applications tend to be unnecessarily complex. This is especially true of J2EE web applications, which, like the Sun Java Pet Store, are often absurdly over-engineered.

J2EE is still a relatively young technology. It's not surprising that it's imperfect. It's time to take stock of where it's worked, and where it hasn't worked so well, so that we can eliminate the negatives and enjoy the positives. Because J2EE contains a lot, this essentially means identifying the subset of J2EE that delivers most value, along with some supplementary infrastructure we need to harness it most effectively.

There is a growing movement in the J2EE community toward simpler solutions and less use of EJB. My previous book, Expert One-on-One J2EE Design and Development (2002), was a step in the growth of that movement, but was part of a broader trend. I believe this book represents the next step in defining and popularizing such solutions, but it's important to note that I'm by no means alone. Fellow pioneers include Rickard Oberg and Jon Tirsen (of Nanning Aspects), who have helped to demonstrate the power and simplicity of AOP-based solutions. The revisions in the second edition of Core J2EE Patterns suggest that even Sun is not immune; there is a new and welcome emphasis on use of plain Java objects.

Some of the problems with J2EE and EJB relate to its specification-driven origins. History shows that the most successful standards evolve, rather than are created by a committee. The danger of a "specification-first" approach is shown by the example of the OMG and CORBA. The OMG was founded to create a distributed object standard. Over 300 vendors signed up; the result was the slow production of complex specifications that never achieved widespread acceptance. As is often the case with committees, usability by developers was barely a consideration; the result was a horribly complex programming model.

J2EE is partly an evolution of existing middleware, because many of the problems it addresses were familiar when it was conceived in the late 1990s. For example, stateless session EJBs are merely an EJB take on a component type of proven value. Service objects with declarative transaction management existed in Microsoft Transaction Server, for example, before the EJB 1.0 specification. It's arguable that where J2EE has tried to innovate, through specifications being developed before any real applications using them, it has often failed. Stateful session beans, for example, were a new and unproven component type introduced in EJB. Five years on, they remain largely unproven. The tricky issue of state replication remains problematic, and most architects avoid stateful session beans if at all possible.

I suspect that the specification-driven nature of J2EE is going to change in practice, and that this is a good thing. I don't envisage J2EE descending into anarchy, but I do think that developers aren't automatically going to adopt each new feature of the J2EE specifications without considering alternative technologies, especially from the open source community.

This book represents part of that critical process: the recognition that end users of the technology-application developers, project managers responsible for development projects, and those who end up using applications-are the most important stakeholders, and that the reality at the coal face of application development isn't always obvious to those on specification committees.

The Way Forward

This book is not primarily about questioning EJB, but about mapping a path forward. This includes architectural principles, working code, and practical advice you can use in your projects today.

The way forward that this book proposes is to focus on core values-I'll call them themes-that help lead to project success, and to examine architectures and implementation choices that express them.


The central themes of this book are:



The fundamental importance of object orientation

The primacy of business requirements

The importance of empirical process

The importance of testability

Let's briefly discuss these.


There are simple problems, and architecture and implementation should always be as simple as possible.


Excerpted from Expert One-on-One J2EE Development without EJB by Rod Johnson Juergen Hoeller Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

Read More Show Less

Customer Reviews

Average Rating 5
( 2 )
Rating Distribution

5 Star


4 Star


3 Star


2 Star


1 Star


Your Rating:

Your Name: Create a Pen Name or

Barnes & Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation


  • - By submitting a review, you grant to Barnes & and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Terms of Use.
  • - Barnes & reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing all of 2 Customer Reviews
  • Anonymous

    Posted February 18, 2005

    Author of the Spring Framework

    One of the authors of this Book, Rob Johnson, is also the author of the Spring Framework. So he knows of what he speaks! Both Hibernate and Spring are topics worth reading about for anyone doing J2EE development.

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted January 11, 2005

    Outstanding J2EE Book

    An excellent book on using lightweight frameworks instead of heavyweight, EJB based frameworks. It uses the Spring Framework for it's lightweight example, and Hibernate and JDO for it's O/R tools. Don't get the wrong idea though, this is not a 'bash ejb' or 'spring is the greatest' type of book. This is a professionally written book, showing you another way of approaching J2EE. This book is a must for your library of knowledge.

    Was this review helpful? Yes  No   Report this review
Sort by: Showing all of 2 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)