Unfortunately, the fundamental messages in Bruce's article are almost lost due to Hyde-esque rantings. Bruce makes the classic mistake of recognizing the failures of EJB entity beans, and then projecting entity beans failure on all the rest of J2EE. Bruce says:
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
So I ate entities, and gorged on both stateless and stateful session beans. I wrote my book and my courseware, and built best-practices white papers, and consulted. I ate it all. The thing was, I thought that after putting in all of that time, the elephant would sustain me for a while, that I'd be able to make EJB work. I expected to be able to camel those resources, and let the energy boost kick in as I needed it. And I'd occasionally have little victories, but big problems continued to plague me
In fact, the first half of the article is a whine-fest about how he was forced into EJB to put food on the table on his family, and all the woes it has visited upon him. His bullets reinforce this "I couldn't test the stuff", "I couldn't teach the stuff", "I couldn't escape". He goes on saying "And I stalked it for months, and like many customers, I never really completely brought it down, but I stunned it enough to start dining. And I ate: CMP, MDB, JNDI. And life was a little better, especially on the persistence front".
Like I said, I agree that entity beans basically suck. But I have the mental capability of carving entity beans out of the J2EE spec and finding alot of usefullness from the remaining spec. Bruce started out talking about persistence, but ultimately we find him trying to convince us that MDB's, and JNDI, and stateless session beans are horrors that have been unleashed upon us witless Java developers. Apparently, you can't test or teach a JNDI lookup, or coding a Message Driven Bean and the (horror of horrors!) onMessage() method - and neither can you escape them! Buwahahahahaha!
I don't know what the "right" persistence mechanism is. Maybe it is JDO, maybe it's something else. But it's sad and a little frustrating to see someone like Tate extrapolate the badness of entity beans out into the entire J2EE world. Perhaps I am some sort of super-genius, but I've never found JNDI or JMS or stateless session beans very difficult to understand or program to. Indeed, Bruce seems to be buying into the extreme "lightweight" camp to the point of implying that a onetime JNDI context setup somewhere and lookup code should be reserved for rocket scientists and 180+ IQ super brains, and that stateless session beans imply some boondoggle requiring several million dollars to develop and employ. Again, maye it's the super-genius in me but I recall developing a bunch of stateless session beans in about an hour. Hell, unlike Bruce I even managed to test them adequately.
I understand people's dislike, even resentment, towards entity beans. I can even see why a large number of people are drawn to the so-called "lightweight" solutions. But I think maybe people like Bruce are forgetting what software development was like prior to J2EE. I remember it - and shudder every single time I think of it. If Bruce considers J2EE "untestable" and "unteachable", he should try writing the applications he's developing today in C or C++.
I don't think J2EE is the be-all, end-all. Unlike some, I don't take the "elephant" whole - I recognize that J2EE consists mostly of pluggable components, and (gasp!) I can choose what components I want to use and what ones aren't suitable for me. I think where Bruce fundamentally errs is that he feels to need, and teach, and test _every_ technology that comes down the pike - an attitude I've never really understood. Where I come from, I don't pick a suite of technologies and then hunt for a problem that fits it. Rather, I study the problem space and come up with the solution that fits it.
About the email@example.com