The end of the EJB world?

[paul wheaton]

In the last 24 hours I have talked to several senior engineers and architects that are all singing the same song: EJB sucks.
The big promise of EJB is that if you follow bean law, nearly all of your scalability, multi tasking, multi user issues are resolved for you. Apparently, no implementation meets that promise.
Last night I was talking to a guy working at Global Commerce. He says that a year ago he was singing the entity bean song long and loud so they converted everything over to entity beans. Then things began to fail. With a distributed system, you can modify some data on one box and modify the same data, in a different way, on another box. Not okay.
Now they have just finished ditching all entity beans.
I've talked to some more engineers and a lot of them are saying that they have been burned by EJB and recommend against it.
To top it all off, I spent the last two weeks trying to do some bean stuff with JRun, only to discover that the JRun EJB implementation is awful. It took "our best engineers" two weeks to get a one line stateless session bean to work. Last night and this morning I heard "oh yeah, it's a well known fact that the JRun EJB stuff isn't ready for prime time".
Should I abandon all EJB stuff?

[Mark Herschberg]

I'm investigating EJBs now. From what I understand the 1.0 and 1.1 spec had a lot of problems. It was underspecified and inter-vendor compatibility wasn't practical. I also got the impression first generation products were slow and didn't scale well; but then, I expect this of most any product.
The EJB 2.0 spec is out, that supposed resolved a lot of compatibility issues. I don't know about performance.
--Mark
[e-mail]

[paul wheaton]

I heard that the version 2 stuff still isn't going to fix these issues.

[Matt Midcap]

I've heard the same about the JRun implementation. But not about anything else - am I missing something?
From what I understand, vendors are frantically trying to implement the "2.0" spec. Until everyone is there (this is still fairly new technology) I would be hesitant to judge EJB capability.
A comparable issue that I have seen, although it is a much smaller scale, is with JavaScript. Although it promises to do some nice things, it does not behave the same on all browsers. This is because the browsers don't precisely follow W3C specification with all of their functionality. Therefore JS has gotten a bad rap with many web developers, but it is still widely used.
Did this information come from Sun engineers?
Matt

[paul wheaton]

Some Sun folks, but mostly folks outside of Sun.

[Joe Guzzardo]

Gee Paul, I sure hope you're wrong about this. I'm staking my career on this right now. I'd like to refer you to the following url as just one piece of evidence (granted its not from an unbiased source): http://www.sun.com/software/cover/2001-0117/?frontpage-sunbox
Also, I've heard so much about the success of Weblogic in the marketplace. Or is it something that companies are toying with but haven't really used with much success in a commercial environment?
As Matt pointed out, and as we are all aware, this is still fairly new technology and it may take a few iterations for vendors to properly address performance issues. (In the meantime just run it in a Cray box)
Please keep us posted here with any additional information you come across.
Thanks.

[Matt Midcap]

Paul,
Do you think that these guys are a little frustrated right now for some reason or another (project late - combined with new technology, etc...)?
As you know, we use WebLogic, and not even to it's fullest capacity and we are very happy with it and it's capabilities with EJB. I did run JRun at my last gig and let me be candid - it did not deliver what it promised and ran differently on different platforms. I havn't seen the same with WebLogic yet - but then again I'm not a WebLogic expert either.
Anyway - it sounds like your engineers might have more of a problem with what JRun is supposed to offer but lacks, and are possibly blaming it on EJB. It would be an easy trap to fall into.
What exactly is EJB lacking that is promised in the spec??? Are you talking about just EJB or J2EE as a whole?
Best Regards,
Matt
[This message has been edited by Matt Midcap (edited January 20, 2001).]

[paul wheaton]

I posed this same question to a mailing list I'm on and a BEA guy that's on the same list admitted to all of the flaws and pointed out several strong points.
The key is that you still get a lot out of session beans. Entity beans are an idea with potential. We should see them live up to the promise in the next two to five years.
I'm convinced to continue on with EJB.

[Matt Midcap]

I agree with you about BEA - they probably have the best implementation of an app-server right now. Hopefully the rest of the industry will give'm some competition (competition drives quality).
So in summary, it sounds like the engineers are mostly dissapointed with JRun and are waiting for good implementations of app-servers to take advantage of Entity Beans.
Therefor, I think ringing the death bell for EJB/J2EE is a bit premature.
Joe - I don't think you have to worry about it. Besides, if you learn everything in the J2EE spec (JSP, Servlets, EJB, etc...), and you do it using OOP, you will be fine and ready for any other OO technology that may come along. I know a few C++ and SmallTalk engineers who are EXCELLENT Java programmers.
Best Regards,
Matt

[paul wheaton]

The EJB shortcomings I was concerned with weren't just in JRun, but in all implementations. Including BEA's weblogic. They failure to fulfill the promise is still there, but it's easier to start with a 90% solution, than to start with a 0% solution.

[Tony Alicea]

