I am thinking about building a fault management application on top of EJB, the more I design it the more I find it less usefull as I thought.
Here are the claimed EJB benefits.
1)Life Cycle Management. Servlet has that also.
2)Instance Pooling . Yes. This is good.
3)Thread/Connection Pooling. Most J2EE server has this regardless you are using JSP or EJB.
4)Threading. Yes. This is good if container threading is acceptable.
5)Caching, Transaction. Yes this is good for database applications.
6)Naming. CORBA/RMI has that also. Unless you are doing large federated system, my understanding is naming isn’t quite useful . But EJB mandates using JNDI which could be overhead for small to mid scale applications.
7)Security. Maybe. Most web servers have authentication. What EJB is emphasizing is method level security and role assignment. But is this level of granularity practical? Besides, what’s funny is that I downloaded j2ee sdk 1.3.1 from Sun and wrote a small EJB application, EJB client mandates a login module which takes almost 10 seconds to prompt for a login. This is ridiculous. Why make it mandatory? Why is it so slow? I couldn’t find any document to disable to login module.
8)Distributed. JSP/CORBA/RMI has that.
So EJB benefits are instance pooling, threading for all kinds of applications. Caching, Transaction for database oriented applications.
Mandatory using of Naming, Security can be headaches sometimes.
I can accept that EJB is not for every project. But I found EJB is much less useful than I thought it was. For a fault management application, I could only benefit from instance pooling/thread management. To me, EJB benefits mostly for for database application. Other J2EE technologies such as JMS, deploytool, support for JSP/Servlet, Thread/Connection Pool are real shiny and useful. I could be confused. Could somebody clarify?
I agree that servlets and plain Java can be as good as EJB for many applications. For an application which doesn't use a database (are there any?) I wouldn't bother with EJBs.
EJB security isn't mandatory, by the way, you can do all your security at the web server level if you so wish.
Some people like to do their ORM with CMP entity beans -- I prefer JDO, which obviously works fine with a plain servlet setup too.
I think message driven beans have a lot of potential for reducing the size and duration of transactions and making EJB apps more responsive, while still guaranteeing integrity.
I don't think RMI gives you distributed transactions, which EJBs do.
My take is. A whole lot of this is marketing. Just like MS OS was not, is not and will not be the best, they do have advantages over anything built proprietarily - the network effect. I worked for a company who built the most of middle ware structure themselves. Our ORM system (can't give the codename, sorry) was already doing a lot of EJB 2.0 stuffs two years ago. The point is though, in the long run, we can only be that good, while there is hope for EJB to have better 3.0, 4.0 .... because there are good bunch of good engineers working on it. The industry went through the painful 1.0 entity bean period and now they praise 2.0 . Sound like windows 95 launch? dejavu in our beloved industry!