What applications justify the use of EJB?
BEA: Robert says that even for small apps, you should design with future migration to EJB in mind. Use EJB if your developers have the skillset for EJB.
JBOSS: Mark says: don't access the database directly from Servlets and JSP, use EJB intead. EJB caches data for web applications very well and can be ten times faster than ordinary database access.
Do you support JDO and what are your plans for JDO?
JBOSS: we have been supporting JDO for quite a while via Castor and other means. But, JDO has not taken the persistence crown. EJB/CMP is much more powerful than JDO. JBoss is working to decouple the CMP engine from JBoss so that it can be used independently of EJB. (Cool beans... RMH)
BEA: ... JDO is not compelling vs. CMP 2.0.
BEA: Robert says it is very difficult to predict the future, but that he sees that XDoclet-like method and field attribute driven development will be important and that web services will be very important.
I am not saying that EJBs are not useful. I am just saying that there are glaring holes in the EJB 2.0 specification regarding CMP. Why do you think there is so much buzz around JDO? Everyone is looking for a better Entity Bean.
If you want to buy or sell components, you will most likely want a layer of persistence in your components to work cross-platform on application servers (for example, IBM WebSphere, BEA WebLogic, JBoss/Tomcat, etc.) and persistence storage systems (for example, Oracle, DB2, etc.). You do not have to write low-level Java Database Connectivity (JDBC) calls in your EJBs to add these features, a great reducer of time and complexity. Once you get the hang of CMP/CMR, it is faster to write entity beans using this technology, than using low-level JDBC inside of bean-managed persistence (BMP) beans.
What does this mean to you? Well, for starters, you do not have to write low-level JDBC calls and, you do not have to write code to manage relationships. It is all built into the EJB framework. Your interface to relationships is through the pervasive java.util.Collection and java.util.Set which most EJB developers are already familiar with. Very cool!
This additional feature includes support for JavaBeans component patterns for persistent fields, inside of the entity bean. Thus, instead of making your class variables public -- which has always felt strange to me -- you create get and set methods following the JavaBean technology standard naming pattern we all know and love.
I can't stress this point enough. Since EJB 2.0 containers will support the most common SQL databases (and other data stores as well), you can write components that work with many types of databases. This makes it easier to sell components that require persistent storage. For example, you can sell components that will work in an IT department that uses Oracle or a shop that uses DB2. Thus, instead of writing low-level JDBC calls using SQL native to a particular database, you will use EJB-QL to create finder and select methods, and describe relationships in deployment descriptors.
Simply put, CMP/CMR is the missing link in cross-platform component creation. CMP/CMR will spur the growth of the enterprise level component marketplace. In addition, CMP/CMR is easier to use then low-level JDBC calls. CMP/CMR corrects many of the foibles, and missing functionality of earlier versions of CMP. There are many persistence frameworks, none are available on as many application server platforms as EJB CMP/CMR!
Also, there is a significant increase in productivity by using select methods and EJB QL. Code that use to take 10, 20, 30 lines of code can be written in just a few by mastering EJB QL.
Mark says: don't access the database directly from Servlets and JSP, use EJB intead. EJB caches data for web applications very well and can be ten times faster than ordinary database access.