I didn't see any reference to IBM in this thread and that's the vendor we are using at work (WebSphere and Visual Age for Java).
I have not had any problems programming and using other's EJBs. In fact they are great abstractions to services that I need in my client code. In some cases I have no idea HOW the EJB gets me the info that I need in my Web app, nor do I care.
Entity beans better make it , since they are DB vendor-independent abstractions to persistent storage. Container-managed persistence (CMP) is a great concept, IMHO.

[paul wheaton]

The promise is multi user and distributed systems. The problem comes when you do both.

[Johnson I]

I agree to Paul that EJB Really Sucks ..But still it's in the evolving stage and not many Implemetations are being carried out throught the globe.
As the implementaions grow more problems will be popped up and it's going to be a challenge for the Sun Guys to beat the Heat out and come out with a better specification. Though EJB2.0 has been realsed with new additions and promising capabilities, still I feel that it's absolutly the time which is going to decide the future of EJB.
Johnson

[Mark Herschberg]

Has any tried any open source EJB servers, such as the one from Enhydra (http://www.enhydra.com/)? Are they any good?

--Mark
[e-mail]

[Jim Baiter]

The point I would pose is that all other attempts to do
similar things also seem to have failed. I know plenty of
engineers from esteemed companies saying that "CORBA sucks"
or "COM/DCOM/COM+ suck", etc. I think those who are going to
use this type of technology have to realize that they are early
adopters and need to deal with those risks.
Another problem I see is that projects will bring in EJB to a
bunch of engineers who are new to it (and frequently new to
Java & OO as well). Then they try and do all kinds of complex
things with it (huge databases, code generation, etc.). Wouldn't
it make sense to pull off a couple of simple projects with new
technology first and then iterate upwards?
In my mind, EJB has been a success. When I first heard of it,
I was a CORBA fanatic and thought the CORBA component model
would win out. The reason being that it supports multiple
languages and I thought that it would be too difficult for
Java to scale and certain infrastructures would need to be
done natively. There are plenty of examples that prove me
wrong.

[Saad Hamdan]

I have been working with EJB for about a year. We started with entity bean with weblogic 4.1 after converting to weblogic I start having problem with finder method. We are not using any entity bean but we are using session bean.
My experience with EJB so far is good.
------------------

[George Brown]

We had a load of problems with EJBs initially, and although we did adopt workarounds, we are still using app servers which implement the 1.1 spec. However, we are yet to properly deploy the beans that we have built. We'll do that later this year. Hopefully we'll get the chance to upgrade to an app server which implements the 2.0 spec soon.
One of my reservations with entity beans is that you need to come up with 'tactical' solutions to get round some of the flaws, ie avoid CMP, adopt workarounds with BMP to avoid so many DB hits etc. The result is that you use entity EJBs but hack around with the way they're being implemented to such an extent that they don't work like 'conventional' EJBs any more. Luckily weblogic servers are flexible enough to allow you to do that kind of stuff, but I have to say that if we used EJBs the way the books say you should - ie using a 'pure' model for entity EJBs, I feel that the project may have been in trouble.
I would still say that the technology has great potential. I still believe that CORBA also has a solid future for platform-independent component access, and especially for gradually migrating those legacy apps to a better component model.

[Michael Hildner]

George, why do you say to avoid CMP?

[Junaid Bhatra]

IMHO, Entity Beans is a great idea! Agreed that most of the app servers suck when it comes to implementing CMP. I've heard BEA engineers themselves do not recommend using the CMP provided by Weblogic 5.1. We therefore use a third-party tool, Toplink for CMP, which runs great & integrates well with Weblogic 5.1. Hopefully Weblogic 6.0 will be a great improvement on that aspect. But I'm not gonna rush out and buy 6.0 yet, given the number of service-packs & bugs that we had for 5.1!

[George Brown]

Originally posted by Michael Hildner:
George, why do you say to avoid CMP?

Just because there's a speed penalty to be paid by using CMP over BMP with the kind of legacy DBs that I seem to always find myself working with.

[Mark Spritzler]

We are using Weblogic 5.1, with Webgain Toplink. Our entity beans are CMP. 95% of the time it is perfect, fast, and gets the job done.
The only thing that failed was in the order of inserts. basically we needed to insert records into an Oracle table. It was the many table in he table relationship. There were multiple records to be added, and they needed to be added in the exact order the user entered it on the Swing client. Well the EJB's couldn't guarantee the insert order. We overcame it by adding a sort order field.
Except for that, EJB's have been the godsend we have been .looking for. I no longer need to worry about security and concurrency in Database Business Applications.
my 2 cents.
Sorry if there are any typos, I broke my right arm last week.
Mark

[ankush walia]

hi everyone!!

would anyone out here plzzzzzzzzzz help me out!!i'm trying to learn EJB right now!!and everyone out here is fighting to find out whether they r really helpful in real time scenarioes or not?? plzzzzzzzz tell me should i continue learning it or drop the idea??
ankush!!

[Matt Midcap]

Like I said before, IMHO, I think it is too soon to put EJBs to death. It's still a new technology and somethings have to be worked out - and they will.
I think you're safe.
Best Regards,
Matt
[This message has been edited by Matt Midcap (edited February 06, 2001).]

[Syed Hussain]

hi everybody,ankush is correct.Everybody is arguing about the short comings of ejb.Does this mean that i shouldnt study ejb and wait till it is corrected or may be switch to another technology.Confusing!!!

[Jim Baiter]

I would doubt that EJB in real-time is going to be of much
help. I think at this point the vendors are just trying to
get everything working as others have pointed out. I have heard
of people using JMS as a "real-time" job scheduler but as to
satisfying formal real-time requirements or running within an
RTOS - I haven't heard anything.

Originally posted by ankush walia:
hi everyone!!
would anyone out here plzzzzzzzzzz help me out!!i'm trying to learn EJB right now!!and everyone out here is fighting to find out whether they r really helpful in real time scenarioes or not?? plzzzzzzzz tell me should i continue learning it or drop the idea??
ankush!!

[murali c dharan]

I've been working with Weblogic for a year now..And the report is: Except for performance, everything is good!
One important point to note is, as someone has already suggested, No production work should be carried out with this Infant technology unless the engineers have an absolutely clear understanding of what they write line-by-line. I have seen cases where replacing a set of Entity Finders by a session bean querying the database directly, improve performance awfully.
That we are adopting this technology automatically binds us to wait for a performant implementation of the spec. As far as I see...there's a lot to resolve in the spec itself (Especially, standards for performant EJB coding has to be proposed by Sun).
And there's no near competitor to Weblogic for providing a compliant product.

[Max Rahder]

Paul, maybe you could be a little more specific about what you don't like about EJB.
I'm very skeptical about EJB, but don't have enough data to come to a conclusion about when to use it. Obviously, EJB adds a lot of complexity, confusion and cost. But there are benefits: any database application eventually needs to address object management, connection pooling, etc., all of which are provided by the EJB environment. Simplified implementations of those features aren't very hard to code using standard JDK classes, but such simple solutions aren't necessarily very robust or scalable. The irony to me is that most applications don't need to be very robust or scalable. Therefore, the question is For what type of environments and applications do the benefits of all EJB's sophisitication outweigh its costs.
For those of you successfully using EJB. What benefits are you gaining from it? How would you have done it without EJB? What were the costs of adopting the technology?

[erich brant]

Companies that say their products are not beta are lying!:
Examples here:

This is an xml/jsp/ejb application and it works well.
http://www.enhydra.org/ but this is in alpha!

Also test out www.jboss.org // I have not tried out jboss

The book below is the single best book on ejb! nothing compares
to it!
http://www.oreilly.com/catalog/entjbeans2/

Examples of beta products!:
Any tech. that is less then 5 to 10 years old most of the time is beta!
Examples: win 95 was a beta! win 2000 is also a beta!
second or 3rd edition of win2k will not be beta.
The java language is still in beta, and will be until,
jdk 1.5 to 2.0 ( about 2-5 more years ) Java's apis
are not fully compatibla with themselves, thus they are beta!
Since you test them not sun!

C++ was beta until 1998 ansi/iso. Thus it was beta since
1980! 18 years of beta C++! ! !

Other examples: XML is still in beta, the main reason is that
no browser fully supports xml, thus xml is not fully tested,
since browsers do not fully support xml !

COM+/DCOM is still in beta, because it is still changing, and
is not backward compatiable with itself.
C sharp is in alpha!

C programming language was invented in 1971 and became
ansi/iso in 1983! 12 full years! of beta and imcompatiblity
with different compilers!
The point is java and ejb and xml and com, and linux, etc...
are all beta! Anyone telling you otherwise is lying! They
are beta because they are not fully developed yet, and have
many years to go before their evolution is close to completed.
Also they are full of bugs! and the corps use users to test
bugs unknowingly and use you as beta testers!

[Thomas Paul]

We are using EJBs we are very happy with it. However, we are not implementing entity beans mostly because the actual data is in legacy databases on a mainframe. (We are using WebLogic).
Apparently, none of you guys have experience with TP monitors, which is what EJB really replaces. TP monitors were hell to implement. They were completely proprietary. Develop on one TP monitor and you were stuck with it. They were complex to code and deploy.

[Jim Baiter]

Have you looked at the J2EE connector architecture? Just out of curiousity, if so what did you think?

Originally posted by Thomas Paul:
We are using EJBs we are very happy with it. However, we are not implementing entity beans mostly because the actual data is in legacy databases on a mainframe. (We are using WebLogic).
Apparently, none of you guys have experience with TP monitors, which is what EJB really replaces. TP monitors were hell to implement. They were completely proprietary. Develop on one TP monitor and you were stuck with it. They were complex to code and deploy.

[Johannes de Jong]

Paul,
I dont know anything about EJB but I saw this article that might interest you http://www.onjava.com/pub/a/onjava/2001/02/28/ejb.html
JdJ
[This message has been edited by Johannes de Jong (edited March 02, 2001).]