This post originated from an RSS feed registered with Java Buzz
by Thomas Gideon.
Original Post: Appropriate EJB
Feed Title: Command Line Interface
Feed URL: http://www.gideonfamily.org/roller/rss/cmdln?catname=Java
Feed Description: The blog of a programmer-hacktivist-curmudgeon who occasional rants about society, work, and technology, among other things. Now how do I get to a command prompt on this thing?
The use and value of EJB's seems to be a pendulum topic. I admit I've contributed to these discussions, but my genuine perception is that EJB is like any other tool, sometimes it is appropriate and sometimes it is not. Hani has expressed a reasonable view about where EJB adds value. Others have, as well, when there is a clear need. But the most level headed view is understand what value they have, what value the rest of the J2EE suite has, and where to use each particular part.
My own vexation stems for our use of EJB's internally, at least entities, where we really don't get any of their benefits and yet we still have to endure the pain of deploying and managing them. I may have not qualified my own complaints about their limitations that these are limitations that specifically rob them of value in our environment. Personally, a more modern environment would seem to address most of my complaints, I'll let you know if I ever get to work on one.
We do not run a 2.0 or (if there are any such) 2.1 container. I know, but we don't have a migration policy. Each time we have upgraded our container, we have done so while kicking and screaming and purely in an ad-hoc fashion. When we stabilize on a particular version, we slowly accumulate patches for intermittent yet very painful problems that crop up in production. Management, therefore, feels that the cost of upgrading to a newer version that may re-introduce these problems, or, worse, new ones is unacceptable.
Will they let us do performance testing and burn-in testing that might find these issues before the system goes into production? No, that also is apparently an unacceptable cost for what they consider little to no benefit. So we have to constantly put out fires that are complicated in large part by our use of EJB that might have been somewhat mitigated by using a simpler persistence mechanism.
Now, though, we are finally talking about doing some sort of clustering. After at least two years of haranguing management about doing so. At least now our investment in EJB may pay off, since clustering is a valid driver for using them. Of course, one has to wonder what cost we paid in the meantime in using EJB's when we didn't really have to and if it outweighs the original cost of using EJBs so that if we had deferred that option, the long run cost would have been much lower. Who knows.
Previous Topic
