What
is the future of EJB3
in the
industry , g
iven the current trends ?
There are a
lot of arguments regard
ing EJB3 be
ing heavy we
ighted .....
A
lso, what cou
ld be the a
lternat
ives of EJB3 ?
How about the sca
labi
lity, pers
istence, performance and other factors ?
Reader Comments (5)
Isn't the problem there's a heavy inertia from J2EE? It will take a while for new projects to adopt the new technology. Even then why not just use servlets, hibernate/JPA, spring, and your favorite AJAX library? REST/JSON is beating SOAP. I don't really know about JMS. And still others are dumping the Java stack for ruby, python, and PHP stacks. Why would you use it?
What do you think?
Here's another opinion http://www.infoq.com/news/2007/12/interview_ruby-rails-dave-thomas">Interview: Dave Thomas on Ruby, Rails and Choosing the Right Tool:
I don’t even know how a beginner J2EE developer gets started, because the stack of books you have to read just to write a simple J2EE application it’s probably 5-6 feet tall.
It’s a lot of pain for not much payback.
But Dave certainly isn't biased :-)
What about j2ee architect certification, I think Sun should review the content
The problem is not that EJB3 is heavy weighted. The reason for calling it heavyweight is 99% of all dev's/apps don't need rmi, clustering or a message bus. As soon as you actually need those features Java Enterprise Edition is more lightweighted than most other systems.
As soon as you use spring with rmi, activemq, jetty, openjpa and terracotta you might as well just use apache/geronimo and end up with a prebuild clusterable bundle.
Anyway, you visit this page to learn more about message busses, (hibernate) shards or clustering, so do you really thing a product where you can get these features from the very beginning is bad? Or overloaded? I startet with JBoss, they have really good tutorials, you can get started in less then 5 minutes. Clustering takes ~30min. to try (propably not perfectly scalable, but at least a starting point). Clustering a JavaEE app is easier than clustering most DB's out there.....
Just my 2¢
EJB3 is much better than EJB2. This is a pretty good comment except that I completely disagree with your assessment that JSON/REST is beating SOAP.
The SOAP vs REST argument has been beaten to death already so I wouldn't want to add much to it. JSON is simply another lightweight presentation format vs XML.
I have to say that XML much more wide spread presentation format than JSON. The fact that it is too verbose is overcome a little by compression. The fact that all the standardized security implementation on top of SOAP is so much better than REST architecture where you pretty much expose your data structure by exposing the "resources" in REST style web service. The WS-Security stack on top of SOAP makes your application pretty much bulletproof, at the expensive of more verbose syntax.
Then the question becomes, are you willing to pay a little extra(CPU power and bandwdith) for WS-Security? The answer depends on how much you want to control your application exposure. If you have profit to protect in your web service, the advantage of SOAP then is immediate. If your application is a buffet where anyone on the planet can get a dip at it, then use REST/JSON to save bandwidth.