composite entity

[H. Hafer]

Hi folks,

anyone ever considered to utilize "Composite Entity" to aggregate the handful business object the analyst has dropped into a coarse-grained EJB and thus making the complete system a, say one or two entity bean system?
If not, why not?

Any thoughts appreciated,
Harbo

[Parag Doshi]

Originally posted by H. Hafer:
Hi folks,

anyone ever considered to utilize "Composite Entity" to aggregate the handful business object the analyst has dropped into a coarse-grained EJB and thus making the complete system a, say one or two entity bean system?
If not, why not?

Any thoughts appreciated,
Harbo

Harbo,
There are atleast a couple of instances in the assignment where I think composite entity is a good fit. But, I havent, yet, reached a decision whether I want to go with BMP or CMP for persistence mechanism. If I go with CMP, then I would rather lean towards making CMP-CMR relationship btw the entities (local interface etc) and wouldn't need composite entity relationship.
And if I go with BMP, then I would go with something similar to composite entity. AFAIK, composite entity was born out of the limitations of EJB 1.0-1.1, but with EJB 2.0 and the whole local entity thing, I am divided btw CMP and BMP choice.

I dont know if this answers your question or not..its just me thinking out aloud

Parag

[H. Hafer]

Parag,

thanks for the input, it's quite worthful because it opened my eyes for an aspect I was unaware of until now.

Using BMP "requires" something like DAO - and yes, one can utilize them to apply some functionality of composite entity. I was unaware of the fact that the chosen persistence mechanism could play a role there: My understanding of composite entity was to reduce remote method calls between client and buiness tier because of the bigger "chunks" of data they share.

I didn't pay attention (at least not enough) to the consequences of using BMP or CMP -- I simply ventured CMP because of laziness and put it to a rest. I'm curious, are things like CMP-CMR relations really in scope of the assignment? I thought that would be details one may happiliy ignore.

thanks again,
Harbo

[Ramon Gill]

Hi Harbo & Parag,
Personally, I wouldn't use composite entities at all now that EJB 2.0 is available. Whether I went for BMP or CMP, I would use 'local' for all entity beans. I would access these through session beans acting as facades. I would pass data back to the client (web tier) using 'data transfer objects'.

For the exam, I personally don't think you need to mention about BMP or CMP, as it won't make a difference to the diagrams. Can anyone who's passed the exam comment on this?

Ray

[Ramon Gill]

Hi,
I've just read Peter Lee's thread where he passed with 94%.
He said he didn't put anything in the class and sequence diagrams that related to J2EE technology. This seems to me that we don't need to choose between BMP or CMP.

Ray

[D. Rose]

I think you would need to describe your design not in model but accompanying architecture document, wouldn't you?Or is it in part III?

[Parag Doshi]

Originally posted by Ramon Gill:
Hi Harbo & Parag,
Personally, I wouldn't use composite entities at all now that EJB 2.0 is available. Whether I went for BMP or CMP, I would use 'local' for all entity beans. I would access these through session beans acting as facades. I would pass data back to the client (web tier) using 'data transfer objects'.

For the exam, I personally don't think you need to mention about BMP or CMP, as it won't make a difference to the diagrams. Can anyone who's passed the exam comment on this?

Ray

Ray,
What you say makes sense about not using the composite entity pattern with the EJB 2.0 and local interfaces etc. I think the choice of BMP-CMP would affect the diagrams, right? For instance, if I were to save the itinerary (paid or unpaid, doesnt matter), then I would have to show the communication from my session facade to either a DAO(in case of BMP) or Itinerary (EJB) in case of CMP.
Am I thinking in the right direction or trying to put too much implementation details in the seq diagram?

I personally feel that we need to show the BMP or CMP choice in seq,component diagrams (by showing the respective DAOs) and also back it up in the accompanied document. This will help if they ask questions related to persistence in Part III. That way you can safely quote classes from your diagram to support your architecture and explain it further.

For me, the choice of BMP or CMP is the last hurdle before submission of the architecture, so it would help to know whether folks (who passed) or those who are planning to submit have gone into this level of details or not?

Thanks,
Parag

[H. Hafer]

Parag,
I completely agree with you that one should make his choice of persistence mechanism clearly visible in his diagrams. Well, showing DAOs is a very good indicator one utilizes BMP, I'm uncertain on *how* to show CMP on the other hand.

Whether to choose CMP or BMP: I really, really believe that that doesn't matter, anyway, so you may choose whatever you prefer.
However, I didn't submit yet, so beware!

HTH,
Harbo

[Ramon Gill]

Hi Harbo & Parag,
Having read your latest comments, I agree its a good idea to mention BMP or CMP. When you think about it, the document you produce should show you have a good understanding of J2EE. It would be helpful if some people who have passed could give some advice though.

For the diagrams, I would always show the session facade linking to an entity bean, regardless of BMP or CMP (same diagrams for both). To distinguish between BMP and CMP, you could show an additional link to a DAO for BMP, or just mention the persistance model(BMP or CMP) in notes or a description.

Ray

[Ramon Gill]

Hi D Rose,
the excellant thread from Harish touches on what is required for part III. There are 4 questions based on system level requirements. This might mean questions asking why you chose CMP over BMP, etc.

Ray