Good points. I don't want to throw out OO modeling either since that's what I
do for a living, but maybe we need an EJB extension.
Anyway, one thing that would help is remote references that were specified as
being persistent. Then entity bean components could hold references to other
entity beans as part of the persistent state. Obviously this would require
non-OODB EJB containers to do more work, but it would provide a simpler model
for the rest of us.
Richard
BTW - I know Ricard already has smart proxies but i'm talking about supporting
it in the EJB specification ... I don't care how its manifested.
Chris Raber wrote:
> Richard,
>
> I for one am not ready to through out the baby with the bath water yet.
> Hey we just now finally have a standard to oo modelling (UML), and
> folks are just starting to grock it.
>
> Loosely, my opinion is that one should use an oo model, and wrap it with
> coarse grained components that interact with the model in a transactional
> way. The coarse grained components can be SB's or EB's as appropriate.
>
> This highlights the area of modelling relationships. Relationships between
> EB's are by key or remote reference (the two are interchangeable, i.e. you
> can get one from the other). So how to handle the relationships Inside the
> coarse grained componts (i.e. within the object graph)? Well if you have
> and oodb, these can just be object references. If you are OR mapping then
> you are swizzling between object references and keys (but more transparently
> than EB's do).
>
> It would be nice if we had a single idiom for relationships in both cases
> (inter
> and intra component).
>
> -Chris.
>
> > -----Original Message-----
> > From: Richard Monson-Haefel [SMTP:[EMAIL PROTECTED]]
> > Sent: Friday, May 07, 1999 7:15 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Granularity of EJBObjects
> >
> > 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".
>
> ===========================================================================
> 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".
--
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".
