BMP, DAO and composite entity

[Mandy Tan]

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

[Cleuton Sampaio]

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.

[suekar meredilko]

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 ?

[Murat Balkan]

I also wonder the answer. Should customer be an entity bean??

[Vidyasagar Guduru]

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]

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.

[Dan Drillich]

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]

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.

[karthikeyan Chockalingam]

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 ]