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.
I do agree with the title of the Book. EJB, especially EJB 1.1 and EJB 2.0 are def. very HUGE specifications and as hard to learn as UNIX. You have 1000's of choices which lead wayward programmers easily. Contrast this with M$FT which provides a clear Roadmap and expands complexity slowly to grasp them easier. EJB is like being pushed into the Q Continuum when you are a mere biped and not an omnipotent. It is too huge for you.
-------- Cluster bombing from B-52s is very, very accurate -- the bombs always hit the ground.
At least the novice developers can use it. Look at Visual Basic: VB is the most popular language with over 3 million developers simple because anyon can pick it up and get started, this leads to more developers, which leads to more apps, which helps Windows dominate the desktop.
Now a large number of those first projects are garbage apps, but at least they give a starting point. We need languages that novices can jump into, then good books that can help steer them as they continue learning the language.
A system with complex rules isn't necessarily more powerful, but it's usually more difficult and error prone.
Unfortunately this misconception is very common in computer science. People tend always to create complex APIs/infaces and protocols just to get a "powerful tools". The result is the security and error ridden state of the internet and computers we see these days.
Strangely other hard sciences have seen these problems decades ago (sometimes even centuries ago) and changed their terminology and fundations accordingly. Take e.g. Mathematics with is based on 2nd order logic and set theory. And this started with Godel, Riemann, Abel and Gauss about 120 years ago. We have the same drive now in Physics with Wolfram and co. propagating simple cellular automata. Some people in string theory move in this direction, too.
Unfortunately computer scientists seem to be immune to this amount of common sense right now. Perhaps they need some centuries of fumbling aroung with overly complex model, too, until they get back to earth.
Owner of a Mensa membership card.
For example, most GUI toolkits. Usually, you follow the examples and tutorials as a model, you read through the API docs, and you can build a system that works pretty well. Even many other kinds of enterprise software infrastructure - take TIB Rendezvous, or similar messaging systems - I've written apps with many of them that scale, are efficient and work well on the first try.
I've seen several EJB apps written, and worked on a few myself, and you can read all the damned API docs, follow Sun's examples, read your app server documentation, and so on, and still, you just shoot yourself in the foot. This isn't the first book on patterns and anti-patterns of EJB usage, it's the umpteenth. Why? Because the EJB model was so poorly thought out prior to its implementation that if you follow the specs and build the kind of system they _seem_ to want you to build, it just doesn't work.
Instead you need to have built 10 systems that don't work before you have a clue how to make one that doesn't. Frankly, it seems to me like more trouble than it's worth for what you get (which is basically transaction-aware objects, at least based on my knowledge from the EJB 1.1 era). If you just use session beans, if you don't use entity beans, if you don't do distributed transactions, if you don't use stateful session beans... then you can build an app that works.
Great. I think the J2EE APIs have a lot of great, great stuff in them, but EJB just tweaks me out. Why the hell didn't somebody try using this hunk-a-junk before they released their 1.0 spec, or maybe their 1.1 spec, or howzabout the 2.0 spec? Maybe things are better these days, but if your API looks like it's supposed to provide a pattern for enterprise database applications, shouldn't it actually do that, or somehow redefine what the hell it's really supposed to be for?
Every failed EJB based system (and many failed non-EJB systems) that I've seen had poor database schema design at their heart. In almost every case, engineers familiar with OO design, didn't really bother to learn anything about RDBMS, perhaps because they felt them to be old-fashioned, and tried to ignore the database as much as possible, and put too much logic outside of the database.
There's a lot to EJBs, sure. But you first have to learn the basics of good database design, for without that, you are hosed.
Namely, whenever people on Slashdot complain about how EJBs are insanely slow and seem to cause more problems than they solve, someone always posts something along the lines of "they weren't used properly." Which is nice and all, but I have yet to figure out what is a proper use of EJBs. So, that's my main question - what should EJBs be used for? When are they the right tool for the job?
I wasn't able to figure this out the last time I worked with a J2EE environment. All in all, it seemed that they were too complicated for what we were doing. And I wasn't able to see a problem where they would have been a good solution.
Of course, I've been soured to them (or bittered, maybe?) based on the project which was basically people questioning the contractors' choice of CORBA on their Java-based system. Someone suggested to management that the contractors should have used EJBs and that this would have made the finished project "Better." So I got stuck with the task of trying to demo a system with CORBA replaced with EJBs instead - never mind the fact that most J2EE environments use CORBA as the RMI layer between beans...
So to sum up: What is the "right way" to use EJBs? And what types of problems are they best at solving?
You are in a maze of twisty little relative jumps, all alike.
However you are correct in the sense that most of the people using EJB's have no clue of whats an "enterprise" application: they think that because their building a banking application (or worse a large website) that they are building an enterprise application. Most people I see using EJB's have no idea whats ACID let alone XA, they sometimes know what 2pc means but only its initials and not how it works.
EJB's depend a lot on the tools as well I personally think WebSphere sucks, it looks good but it was just badly designed.
EJB's were technically designed to be developed by novices using GUI tools that will abstract the complexities. Some of these tools actually work very well and you can get a team of novices to produce a great EJB application (since writing EJB's with a tool is REALLY easy) but when you hit the snags (since no current tool works correctly and usually you need application server tuning) then you need a REAL architect to step in and fix things.
Most people just use EJB's for buzzword compliance which regretfully causes the tons of FUD we see about them today.
I've been doing J2ee development for the last couple of years and on the whole I don't think EJBs give you many advantages but they do add a lot of confusion.
The main problem is that it isn't clear the best way to use them, there are so many techniques and patterns out there but there is nothing you can point at that is the 'best practice' - it all depends on your application.
The advantages of easily scalability of business objects over multiple servers is useful, but since the database is the main bottleneck in most enterprise applications the scalability of the business logic layer doesn't give you a lot. Also many applications require communication between the various clients (through the server) but since EJBs are designed to be location independent, there is no nice ways of communicating between session EJBs on various machines. It is possible to do it with message EJBs but it's not easy. Another thing to note is that you don't need EJBs to separate the business layer from the presentation layer, it's easy to do with normal classes. You also don't need EJBs to have the business logic running on another server - you can just use RMI.
The automatic EJB transaction management is useful but since it relies on exceptions being thrown and it can get very confusing, and often isn't flexible enough - we seem to resort a lot of the time to UserTransactions.
On top of that a complex database schema seems also impossible to map to Entity EJBs in a useful way. We have 300+ tables and the presentation layer needs all sorts of combinations of relations between the data that mapping the data into 'Entities' just seem to make data access inefficient.
EJB uses OO centric ideas, which tend to neglect data modelling. Class modelling is what its all about, data is not at the center.
You see it in the idea of entity beans that encapsulate data, and the higher layer of session beans that encapsulate process (i.e. business logic). It encourages you to not use RDBMS business logic (such as constraints, triggers and a sound datamodel).
Lighter approaches such as the simpler "model-2" servlets, using plain JavaBeans as data access layer much more leads you to put more emphasis IN the database and less in all kinds of layers outside. It leads to simpler and more robust systems with (generally) better thought out datamodels.
Hmmm....perhaps, then, Java is not a language for beginners. Not all tools should be for the novice. While I have known many beginners who have done just fine with Java, if it presents a problem for you, find another language. Visual Basic perhaps.
Of course, one could also argue that folks would be a lot better off starting with Assembler, moving to C, and then to Java. Especially with Assembler, at least *then* they would have an understanding of what actually goes into an I/O instruction as trivial as "print". It's wonderful that your language of choice makes it so easy to do something such as "input a$", but when it doesn't work, do you even know why?
For those who are so inclined, Java allows you to get down and examine the compiled code instruction by instruction. Can your language? I'm not trying to suggest that Java is necessarily better, I'm just tired of amateurs like yourself insisting that it's a bad language. It's not. You don't like the fact that you are forced to adhere to the OO paradigm? Use a different language. You don't like the fact that Java compartmentalizes functionality into packages and gives you access to a deeper level of ability and interaction with the operating system? Use a different language. You don't like the fact that low-level system calls are sacrificed at the expense of portability, a feature that many of us *do* need? Use a different language.
I have no desire to start a flame war, here. But it is crucial to accept the fact that different languages exist for different purposes. Languages like VB are great for quickly getting a GUI-based app up and running. Perl and Python are fantasic for kicking out small CGI-based apps. But for building large-scale, scalable, distributed applications, I'll take Java and, where appropriate, EJB every time.
I've noticed that you have made several posts in this thread denoucing both EJB and Java as a whole. I have to wonder why you are so persistent in this battle when you are clearly not a Java developer. The book, Bitter EJB, is clearly for EJB/Java developers. The review was written for the book. This thread exists for the review. Thus, the thread is for EJB/Java developers. Why do you continue to participate in a discussion that you have freely admitted aren't in support of?
As for the language itself, it has become apparent to me, from reading back over your posts, that you either are not a professional programmer, or that you did not spend an adequate amount of time evaluating Java. Again, not every language is right for every person, just as not every tool is right for every job. Still, I'm at a loss as to why you are being so persistent in displaying your ignorance about Java, EJB, and distributed architecture in general.
Care to comment?
Ryosen
One man's "Troll, +1" is another man's "Insightful, +1".