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