Best techniques for this senario

[Steven Lau]

For a business operation, a complex set of data is returned. The data is a subset of the data associated with an Entity bean. Much of the data needs to be presented back to the client through a JavaServer Page. The technic I was suggested are :
1. Create a JavaBean Wrapper access bean to access the Entity EJB.
2. Create a Value Object (JavaBean) specific to request, copying data from the EJB on construction.
3. Create a Value Object (JavaBean) which represents complete persistent object, copying data from the EJB on construction.
4. Create a copy Helper access bean to access the Entity EJB.
5. Hand off a reference to the Entity bean directly to the JSP.
Can any guru help me to choose the the BEST technique to deliver the data back to the JSP?

[Kyle Brown]

Originally posted by Roland2k1:
For a business operation, a complex set of data is returned. The data is a subset of the data associated with an Entity bean. Much of the data needs to be presented back to the client through a JavaServer Page. The technic I was suggested are :
1. Create a JavaBean Wrapper access bean to access the Entity EJB.
2. Create a Value Object (JavaBean) specific to request, copying data from the EJB on construction.
3. Create a Value Object (JavaBean) which represents complete persistent object, copying data from the EJB on construction.
4. Create a copy Helper access bean to access the Entity EJB.
5. Hand off a reference to the Entity bean directly to the JSP.
Can any guru help me to choose the the BEST technique to deliver the data back to the JSP?

IMHO, 1 and 5 are right out. Don't even think about that -- the problem there is that you are now having to move transaction management to the client side -- a BAAAAAD idea. Since the person suggested (4) I can surmise that you are working in VAJ -- since that's the only technology that gives you copy helpers.
Copy helper's are OK -- there not a bad solution, but be aware that they don't automatically map complex structures -- you have to do that yourself, and that can prove challenging.
For my money, I'd go with (2), with (3) being a fallback position if there are a lot of very similar requests. It's cheapest at runtime, fastest, and probably easiest to write and debug.
Kyle

[Steven Lau]

Dear Kyle,
Thank you so much for your kind help and prompt advises for all of my "best practices" questions.
I am an enthusiastic advocator of your great book.
However, for this question, using a JavaBean Wrapper generated in VAJ as an EJB AccessBean that encapsulates the business data for JSP access seems a common practice promoted by IBM.
I am still a bit confused about the Choice 1. Can you provide some detailed explanation about why the trasaction management has to moved to client side for this situation?
Thank you again

Roland

[Kirt Henrie]

A regular JavaBean does not (without extra transaction code) support transactions, in other words if you call multiple setters on your entity bean (setFirstName(..), setLastName(..), setAddress(..)) and there is a database failure, all data that was modified prior to the failure will not be rolled back.
If you however, call only one method on the entity bean (setDetail(..)) and pass it a value object containing all of your attributes and your entity bean internally updates all of the attributes individually, the transaction can be set up so that the update only succeeds if all attributes are successfully updated.
The transaction will begin upon the single method invocation and propagate through the individual mutator calls (setters) and succeed unless there is a failure that causes a rollback
(by throwing an EJBException or calling setRollbackOnly()). A failure will cause a proper rollback of all attributes.
Hope this helps,
KJ