Slashdot Mirror
Bitter EJB
However, every coin has two sides: the other side of "freedom of choice" is "complexity". Although EJB is an incredibly powerful tool in the hands of experience architects, it is subject to a lot of misuse by novice developers who do not make sound choices. For example, some developers might use a BMP entity bean to map each database table in the system; or access entity beans directly from a distributed layer; or store large amount of data in session objects ... The list goes on. Although those approaches are technically possible, they are hardly the most efficient ways in most cases. Such problems have not only caused many projects to fail but also tarnished EJB's reputation. In fact, the complexity of EJB is often quoted as an argument for other enterprise platforms.
For EJB developers, it is crucial to learn from other people's experiences and follow proven best practices. That helps to reduce the complexity of the platform. Manning's "Bitter EJB" is a very timely book written by well-known experts in the EJB field: Bruce Tate, Mike Clark, Bob Lee and Patrick Linskey. Unlike other "architectural" books, Bitter EJB teaches best practices through common mistakes (anti-patterns). It focuses on "what not to do" but still encourages developers to come up with liberal (everything not forbidden is OK) and innovative solutions. After all, EJB is about flexibility and freedom of choices.
Part I of the book is an overview of anti-patterns in the EJB specification. The EJB specification itself has several major design problems when it first came out in March 1998. EJB v1.1 and v2.0 have gone great length to fix the anti-patterns in the specification. But early adopters may have already developed some anti-patterns in their applications. For new developers, the history also serves as a valuable lesson on what EJB is really for and how different components in the specification fall into their current places. In this part, the authors also provide an excellent recount on what went wrong in the high profile TSS Java PetStore benchmark.
Part II is about session and message-driven beans. Those beans are mainly used in the integration layers. Topics covered in this part include how to deal with large database results, whether to maintain session states, the limitations of XML and much more.
Part III covers EJB persistence. Entity EJBs are probably the most confusing types of components. Many experts have advocated to abolish entity EJBs altogether in favor of other simpler persistence frameworks such as the JDO or even simple JDBC facades. The authors discuss the pros and cons of entity EJBs and covers most leading alternatives. For those who must use entity EJBs, this book also offers useful advices on a range of topics including how to reduce round trips, shorten primary keys and handle expensive database joins etc.
Part IV covers broader topics including performance tuning, testing, building and packaging. One big problem that even EJB developer can recognize the complex deployment descriptors. One chapter of the book is dedicated to reduce code duplication, automate the deployment process and avoid the "integration hell". The last chapter of the book provides an overview of "what's next" in the EJB space.
Overall, it is an excellent book for all EJB developers and other enterprise developers who want to learn from the successes and failures of EJBs."
Peter Wayner's review:
Although there may be as many 36 plots
in all of literature, the compartively new world of computer books has really had only one: this new technology is simple, very
simple, and it will make your life better and your teeth whiter. Bruce
Tate opened up a second plot in his book Bitter
Java by exploring just how even the best programming ideas have
dark sides. Now he's back with three other authors exploring the world
of Bitter EJB.
This book is more fruit from the same tree. Or, to hack the Java MemeStream even more, more beans for the same mill. If you use Enterprise Java Beans (EJB), or think about using them, you should read
this book to see what can go wrong. The title shows how naming schemes can be misleading because either the authors aren't really
that bitter, or because they're focused entirely on EJBs. This book does not belong in
the same camp
with the Java==SUV crowd. These authors are really admirers who just want to warn people how to avoid problems with Java and EJB.
Tate and his new co-authors, Mike Clark, Bob Lee, and Patrick Linskey are all
consultants who seem to use Java a lot, at least when they're not cheating death. One of the cuter grace notes in the book is a collection of war stories from extreme sports that are mixed in as an allegorical taste of what's to come. Before exploring the problems with a Java concept known as enterprise beans, they tell a kayaking story
that ends with the sentence, "Then we hear a loud crunch and look up to see Eric's stern stationary at the top of the drop, revealing the
sitaution that every kayaker dreads the most -- the vertical pin."
After stories like this, the book goes on to explore just how the
very fancy enterprise beans toolkit can produce an application that moves slower
than a stream filled with honey. Each chapter is filled with antipatterns, or lessons about the software learned the hard way.
They're sort of like points on the map that say, "There be dragons here."
The book is divided into four parts. The first section, termed "The
Basics," explores the simple ways that EJB technology goes bad. The
toolkit was heavily hyped as the perfect solution for building business websites that interface seamlessly with large databases. As the business
grew, new servers could be added without grief. Alas, as this
section points out, there are many reasons why an elephant gun can be
the wrong weapon for getting rid of mice in your house.
The next section on "Networks and Messages" describes how good ideas
can turn into slow code when people misuse the fancy tools for scaling
EJBs. In theory, the EJB toolkit will split up processes simply across
multiple machines to handle more customers, but in practice all of the
communication can slow things down considerably.
The section on "EJB Persistence" describes how the much-hyped system
for seamlessly storing away enterprise beans in databases can weigh
down a system. My only beef is that they left out much information on Prevayler, a much-maligned and
misunderstood ultra-light toolkit that is like an anti-EJB persistence
layer in every possible way. I'm enamored with it, if only because it's
such a radical move away from the monolithic APIs like EJBs. While they
liken using EJBs to snowboarding in fresh powder with a 100lb pack on
your back, Prevayler is sort of like boots-only hiking.
The last section isn't about EJBs per se, but similar toolkits and
projects that often get used with EJB. There are antipatterns to avoid with JUnitPref and Ant, too. Some of these suggestions, like some in the rest of the book, aren't terribly new or brillant, but it can't hurt to get another lecture on the importance of testing your code.
The book shines when it's exploring what goes on behind the slick facade of the API. Sure, the EJB toolkit will dutifully load up data
from any object on any server in your farm, but you better be careful invoking some of these these methods because the network is slow. The
book often points out how invoking that one simple method from the sales literature
can start up dozens of sluggish threads. Peeling away the layers helps
understand and explain why the system fails.
Many of these lessons aren't limited to Java or EJB. I wouldn't be
surprised if the group of authors was busy rewriting the book with examples from .NET. Unfortunately, some programming problems are very
hard, and building a toolkit with a simple API won't make them go away.
In fact, the simple appearance can cause more trouble when the
programmer can't understand what the secret mechanism inside is doing.
Almost all of the problems in this book arise from programmers who
believe the sales literature when it tells them not to pay attention to
what that little bot behind the curtain is doing. If you're working
in the world of EJB consulting on big iron, then you've got no choice
but to start thinking about what's behind that curtain.
You can purchase the Bitter EJB from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page. Peter Wayner is the author of 13 books including Java RAMBO Manifesto and Translucent Databases.
For those you who aren't boycotting Amazon:
Ref: Amazon has this book for $4.50 less than bn and with free shipping
If I used EJBs, I think I would buy the book. Addressing the anti-patterns first is good, because EJBs won't save the world. But, they are very powerful in certain applications. Many posters have simply stated that EJBs are hard to develop and slow in performance. Some of these claims are true, but reasonable performance can be achieved by being smart in how you use beans, and that's what this book helps you to do.
I'm also glad the book talks about the failed TSS PetStore performance shootout, although I'm curious about how it's presented. Suffice it to say that PetStore really isn't (or at least wasn't then) a good example of the way to do things.
And for those complaining about the difficulty of EJBs, many AppServer vendors provide development tools that make coding EJBs very easy. Although, these tools tend to be really pricey.
That's how every good slashdot troll should begin. But if there is one technology that is currently at real risk of extinction in the Java world it is EJB. Almost every new J2EE project that I hear about steers clear from EJB towards simpler solutions such as plain servlet/jsp with JDO for persistence. Then you scale it horizontally through mod_jk or a hardware load balancer. No need for confusing (and restrictive) enterprise beans.
Entity EJBs have been critisized many times and rigtfully so. Session beans I find are OK but for me (and my company) it's a case of "I really don't need them given the baggage of complexity and the restrictive nature of their API.
Message driven beans are probably worthy of consideration but there isn't that much to them really. Certainly not something you couldn't implement on your own with plain JMS. I've done it, didn't take much time and it worked just as well as the specc'ed MDBs. And I don't have to run within an EJB container. I can deploy to Tomcat and have SonicMQ running remotely.
Is EJB going to really take off? Seems that the spec was vastly improved but not all problems with the technology have been addressed and then there is the phsycological issue for many developers who had nasty experiences with EJB 1.1 development.
I won't trash EJB they are a certain way to develop enterprise applications. I just find that I end up with much simpler design if I avoid them in lieu of something simpler. My preferred stack at the moment (assuming no legacy systems to integrate with) is as follows:
- Struts
- Hibernate
- GLUE
- Tomcat
- JDOM
- SonicMQ if I need messaging
- Good DBMS
And I'm good to go. Look Ma, no EJB!Your pizza just the way you ought to have it.
"Oh, I hope he doesn't give us halyatchkies," said Heinrich.
To Bitter Java, Bruce Tate's previous and somewhat less targetted book. I read this book and it was absolutely fantastic-- I would recommend it, and based on the pedigree I would say this new book is probably worthy of recommendation as well.
:(
Bitter Java went in exquisite detail into the various ways things can go wrong in Java development, and in Java-like languages, in an attempt to teach good design by counterexample (most of the book concerned real-life examples of what they called "antipatterns"). It is one of the better books on OO design I've come across. Unfortunately I accidentally left my copy on an airplane somewhere between Indianapolis and Dallas
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
Well, here I go, throwing away my mod points to respond to this flamebait....
.NET or DCOM is a better solution with its "one size fits all" solution. Of course, you don't actually state which is better, merely, you are blindly proselytizing another vendor's product line.
.NET platform, those choices are rather similar.
.NET. Hell, CORBA isn't all that difficult when you get down to it.
First, let me see if I understand your criticism correctly. Distributed architecture is a very complex and advanced form of software architecture. There is not merely one simple solution for all requirements, but an entire host of options to ensure that the right system is built to solve the problem at hand. This might include distributed components (EJB), but might also include CGI-based services (Java Servlets), asynchronous message-based services (Java Messaging Service), socket-based services (sockets, RMI), and much more. J2EE (Java 2 Enterprise Edition) addresses all of these (with RMI covered by the core Java API), of which EJB is one small part.
Your complaint seems to be that EJB is difficult and provides too many options. You seem to feel that
Regardless, your statement that EJB provides you with 1000's of choices is patently false. In actually, you have a small handful of options from which to choose. In fact, if you take a look at the
For those who aren't familiar with EJB, you basically have a choice between objects that maintain stateful data on the current user session and those that don't (stateful and stateless beans). Of these, you also have a choice of whether a componet represents business logic (session beans) or data (entity beans). Finally, of the data components, you can have the EJB engine (called a "container") manage persistence for you or you can do it yourself ("container-managed persistance" and "bean-managed persistance"). Lastly, introduced in EJB 2.0, you can have components that respond to asynchronous messages. By my count, that is 6 options. Go nuts, throw in "local interfaces", and you have 7 options.
That's a far cry from 1000's.
It sounds to me like you merely glanced over the API's which are provided for two primary purposes. One, for those who wish to develop components for use within the EJB framework, there is a small set of interfaces and objects. Two, for those who wish to develop their own EJB container (e.g. JBoss, Websphere, WebLogic), the remainder of the API's interfaces are provided.
I have developed countless EJB-based systems so I have the experience upon which to draw when I say that EJB is not complex. Neither is
Distributed architecture is complex. Please do not confuse the design with the implementation.
Oh, and lest you question my qualifications, I have co-authored two books on EJB and Distributed Architectures, as well as having given many lectures on both at various conferences.
Oh, and I found Unix very easy to learn. =)
Ryosen
One man's "Troll, +1" is another man's "Insightful, +1".
I'm an architect working on a multi-million dollar enterprise app, and our experience with ejb thus far has been extremely positive. We steered away from entity beans, opting instead for a jdo layer. Much of the integration layer utilizes mdb's for bridging between an oracle backend and a db2 subsystem.
With modest hardware we're competing quite effectively with the mainframe app we're replacing.
Our worst choice was to use a Swing front-end instead of Struts.
My advice for anyone getting into ejb development is DESIGN. DESIGN. DESIGN. Know exactly what you're trying to do. Prototype a lot. Test all the time. And get a quality dba, because the effect of solid db tuning will usually beat anything you can do at the app server level.