• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
Bartenders:
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

BMP, DAO and composite entity

 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi

I am doing part II and III now. Currently having some doubts on how to present the entity bean and DAO in my sequence diagram.

I have decided to use BMP + DAO + VO, after reading some of the earlier threads. Problem is

a) I am not sure whether I should show the entity bean (BMP) inside my sequence diagram. Should i just show DAO classes without entity bean to make it technology independent ?

b) And having 1 BMP for each entity is not coarse-grained, so i am thinking of using composite entity to make it more coarse-grained and reduce number of network calls. If i were to show BMP in seq diagram, then should I show the interaction of the composite BMP (eg. CustomerBMP interacting with CustomerDAO, CreditCardDAO and AddressDAO?)

c) if i dont show entity bean (BMP) in my seq diagram, i also should not be showing it in my class diagram, that means component diagram is the only place i should show my entity beans ?

Any advice is much appreciated !!

Thanks & rgds
Mandy
 
Ranch Hand
Posts: 181
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I am still waiting for my part II and III results.

But IMO if you are using BMP with DAOs you should include all components in your diagrams.
 
Ranch Hand
Posts: 153
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
why would you have an entity bean for a customer if the customer's records are not going to be shared by hundreds of users ?
 
Ranch Hand
Posts: 127
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I also wonder the answer. Should customer be an entity bean??
 
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If Customer represents a business entity we need to use the entity bean according to the specs, but the decision depends on how you architecting..

My understanding of sharing the entity beans is, multiple requests share the entity bean instance but not the particular entity inside.
 
Cleuton Sampaio
Ranch Hand
Posts: 181
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Again, I am not felling confortable about giving my opinions because I do not have my results yet, but...

If you use Entity beans, then Customer should be one of them, sure.

The problem with entity beans is not sharing but the heavy load they impose on the system.

In the literature we can see that the STATEFUL Session Bean is the heaviest and the Entity is heavier that Stateless Session beans.

When you have up to 600 concurrent users and only one application server, you cannot scale horizontally, then the performance of the application may be affected.
 
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Let's listen for a second to Ajith at https://coderanch.com/t/151535/java-Architect-SCEA/certification/Number-Entity-Beans

Entity beans are created only when a client requests it. The app server will not automatically instantiate 10000 entity beans on startup. The number of entity beans living in memory depends on server resources and to a certain extent the ejb container implementation. Using instance pooling and swapping the container will be able to use fewer instances to represent a large number of underlying data records. That is the beauty of EJB technology.



Regards,
Dan
 
suekar meredilko
Ranch Hand
Posts: 153
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I dont think we are saying that container automatically instantiates 10000 or whatever entity beans. No thats not the point.

Customer Entity does not have transactional or sharing requirements amongst many users...Yeah sure it is an entity but it does not qualify being an entity bean. I would create an entity bean for those which require transaction mgmt and sharing across many users. Its bad practice to just map entities identified to entity beans so as to say.

I would rather design entity beans for Segment, Seats, Flights etc using a composite design because they will be shared across many users and transactional, atomicity, isolation levels all apply for this data to keep its integrity.

again my 2c of opinion.
 
Ranch Hand
Posts: 259
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It may be modelled as a coarse grained entity bean (BMP) for the following reasons.

It may be reused by another system incase it is rewritten in Java/J2EE (Let us be optimistic that your current implementation will impress).

Simplifying transaction handling as both BMP and CMP entity beans use CMT.
[ September 13, 2006: Message edited by: karthi keyan ]
 
Creativity is allowing yourself to make mistakes; art is knowing which ones to keep. Keep this tiny ad:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
    Bookmark Topic Watch Topic
  • New Topic