I found myself writing a response to Jared Odulio’s “post(EJB should really, really, really, really, really, really go away!!!)”:http://blogs.application-servers.com/roller/page/jaredflo/20040122#ejb_should_really_really_really, and realised that this was about the third time I’d written such a response this week. I felt putting the response here may be of benefit, at least to promote some legitimate debate on the subject (of which there seems to be little at present).
Jared Wrote:
EJB really sucks, Wanna discuss? First its principle contradicts some fundamental Java development pattern (e.g. multithreading for one). Second it’s the SUV of distributed computing; inadequate for its purpose, overkill for how it is currently being used.
I am beginning to suspect that those who admonish this just want to make more money(if they are an EJB vendor, if they want to overprice a project, if they want to bring up the false sense of future-proofing) and stretch their resumes.
People should really realise that EJBs are very good in certain very specific circumstances, and is overkill for most. Saying EJB’s should ‘go away’ is missing the point completely. It is an important tool in a J2EE developers aresenal, but it isn’t the alpha and omega. The majority of the backlash against EJB’s has come from people who have either used them in the wrong place or just didn’t understand how to use them properly. Perhaps some people were mis-sold EJBs by their vendors or even by sun, but those rejecting EJBs out of hand may be in danger of throwing the baby out with the bath water.
magpiebrain 
8 Responses to “In defence of EJBs”
Unfortunately, those very specific circumstances can be easily addressed by SOAP or JMS alone.
I may have tried to use EJB in the wrong place but nobody is certain where is the right place. Even the ‘right place’ does not immediately justify the use EJB as a solution.
Right now, I am still looking for a good problem that can be solved by EJB hands down.
Well, how about clustering app servers? EJBs transaction management makes this fairly easy…
I could write several cluster apps/services down from ground up and take control of everything. Instead of letting some EJB explain to me what fucked up what. As an advocate of XP, everything should be simple and we found simplicity in SOAP, JMS or even Jabber. In this way I could eliminate vicious app servers and the need to cluster it and that’s easier.
I fail to see how the use of SOAP, JMS or Jabber eliminate the need for clustering. Non-trivial J2EE applications typically need to be run on clusters because they need the power, and given the ecomomies of scale it is far cheaper to run on several cheap computers than one big one – just look at the recent OSX cluster running on G5 desktop machines, or googles linux server farm.
“In this way I could eliminate vicious app servers and the need to cluster it”…
Perhaps the context wasn’t clear. Of course, we can’t eliminate clustering per se. How much processing power do I need for a SOAP, JMS or Jabber cluster compared to the ones pockmarked with EJBs in it? We usually deploy non-trivial server applications(e.g. AI in Prolog etc.). We found EJB to be overkill in that environment and yet it eats up unnecessary resources.
Aren’t there situations where performance is of high priority, and the processing hit you take when using XML (SOAP, JMS) necessitates a switch to EJBs called via local interface?
Kyle, definitely no. When performance is high priority it is wiser to stay away in EJB further as matter of fact.
Actually I?d have to disagree there. There was a time when I said that, and in some instances that?s still true. If you?re running on a single box, then Hibernate or some other ORM is a better option. However if you need to scale large like CheapTickets.com has to do, then there is no single box on the planet except for an IBM big iron machine that will handle that stuff. CheapTickets and companies like them use EJB server farms to handle processing. SOAP is just an object access protocol similar to RMI/IIOP that EJBs use. Also SOAP and web services are not exactly ?fast?. For a few transactions per second they?re ok, but once you start getting hundreds or thousands per second then they become a bottleneck. SOAP was design for interoperability between platforms like java to .NET. EJBs a much better in terms of performance & system resources for serving enterprise data & business logic. JMS is part of the J2EE structure. Technical it uses EJBs as well. What EJBs offer are the ability to scale since a client requests an object from a group of machines. Need more performance? Add a box. Also most EJB containers have sophisticated object caching so you don?t hit the RDBMS every time you get an object. DBs take a pounding on most apps. So anything you can do to speed them up is a plus. Also EJBs have a security layer by design. EJBs are portable to other app servers and DB servers. Now having praised them, let me beat ?em for a sec. They suck when you have to learn the technology and/or build stuff. To me, building EJBs is like you hard coding SOAP envelopes into your calling classes or in separate XML files. Any time I see a point where I have to write XML files by hand, that?s a time I know that someone hasn?t built a tool for the technology. XML files and service specs aren?t created so you code them by hand. They?re made so a computer application can be design that can talk to the spec and create that stuff for you. Again, this is why JBuilder has actually pryed Intellij IDEA from my hands. They do an exceptional job creating EJBs, descriptors, and JBoss descriptors for me so I can focus on the app and test cases. There I get pissed at SUN is when I talk to my .NET friends around the corner and they tell me COM and .NET remoting is a snap. The .NET SDK, VM, and compiler is basically the same as Java. There no reason that SUN can?t do something as powerful that is much easier to use. š