There are several significant advantages/reasons to using EJB3.
1) distributed transactions. how do you handle 2PC/XA with POJO classes? You need a container with JTA available. This is one thing that Spring uses EJB containers for (or at least used to) b/c Spring didn't/doesn't handle distributed tx's AFAIK.
2) interceptors. I always have a profiling interceptor in my Seam apps that will output to the log the amount of time it takes to exec a business method.
3) EJB3 timers. not as feature-rich as Quartz in EJB3 (no CRON jobs) but IIRC they added this to the EJB3.1 spec.
4) CMT. If you're not using Seam (@Transactional) then how do you declaratively demarcate your transaction boundaries. Also, Seam's tx doesn't offer as many tx types as EJB3.
5) web services with SLSB.
Arbi Sookazian wrote on Apr 09, 2009 18:44:
Local interface is no longer required in EJB3.1. So perhaps this problem will become irrelevant in EJB3.1...
Unfortunately not. Then all your client classes are dependent on the bean implementation, and you end up with the exact same problem. If anything it will make it worse, as currently if you loaded every ejb implementation class in its own classloader you could theoretically make any changes you want to the actual implementation, you just cannot change the buisiness interface.
well that totally sucks, doesn't it?
I received no reply from the EG or Kenneth. That means they can't do it, don't want to do it, or I'm asking a stupid question.
AFAIK I want to be stupid and quit using EJB and anything remotely related.
earthquake prediction, theoretical physics, 10 ft tall women, and derivatives of LSD are more interesting.
give up. ;)
"Those who say it can’t be done shouldn’t stand in the way of those who are doing it." ;-)