Use of DAO in SCJEA Assignment

[Kodo Tan]

Hi all
From my discussion with at least 10 developers doing SCJEA part 2, it seems that all of these people are using DAO for the entity beans.
I'm currently doing my SCJEA part 2 and my implementation is to use CMP, and hence, does not need to use DAO. My concern is that since CMP is recommended (for most circumstances), why does everyone wants to use DAO (BMP) ? Is there any issues that warrant the usage of BMP beans and that I do not consider ?
From the discussion, the developers cannot give me a justification. It seemed to me that they use DAO so that they can introduce such a design pattern (in addition to other various patterns to their design).

[herve attia]

Kodo,
A common problem is the direct mapping of the object model to an EJB model (Entity beans).
Entity beans should not represent every persistent object in the object model (database schema) !!!
If you choose this way, your system will have a large number of entity beans.
That will impact your manageability (more class to maintain home, remote, primary key...), security, transaction.....network performance (more inter-relatioship entity )...So scalability will decrease.....not good !!
Solution : Entity beans should be implemented as coarse-grained objects....using a Composite/Aggregate entity bean pattern!!!
Example : In your database, you have the following tables : Customer, CreditCard, Address....
Modeling entity beans for each table is not good practice as I explained above (fine-grained design).
Instead, implement a "Customer CMP entity bean" but you map your persistent field related to creditcard and address with a DAO object.
Use ejbPostCreate() , ejbLoad(), ejbStore() methods for the synchronisation.
SCEA part II expects a good scalable design. If you design your project using a fine-grained approach...I'm sure that will impact your note as well !!! ;-)
I'm preparing SCEA part I....I'm not yet in SCEA part II... :-(
Hope it helps,
regards,
herve attia
You can still have Entity CMP
SometimesEntity beans

[Eric Handbury]

Herve,
Excellent answer, but in my opinion, a little too excellent.
IMO, The question posed by Kodo falls into the 'please help me pass my assignment'-type question. And these types of questions do us all a disservice because we all get the answers the easy way.
What Kodo should do is to design his solution using both CMP and DAO and see the differences/problems himself. Then he can make an informed decision as to which one to use. This is what an architect in the real world does.
We all know that doing the research ourselves pays off in the end because we learn so much more than if someone just gives us the answer. The object of the SJEA assignment is not to pass... it is to learn J2EE sufficient enough to pass. And there's a BIG difference.
My $0.02. Eric.

[Kodo Tan]

Hi all
Perhaps my original message was not clear enough that it has been misunderstood.
I'm not posting for people to help my assignment. (If you see the old archive of this forum, you should realise that I have earlier condemned those who have posted their answers at their web site).
I'm fully aware that entity beans needs to be coarse-grained and that is where Value Objects, Facade, Composite patterns are valuable.
I have also implemented J2EE applications using CMP and BMP (with DAO) and observed the merits of CMP in most situations. It is also more scalable.
My question is : Why would those developers taking the certification want to do it in BMP manner ?

[Kodo Tan]

Hi Herve
I refer to your comments "Instead, implement a "Customer CMP entity bean" but you map your persistent field related to creditcard and address with a DAO object."
Isn't this should be VO (Value Object) rather than DAO ?
Regards.

[Kodo Tan]

Hi Eric
Please re-read my first posting. I think you have misinterrupted my posting.
I fully agreed with you that "The object of the SJEA assignment is not to pass... it is to learn J2EE sufficient enough to pass. And there's a BIG difference." I think no one else in this forum will disagree with that.
It is in this spirit that I have posted my first message. I'm concerned that are the many developers doing the assignment without really understanding it. It seemed to me (at least for those who I have queried their designs) there are alot of them are using DAO pattern just simply for the sake of introducing design pattern to their assignments.
I bring up this issue here so that anyone who is in the same situation above can think about his design again.
Regards.

[SJ Adnams]

See http://www.iplanet.ne.jp/developers/ias-samples/jps1.1.1/docs/patterns/ for a discussion of the patterns used in the Pet Store application.
------------------
http://www.x-nt.com

[Kodo Tan]

Hi Simon
Before I start my assignment, I have read all the available resources I can find on design patterns. These included GOF, Cooper's book and Core J2EE patterns etc.
For those who really know what's DAO, it is not "required" when CMP is used. Below is the extract from the patterns resources
" Container Managed Persistence may make Data Access Object unnecessary. Container Managed Persistence already abstracts the data persistence mechanism out of the enterprise bean logic, making DAO superfluous "
From the posting so far, it seems that either the sender does not understand the issues I'm voicing out or mixed up Value Object with DAO. Some merely criticises without knowing anything.
Regards.

[Tiger Scott]

Hi Herve:
Where are the details on the - Composite/Aggregate entity bean pattern available.
thanks
Sanjay

[herve attia]

Originally posted by Kodo Tan:
Hi Herve
I refer to your comments "Instead, implement a "Customer CMP entity bean" but you map your persistent field related to creditcard and address with a DAO object."
Isn't this should be VO (Value Object) rather than DAO ?
Regards.

Kodo,
You need to use both : DAO and VO.
One of the main issue in J2EE architecture is network overhead, latency....
As I said DAO object will help you to decrease large number entity beans.
Another way to use DAO object is when you need to implement a complex finder method that you cannot accomplish using entity CMP finder methods. ...Stateless session bean is the most appropriate place...
Furthermore, the common problem with entity CMP finder methods is that it returns a collection a remote reference.....not good (some ejb server might create/activate all of them....that will impact your system ressource )!!!
Solution : (in my personal opinion) implement finder method with DAO and return collection of VO objects instead of remote reference !!!
One rule of thumb is to do not expose entity bean interface to the client...because you will allow him to build in own business logic....CLients (applets, servlets....) are Presentation-centric...
regards,
herve attia

[charles zhu]

Another usage of DAO is to privide the J2EE Fast-lane reader design pattern. In the petstore sample, catalogDAO is used to
bypass the whole EJB layer, feeding the presentation layer with quick but outdated response. Since 90% of the user just do browsing, the response speed is more important.
-Charles

[ruilin yang]

DAO could allow to adapt the entity bean (BMP)to work with the data access to different schemas or different type of database.
CMP has some limitations compared to BMP. That may be the reason why some people prefer using BMP with DAO.
[This message has been edited by ruilin yang (edited October 11, 2001).]
[This message has been edited by ruilin yang (edited October 11, 2001).]

[SJ Adnams]

Hi Kodo,
I'm sure you've done just as many exams of all variaties as me so you will know it's all about telling Sun what they want to hear. I'm working on part 2 also (I've spent around 5 hours so far reverse engineering the pet store application ) there are some things in the brief which make no sense.. an E10000 Appserver??
Sun want to see a solution that is scalable, J2EE platform & database independent, for this reason BMP exists throughout the petstore. Want to run iPlanet with Oracle and BMP?? fine. An Object database? Nope
I just want to get this exam out of the way, I'll be happy to get 75%, if I get 95% I will think that I spent to much time on it
Sun don't want you use CMP simply because most combinations of J2EE & DB Vendors are simply inoperable. Well thats my opinion.

------------------
http://www.x-nt.com

[herve attia]

Originally posted by Sanjay Bahal:
Hi Herve:
Where are the details on the - Composite/Aggregate entity bean pattern available.
thanks
Sanjay

http://www.togethercommunity.com/docs/5.0/j2eepatterns/CompositeEntity.html

[Andrew Tyson]

Simon,
>Sun don't want you use CMP simply because most combinations of >J2EE & DB Vendors are simply inoperable. Well thats my opinion.
Surely one of the major strengths of CMP is the low level of coupling between the EJB abstraction and the underlying data-sources. Does it matter that the container vendor uses a proprietry mechanism for implementing the plumbing/wiring code when it's all done at deployment time? As long as you can create a DataSource for an underlying data store you should be able to port a CMP EJB to that underlying datastore.

I would have thought that the main criticism of CMP (certainly with EJB 1.1) is that you invariably end up with a fine grain abstraction where each bean instance has a one to one mapping with an underlying row in an RDBMS.
Further the developer has no control over the EJB's behaviour when the container synchronizes its state with the underlying datastore (whilst not mandated realistically occurs on a per business method invocation of the EJB). Clearly using BMP and DAO the developer has greater control over these aspects.
What do other people think about this?
Thanks and regards,
Andrew
PS If you read the spec carefully it says "E10000 as the machine for the App Server".
[This message has been edited by Andrew Tyson (edited October 11, 2001).]

[Tiger Scott]

Herve,
Thanks for the link - but I keep getting an error in trying to access it:
You don't have permission to access /docs/5.0/j2eepatterns/CompositeEntity.css on this server.
Were you able to access it?
Thanks
Sanjay

[SJ Adnams]

Andy, my point was that $1m hardware for an Appserver was overkill. A Cluster of E450's would be fine for this kind of application.
------------------
http://www.x-nt.com

[Andrew Tyson]

Originally posted by Simon Lee:
Andy, my point was that $1m hardware for an Appserver was overkill. A Cluster of E450's would be fine for this kind of application.

point taken, in fact from an availability perspective horizontally scaling the app server host would be a better option.

[Tiger Scott]

Hereve:
I got it. The server may have been temporarily down.
Thanks
Sanjay

[herve attia]

CMP versus BMP.
---------------
Which approach to choose for mapping EJB Objects and data storage ?
Well....it depends of your EJB Container !!
As we know, with CMP, deployment descriptor tells the container which attributes of the entity bean to persist.
Flexibility is therefore governed by the vendors of the container and database
So, the container will manage the caching of the entity object'state and synchronizes the instance' state using a specific "commit options" (refer to EJB1.1 spec 9.1.10).
Does the container will optimize the loading of the data ?
Does the container will optimize the storing of the data ?
Well, I don't think that the EJB container is aware about what data has changed in the CMP entity and need really to be persisted !!!
So, Architect needs to be EJb container-aware before choosing between CMP approach.
With BMP, you have explicit control of the management of a bean instance's state.
BMP advantages are performance, ability to build complex relationships among data, an interface to complex legacy SQL databases via JDBC ....
When the ejbLoad() is called ...you can optimize it using a "Lazy Loading Strategy" : Load only the Entity's dependent objects that you need first during the initialization....and implement a load on demand when the client requests the others dependents objects.
When the ejbStore() is called....this time, you know exactly what data need to be persisted using a Dirty Marker Strategy : All the dependent object of your entity bean should implement a specific interface which inform the ejbStore() method if the dependent's state has changed.
For the most sensitive objects of your system, EJB provider should implement the both approach. Use inheritance to design as following :
public class MY_CMPBean implements javax.ejb.EntityBean {
public My_PK ejbCreate(...) {... return null; }
public void ejbPostCreate(...){ // do nothing. Required }
public void ejbActivate(){// not implmented}
public void ejbPassivate(){// not implmented}
public void ejbLoad(){ // not implmented}
public void ejbStore(){ // not implmented}
public void ejbRemove(){ // not implmented}
}
public class MY_BMPBean extends MY_CMPBean {
public My_PK ejbCreate(...) {//DAO , lazy load strategy...
return pk; }
public void ejbPostCreate(...){ //DAO... }
public void ejbActivate(){//DAO , lazy load strategy...}
public void ejbPassivate(){//DAO , Dirty Marker strategy...}
public void ejbLoad(){{//DAO , lazy load strategy...}
public void ejbStore(){//DAO , Dirty Marker strategy...}
public void ejbRemove(){ // DAO}
}

The point is that SCEA II requires you to make all the suggestion and to bring all the solution at the design step.
You should'nt design something that turns out to be slow at the production stage.
You should instead discover these issues at the prototype stage...
Regards,
herve attia
PS : sorry to have been too long....

[Luiz Reginaldo Curado]

And how about use only a Stateless Session to acess a DAO, in place of CMP Entitys? Do you know is a good idea?

[Jesse Jesse]

Hi Luiz

They are my thoughts exactly and this is how I was working my design. The only worry I have with this approach is maybe it is something Sun this not want to see.

Jesse

[Parag Bharambe]

Luiz/Jesse,

Let me share my thought on DAO.

Around 70-80% of the customer/user will use the site for searching the flights. So I think Fast Lane reader will be ideal for searching the flights (read only data). As per blueprint, they are recommending accessing DAO directly from client/web tier. I am not too certain of directly accessing DAO from client tier. In the current scenario, even for search, I will use Stateless session bean � to DAO call. I do not see any reason for using entity bean for search. What do you suggest?

For creating/reserving seat, IMO it is good to use BMP (using DAO). By doing this we can utilize the infrastructure provided by Application server such as transaction management/data sharing. It is also advisable to use DAO since it is not a good idea to model entity bean for each of the domain classes (Segment/Flight/Equipment)



Any thought?

[Karimulla Shaik]

Originally posted by Parag Bh:
Luiz/Jesse,

Let me share my thought on DAO.

Around 70-80% of the customer/user will use the site for searching the flights. So I think Fast Lane reader will be ideal for searching the flights (read only data). As per blueprint, they are recommending accessing DAO directly from client/web tier. I am not too certain of directly accessing DAO from client tier. In the current scenario, even for search, I will use Stateless session bean � to DAO call. I do not see any reason for using entity bean for search. What do you suggest?

For creating/reserving seat, IMO it is good to use BMP (using DAO). By doing this we can utilize the infrastructure provided by Application server such as transaction management/data sharing. It is also advisable to use DAO since it is not a good idea to model entity bean for each of the domain classes (Segment/Flight/Equipment)



Any thought?

[Shihchen Chiang]

Suppose we can use EJB 3.0 (I think Hibernate is not welcomed by Sun) in this assignment. Will you still choose to use BMP or SessionBean with DAO?

Are we allowed to use EJB 3.0?

[Leonardo Maranh�o]

Didi someone pass the exam using hibernate?