I wanted to thank you all for your insight on the use of Entity beans. We've gathered
a lot of information from this list and it's been very useful.
In regards to my conclusions, we're going to approach our changes very carefully.
Everything works fine using stateful session beans with no use of entity beans.
The idea behind simply creating a simple thin entity bean layer for data access only
was to limit the complexity of migrating true business object behavior entirely to
entity beans. EJB Server vendors still use various vendor-specific methods in thier
entity beans that you can implement to achieve greater functionality (i.e. BEA's
isModified()). The problem is that we're trying to avoid locking into a specific
vendor. This is why we want to approach things carefully.
We're going to look at how we can do both approaches (full migration, or thin entity
data objects). Then we'll do some testing and go with the best solution.
It's interesting to note that I did get some feedback from technical resources at
Oracle and we talked about some of the things that Oracle did in their "Oracle
Business Components for Java". Their current model for their "Entity Objects" <-- not
EJB entity but "business entity" is based on Session EJBs.
Thanks again for all the insight, it's greatly appreciated.
John Abbey, AMS eCustomer
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
