Why would a developer choose one (CMP) over the other (BMP) and what are some key features we have to keep in mind when deciding to go with CMP since BMP also requires maintaining our own database access code (which we would like to avoid since all that is provided by the app server vendor if we use CMP)?
For example, we dont have an ORDER BY clause in the EJB QL now so sorting becomes an issue in CMP? Are there any other considerations like this?
There are many reasons why one would like to use CMP and ther are few why one won't the dessiosion is on to you how well u understand your needs.You can definately go for BMP if want to loose the advantages of a Container and can take the pain of maintaing every thing yourselves.........
By the way,there is OrderBy clauses in WLQL and i have used them neumerous times but can not say about EJB QL...????
Hope I an able to answer u....
THE main advantage of CMP over BMP is that with CMP, you hardly have to write (data access) code. And writing less code means less of a change of getting it wrong ;-) And not having to write data access code, means less problems supporting multiple database vendors!
With BMP you have to write all data access code yourself, e.g. using JDBC, meaning you have the utmost level of control. But the question is, do you need that level of control?
My approach: for each table in your underlying database create a CMP entity bean, but don't include any logic/code other than setter/getter methods. Then, write stateless session beans with all the business logic. E.g. a stateless session bean SalaryCalculatorBean might call several CMP entity beans, such as EmployeeBean, SalesBean, ...
About sorting: indeed, sadly EJB QL doesn't have an ORDER BY clause. This means the various vendors have implemented their own ways to sort data. E.g. JBoss allows an ORDER BY clause. And you could sort data after it has been retrieved, not too difficult a task using the JAVA Collection framework.
Also, don't forget that you can combine BMP and CMP, even adding some session beans with JDBC code in the mix if so required!
It is not necessary to have database as persistence storage. In such cases you have no choice but to write your own BMP bean, because only you know how to access that persistence storage to read and save data and container does not have any clue about it. For example, persistence storage can be a flat file.
Although I agree with most of your post:
> For example, persistence storage can be a flat file.
Wouldn´t that mean using java.io ??? which is prohibited by the spec??
It´s more likely that storage would be a ODBMS or someting that needs a connector instead of JDBC
"You can definately go for BMP if want to loose the advantages of a Container and can take the pain of maintaing every thing yourselves......... "
Ahh how nice that would be if it were true. Here's some experiments you can do to test the "usefulness" of CMP:
1) Using WebSphere, try building a CMP app to talk with an existing database *without* using VAJ/WASD. This is also known as "meet-in-the-middle" development.
2) Write a CMP app for one app server, then port it to another app server.
I have had experience with both these situations. Here's what I ran into:
1) WebSphere (v4.0 in this case) uses bunch of XML files to map your CMP EntityBeans. When generating deployment code with WebSphere (not VAJ/WASD), the mapping files are generated such that it assumes the tables are named like the bean, i.e. USER_ENTITY_BEAN, INVOICE_ENTITY_BEAN, etc. where you would actually want USER, INVOICE, etc.
2) As shown above, CMP mapping is proprietary. Migrating your CMP app between app servers will require a significant effort. The common response to this argument is, "Oh well, we'll *never* need to port our app off <insert app server name here>!" If you believe that... wait.
I will agree, doing an inital run of BMP beans can be a pain. This is when code generators come in handy. This is exactly what IBM does when you play with VAJ/WASD, but instead of having all the other limitations associated with CMP, you will now be free of vendor constraints.
Whoops! I forgot to explain the solution to problem #1. You need to have the XML mapping files in the un-deployed EAR prior to deployment. This way WebSphere will use your XML mapping files instead of generating new ones. Now the bigger problem: you have to make all these *very* cryptic XML files. Time to generate XML files... :)
Screw all that.
Own your own code. Be free from specific app server vendors.
Not that it helps you now, but the EJB 2.1 Public Draft specification of June 14, 2002 has an ORDER BY clause in the EJB QL.
Any idea when JBoss will support the EJB 2.1 spec?