• Post Reply Bookmark Topic Watch Topic
  • New Topic

Best design practices

 
amit mawkin
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Would like to know which is better
a CMP with advantage of less control and coding
or a BMP with more coding and more control.
Different people say different things .I want to know your opinions.
 
Chris Mathews
Ranch Hand
Posts: 2712
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
With the use of design patterns such as Session Facade I do not see BMP as useful for much of anything. Since EJB 2.0, CMP performs better and offers significant coding advantages (no persistance code) over BMP.
When would I use BMP? At this point in time I would say never. I would rather go with CMP or straight Session Beans and circumvent the peformance woes of Entity Beans entirely.
When JDO becomes widely available then I would consider that as an alternative to CMP. Right now for automagic persistance, CMP is the only game in town (standards-wise).
 
Joshua S. Moyer
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
BMP hands down. If it ain't broke, don't fix it.
 
Chris Mathews
Ranch Hand
Posts: 2712
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I see the performance of BMP (or lack thereof) as being broke. The overhead is too great for the advantages (which I don't see). Name one advantage to BMP that cannot be achieved using a Session Facade with DAO or JDO?
 
Simon Brown
sharp shooter, and author
Ranch Hand
Posts: 1913
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with Chris - CMP provides you with an easy to use persistence mechanism along with performance advantages such as lazy loading, caching and so on.
Simon
 
kettle
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Decision is based on various aspects of the application and datbase you are going to use. As complex database access using CMP is very complicated and you have to manage many fine grained CMP's.
So its not easy to say.
Kettle
 
Chris Mathews
Ranch Hand
Posts: 2712
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am not trying to say that CMP is the answer to all problems... far from it.
The question is: does BMP offer any over Session Facades + DAO?
My answer is: I don't think so.
If I can't do whatever it is that I need with CMP then I am just going to go with Session Beans + DAO and skip Entity Beans altogether. It also seems that many people forget that CMP and DAO can peacefully co-exist. CMP gets you 90% of the way, DAO will get you the rest.
 
Simon Brown
sharp shooter, and author
Ranch Hand
Posts: 1913
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
...just to put some real-life spin on this, in one of the systems that I've just worked on, we purposely used an architecture consisting of some EJBs that used CMP for read/write and session facade/DAOs for high speed, complex queries. Worked for us really well.
You are right about it depending on the situation though.
Simon
 
Rick Hightower
Author
Ranch Hand
Posts: 350
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have to agree with Simon and Chris.
And I would like to add the following...
Use CMP about 80 to 90% of the time. For special cases (complex queries, high speed access) use Session with DAO.
I find that using caching with CMP real speeds up your web application a lot.

I wrote a quick start EJB tutorial on using CMP 2.0. It has been ported to Resin, JBoss, WebLogic and Sun's RI.
Here is how you can find it....
Just go to google and search for EJB CMP
Click on the first link...
I think JDO is promising, but I have to agree with Chris... at this point in time stick with EJB CMP 2.0.
I think in the future (EJB 2.2 or 2.3) that EJB CMP and JDO will merge or rather EJB CMP will be built on top of JDO and it will extend the base functionality of JDO. This is just opinion.
 
Rick Hightower
Author
Ranch Hand
Posts: 350
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

BMP hands down. If it ain't broke, don't fix it.

I would agree with you, if we were talking about EJB 1.1. But EJB 2.0 should be a tool in your tool box.
I have recently read a lot of articles about whether or not developer should use EJB.
The argument against EJB tends to be that they are too complex. This is ironic since EJB's purpose was to simplify server-side development. While I agree that EJB is not for every project, I think recent advances in tools and techniques equate to EJB being more applicable to more projects, and these articles tend to leave these new advances out.
Resin EE is a good example of "recent advances" as it seems to bring EJB to developer who might not otherwise use it through its support for EJB Local beans, CMP, CMR and EJB QL. Resin CMP was more geared to a replacement for JDBC and transaction mgmt than EJB for the sake of EJB. Resin CMP evolved into Resin EE.
Of particular interest in developer productivity with EJB is CMR, EJB QL and XDoclet (subproject EJBDoclet). Basically, the productivity and utility of these tools have to exceed the inherent difficulties in using EJB in order for EJB to be considered on a project. These tools lower the bar to entry while increasing the utility and make more projects candidates for EJB.
XDoclet, an open source project, simplifies EJB development by using JavaDoc API and some additional APIs as a code generator so that a developer only has to maintain one file instead of 5 or more files (,i.e., deployment descriptor, local interface and/or remote interface class files, local home and/or remote home class files, vendor deployment descriptors and/or conf files, bean implementation, primary key class files, value class files and more.)
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 lines of code by mastering EJB QL.
When you combine XDoclet simplification with EJB-QL and CMR utility, you can use EJB on a lot more projects.
With CMR it is really easy to work with the standard collections API (which we all know and love) when dealing with one-to-many and many-to-many relationships between entities.
EJB 2.0 specification has been out for a while. Have you tried the new features like CMR and EJB QL? If so, what do you think?
My personal experience is that finder and select methods (written in EJB QL) are really productive and can save a lot time. Is EJB QL the killer tool?
I think so.
 
Rick Hightower
Author
Ranch Hand
Posts: 350
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

As complex database access using CMP is very complicated and you have to manage many fine grained CMP's.

I don't agree with this. I think CMP 2.0 is easier than doing BMPs. CMP 2.0 + XDoclet speeds development.
Give it a try. It works. I wrote a quick start tutorial. I swear it is easy to use.
We used it in production at eBlox, and we loved it.

A self-proclaimed technology masochist, Rick often enjoys working with cutting-edge technologies. "Expect to bleed a lot if you are on the cutting edge", is one of Rick's favorite sayings. On a recent project that predates the EJB 2.0 specification, Rick and others adopted EJB CMP/CMR as there persistence layer of choice before the EJB 2.0 specification was finished.
Many a night, they doubted their decision, but it all worked out in the end. Rick states: "We did not want to use a non-J2EE compliant persistence solution, since we want the freedom of porting our application to other J2EE application servers, and the possibility of selling components that we created. In the end, it looks like going with EJB CMP/CMR was a good decision, but there was some pain along the way as we were using the specification a lot as our main form of documentation, and we were one of the first users of this implementation of CMP/CMR."
"We were able to help the vendor by reporting problems. Some of the problems were our perception of the specification versus the vendors perception of the specification. The vendor was usually right (that said we were credited with reporting (and one time fixing) quite a few bugs)."
"One of the advantages of this decision was our team got to work with a solid implementation of CMP/CMR a long time before it was available anywhere else. We now use EJB CMP-CMR for all projects. I am a big EJB CMP-CMR fan! This new feature will drive the adoption of EJB even further."
Since the team was practicing XP, they were able to come up to speed really fast on EJB CMP/CMR and EJB QL. Pair programming really spread the knowledge as each member learned and shared different parts of EJB CMP/CMR and EJB QL.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!