I have been thinking on and off about these types of problems for over a year and have 
listened with great interest to threads like this one.
The following is simply my thoughts on the mater and do not represent a solution.

It seems to me that OO design with respect to associations has an impedance mismatch 
with EJB.   Attempts to model associations are especially
difficult when those associations have a cardinality with multiplicity (one-to-many or 
many-to-many).  This is do to the differences between an
object graph and a component graph (a concept I wrote about a few months ago).  
Because references to other beans are remote references,
navigating the component graph has serious penalties that are not experienced with 
domains models that are manifested in traditional OO
systems.  Interestingly enough, this problem is not specific to EJB, but is also 
experienced in other distributed object systems like CORBA.

Is it possible that much of what we know today about OO domain modeling needs to 
change to fit the new server-side component model?   I'm
beginning to believe that server-side components require a slightly different design 
methodology than OO systems.  I certainly don't believe we
need to throw out everything we have learned about OO analysis, design and 
development, but I think design and development needs to be modified
for server-side components.  An OO design just doesn't map to a server-side component 
model.
--
Richard Monson-Haefel
Senior Consultant
BORN Information Services

Author of Enterprise JavaBeans
Published by O'Reilly & Associates
(Available June 1999)

===========================================================================
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".

Reply via email to