• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

decisions for deciding Composite entity and BO

 
Dhiren Joshi
Ranch Hand
Posts: 463
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a general question on design decisions which are used as pointers for deciding which domain model object can be structured as a POJO BO and a composite entity. Any body expert at designing and architecting EJB's please give there inputs .
Please refer to the Pet store Customer account for this Example.


Pet store customer Example

Thanks
Dhiren
 
Dhiren Joshi
Ranch Hand
Posts: 463
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Resurrecting this thread again.
Some one Please HELP
Thanks
Dhiren
 
Dhiren Joshi
Ranch Hand
Posts: 463
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Any one Please ....... ?
:roll:
Thanks
Dhiren
 
Ramon Gill
Ranch Hand
Posts: 344
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Dhiren,
If I was implementing the 'Pet Store Customer Account', I would set up entity beans for User, Customer, Account, Profile, ContactInfo, Address and CreditCard. These can also be referred to as BO's as they contain state and behaviour. I would use CMP and CMR and local interfaces for all of them, which I would indicate within the deployment descriptor. I would set up a session bean as a facade (possibly with remote interfaces) to access these entity beans to provide data to a client.

IMO the above describes a composite entity for a 'customer account'in EJB 2.0 style.

I would be interested in other peoples views.

Ray
 
Joseph Zhou
Ranch Hand
Posts: 129
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree. Session bean called by remote, so we deploy the presentation tier on a different node or have 2 different implementation of presentation tier. Also, I think the tiwer naming for application client is still a problem: The client tier does all the UI work for "presentation", and the presentation tier only have controller etc. left.
 
Ramon Gill
Ranch Hand
Posts: 344
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Joseph,
How about using a package for the application client? we can describe the package in notes (i.e. say it contains a controller, etc and its based on MVC, links to a controller on the web tier).

Ray
 
Dhiren Joshi
Ranch Hand
Posts: 463
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Dhiren,
If I was implementing the 'Pet Store Customer Account', I would set up entity beans for User, Customer, Account, Profile, ContactInfo, Address and CreditCard. These can also be referred to as BO's as they contain state and behaviour. I would use CMP and CMR and local interfaces for all of them, which I would indicate within the deployment descriptor. I would set up a session bean as a facade (possibly with remote interfaces) to access these entity beans to provide data to a client


Thanks Ramon for your replies.
Referring to the above.. If each is an entity bean .. Which component is defined as the composite entity. What defines an entry point for an entity bean to be designed as composite entity bean.
I can just say from looking at other implementations that customer or may be the account (I am still mixed up) would be the composite entity having the dependent entity beans. Is there some aggregate /composite relation which truly identifes which one of the bean plays the role of composite entity and the other beans play the role of POJO's or simple entity beans.

Thanks
Dhiren
 
Joseph Zhou
Ranch Hand
Posts: 129
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, Ray. Sun may not expect too much details in this part.
 
Annie Zhang
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My understanding for this is:

Both AccountEJB and CustomerEJB are composite entities,
ContactInfoEJB and CreditCardEJB are AccountEJB's dependent EJB, while ProfileEJB and AccountEJB are CustomerEJB's. This is just one type of composite entities to make use of the composite/aggregate relationship between the entities.

Another type of composite entities is that there is no "explicitly" composite/aggregate relationship between the entities. Rather, the parent or the composite entity is more or less as an entity facade in order to hide the dependent entity beans from the client. In this case, you can't find any "real" entity (from the database) related to the composite entity.

Maybe I am wrong, someone please corrects.

Thanks,
Annie
[ November 18, 2004: Message edited by: Annie Zhang ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic