Table of Contents
| Ch. 1 | Why "J2EE without EJB"? | 1 |
| Ch. 2 | Goals | 13 |
| Ch. 3 | Architectures | 31 |
| Ch. 4 | The simplicity dividend | 65 |
| Ch. 5 | EJB, five years on | 81 |
| Ch. 6 | Lightweight containers and inversion of control | 121 |
| Ch. 7 | Introducing the spring framework | 143 |
| Ch. 8 | Declarative middleware using AOP concepts | 187 |
| Ch. 9 | Transaction management | 231 |
| Ch. 10 | Persistence | 261 |
| Ch. 11 | Remoting | 309 |
| Ch. 12 | Replacing other EJB services | 341 |
| Ch. 13 | Web tier design | 363 |
| Ch. 14 | Unit testing and testability | 411 |
| Ch. 15 | Performance and scalability | 451 |
| Ch. 16 | The sample application | 489 |
| Ch. 17 | Conclusion | 521 |
Read a Sample 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.
Themes
The central themes of this book are:
Simplicity
Productivity
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.
Simplicity
There are simple problems, and architecture and implementation should always be as simple as possible.
Continues...
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.
Loading...