Input parameters can only be used in comparison_expressions or collection_member_expressions, as defined in Section 11.4, "EJB QL BNF"
Rick Hightower is CTO of Mammatus which focuses on Cloud Computing, EC2, etc. Rick is invovled in Java CDI and Java EE as well. linkedin,twitter,blog
Rick Hightower is CTO of Mammatus which focuses on Cloud Computing, EC2, etc. Rick is invovled in Java CDI and Java EE as well. linkedin,twitter,blog
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.
Rick Hightower is CTO of Mammatus which focuses on Cloud Computing, EC2, etc. Rick is invovled in Java CDI and Java EE as well. linkedin,twitter,blog
You’ll find me in my office. I’ll probably be drinking. And reading this tiny ad.
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|