My RSS Feeds
I think people miss the point about EJBs.
Yadda, yadda, yadda. Mostly crap.
Look: the problem is the mindset of the programmers. You get used to thinking in terms of your desktop: instant response is King, and if it fails, fine. Try it again, and expect instant response. If it fails, fine. Try it again, and expect... you get the idea, I hope. We, as programmers, look at what we use every day and it colours how we write for the enterprise. We want that sub-nanosecond response, and we're willing to write for it, damn the consequences... and anything that causes us to go to millisecond response is simply too slow to tolerate, and thus it's bad.
The enterprise doesn't work like this. In the Real World in which I live, what matters isn't that sub-nanosecond response time: it's "Did it happen? When it did, was it right? How hard is that to repeat?" Give me a guaranteed delivery and I'll trade you milliseconds, especially since people can't detect granularity on that scale for an individual transaction.
EJBs give you a neutral datastore. For all those programmers copying jar after jar after JDBC driver into their app, this is a good thing. They allow you to look up your elements, instead of having to go out and FIND your data.
EJBs can give you transactional integrity, if you want it. Considering some of the pain inherent in JTA, EJBs are nice in this regard.
EJBs give you role-based access. If you need it, this is also nice.
Are EJBs THE SOLUTION? No. There will be cases when tuning is absolutely required, when the cost of checking roles or looking up contexts (or dealing with wire-time semantics) is simply too high to bear. That said, I still think people are judging them on the merits of how they match up to desktop performance metrics, and they're simply not meant for that. Stop saying that the oranges you bought simply don't taste like the apples you wanted. Decide to let them be oranges, with their own strengths and weaknesses, instead of whining about them on the basis of a performance metric that's biased by what you use.
You're completely right. I think the problem that has occured since EJB's
were first released is that a lot of people (myself included) thought they
were THE persistance solution (back then of course there was only standard
java serialization or raw JDBC really). People realised that they were
using a sledgehammer to crack a nut, and then started complaining that it
was too heavy to lift. What we ware seeing to a certain extend now is a
backlash against EJB's. EJB's have their place, its just taking people a
while to realise what that place actually is.
Sam Newman [sam-newman@magpiebrain.com]
What are you talking about here, EJBs or Entity beans?
Entity beans are pretty much universally agreed to be the work of Satan.... Ok, not quite that bad, but why use them when I can use Hibernate, have better performance, better OOD, and less coupling to the container?
EJBs are a different story... It's not about performance w/ EJBs for me, although the extra performance hit on top of the other disadvantages doesn't help matters. What matters for me with EJBs is PRODUCTIVITY. EJBs suck development cycles from developers who could be doing something useful. There's all of the complexity and pain of building them, with their multiple interfaces (an extra 2 Interfaces may not seem like much, but when you have 100's of EJBs...) and the deployment descriptores, etc.... Plus, to test them you have to run a container!! There goes a minute or so for every test...
The point is that for the limited VALUE they bring, they COST a lot (in the terms I just described) and can be replaced by some lighter weight infrastructure that won't soak up so much of your time for the same services.
Jason Carreira [jason@zenfrog.com]
I thought the original point was to use EJBs for re-usable business
components. That way you could connect EJBs together with very little
coding or something like that. Then drop them into the platform of your
choice. I thought they were supposed to be the ActiveX/COM components of
enterprise java
Instead, they've become this bloated, unintuitive web app framework. Their only point to me is they make us Java developers a lot of money.
Ryan Ackley
Yeah, I probably should of clarified my point - I was talking primarily
about entity beans. I think the point that EJB's were supposed to be
reusable components but really aren't is well made - most people use the
standard session bean facade and neglect to decouple the code behind the
scenes. EJB's can theoretically be nice, decoupled components, however when
was the last time you found a third party EJB that you integrated with your
code?
Sam Newman [sam-newman@magpiebrain.com]
EJBs should be culled from the herd of J2EE APIs. It is a failing of J2EE
that they haven't done it already. There is nothing "Enterprise" about EJBs
and the fact is there is nothing worthwhile you can do with EJBs that can't
be done more productively (today) with other approaches. This wasn't true
when EJBs were just a promise, but things change and EJBs didn't...
I don't know of any successful large EJB implementations (entity EJBs that is), other then my own (and I succeeded by bypassing most of the EJB stack). If you know one, please post about it and how successful (that is positive ROI) it was, and numbers.
Steve
J2EE and EJB has not become interesting to me until EJB 2.0/2.1 added the
message driven bean coupled to JMS.
What I didn't like about J2EE and EJB prior to that was the remote interface access via RMI or SOAP.
Basically I've used RPC protocol in one variant or another for over a decade and it just sucks so bad that I can't take it any more.
But not to fret. JMS has really matured and come of age via a lot of vendor support. Course Tibco has their Tibco Enterprise JMS and there are some great JMS solutions that aren't near as spendy as Tibco - so no one really has any excuse anymore.
Now with JBoss and message drive beans coupled to my preferred JMS provider I'm one happy camper, and finally am singing the J2EE EJB tune. (You can use session and entity beans via their local interfaces from MJBs, as well as directly party with JDBC stuff, or use JMS to send a message.)
Finally, with a sane message driven communications, J2EE can begin to pay off on its promise in taming distributed application development for enterprise hetrogeneous networks.
Sul Ross [sulross@hotpop.com]
To: Jason and Ryan,
Guys, you cannot be more right. I am second month
in pain with 'legacy' over engineered EJB app that is sucking our
development cycles like crazy, and even with our fat budget my bosses are
stunned by the cost. We/they are paying the price of a politically correct
decision made back at the time the EJB was the buzz word...
And please
don't tell me that we are a bunch of morons and/or we don't have the right
tools.
ivo
* If your EJB's are taking too much time, you are not using the right
tools.
* If you are writing any more than one source file per ejb, you
are not using the right tools.
* If you ever have to write a deployment
descriptor, you are not using the right tools.
Try XDoclet, and
you'll see how productive ejb's can make you.
Wow I feel like an evangelist! But seriously, for a project I'm working on, we were able to elimintate all of the home interface, all the remote interfaces, all of the deployment descriptors. They are all generated for us at build time. Then we extended XDoclet a little bit and now we don't have to write any of our business delegates. We are working on another small extention, so we won't have to write much code to get webservices either.
Geoffrey,
We use XDoclet. How long have you been using it? You've extended it you say... Have you used XDoclet across a major EJB release? How do you think your modifications are going to do when XDoclet keeps moving? Plus, Xdoclet 1.2 is never coming out... 2.0 is out there in alpha code land, but will it be backward compatible? 1.2 is not backward compatible with older versions.
There's more to a large scale development than "my tool will handle that for me". At some point you pay for complexity, even if you put it off for a while.
Jason Carreira [jason@zenfrog.com]