Stateless EJBs and MDBs scale fine. Many large scale applications are built with them.
Peter, can you share privately the success story? Are you sure it's not just stateless? ... So my belief continues to be "EJB for small
was discussed on the TSS that statefull session EJB2.1 scales same as the HTTP session;
sometimes is good to keep the state closed to DB in app server, sometimes is good to keep the state in client. Stateless service is not the best solution for everything.
also was discussed on the TSS that BEA CMP EJB2.1 can be faster than Hibernate
So it seems no one wants to challenge that EJB's are mostly for smaller projects
Spring/Groovy/iBatis for large"
but using EJB's to do data caching and object distribution has WAAAAAAYY too much baggage ... There is a better way, and it is writing and properly encapsulating JDBC code.
I prefer to use DAO and combine O/R (e.g. CMP EJB21, JDO, Hibernate) + JDBC SQL (e.g. iBatis) + JDBC SP (e.g. also iBatis) in one app. O/R mappings are ideal for a small amount of data cached the whole transaction. Some O/R frameworks allow to cache data across transactions. Some CMP implementations offer the read only CMPs. Also O/R mappings allow RAD and DB independence.
So ignoring of O/R frameworks in your apps has to force you to use some other type of caching to get similar performance/scalability.
I know a few huge disasters where they spent 8 digits and then pulled out EJB, and everything worked.
This is usually caused by:
- too big HTTP or statefull session EJB session data
- using remote communication/interfaces with the fine grained component model or in one JVM
- using CMP entity EJB O/R framework as only one DB access framework
In this way will suck EJB2.1, but EJB3 and Spring also.
I do not believe that rewriting the EJB21 app to EJB3 or Spring/Hibernate app will bring a dramatical performance / scalability benefit
I offer Struts, Spring, and Hibernate
Stateless EJBs are also now being replaced by more flexible AOP frameworks like Spring
IMO the enterprise mainstream is going to be JSF + EJB3. JSF offers couple of implementations and GUI RAD tools already. And also JSF offers the component model, what is a huge benefit for RAD. Hibernate3 is going to implement EJB3 O/R API anyway. And the easiest migration is going to be from EJB2.1 to EJB3. I also do not believe that Spring/Hibernate is going to be superior to EJB3, especially because EJB3 will offer at least about 10 implementations.
EJB is overkill unless you have a need to do distributed transactions, have massive scalability
I do not believe that rewriting the EJB21 app to EJB3 or Spring/Hibernate app will bring a dramatical performance / scalability benefit.
Also IMO this migration will improve a developers productivity for about 10-15 percents. I just will not implement the ServiceLocator.
The biggest EJB21 disadvantage is that it does not support the rich OO domain model, but in my case I do not use it, because of the relational DB. I want to be a good friend with my DBA.
and even then, an intelligent O/R model and KISS DAO framework go a long way.
was discussed on the TSS that BEA CMP EJB2.1 can be faster than Hibernate
also Oracle implements the CMP entity EJB21 by TopLink, SUN by JDO
of course you should always combine the O/R and KISS JDBC frameworks inside of your DAO implementations
EJB's have HUGE overhead on the development and production sides.
I fail to see how small projects would benefit from EJB's.
I am able to implement a CRUD for one table in 10-20 minutes. JSF + EJB21. SUN Java Studio + SUN Java Creator.
I do not believe that EJB3 and right tools will boost significantly my performance. If you implement EJB21 with VI than I understand your concern.
the network saturation that results from session and cache replication is ENORMOUS...let's let databases do what they do - CACHE and QUERY
you do not need to replicate the session. If your app does not go down very often and session data are not too critical, you can just go for the load balancing.
Anyway the motivation for that is that DBs are not still able to scale horizontally very well. App servers can scale horizontally almost infinitely. So we are trying to move as much load / work as possible from DB to app server.
"there is no component market => no component model (like EJB) needed"
The EJB component model is good for the manageability. You get nice statistics about your EJBs and it helps you to optimize / trouble shoot your up. It is not so strong as profiling, but you can not use the profiling for the everyday production monitoring
We've been able interview and hire junior and mid-level developers who were almost all immediately productive because the either came in with say Struts experience or could benefit from the various books and forums on Hibernate and Spring and ramp-up quickly.
IMO the biggest amount of people, which are offered by job markets now, are skilled in EJB21 area. And they will and it will be the easiest for them to migrate to EJB3.
The JSF with a right tool like the SUN Java Creator requires much lesser study curve than Struts