I mostly agree with Richard and the general direction this
thread has taken.
There does seem to be an issue, however, with access to the
data managed by the components, defined by the object model,
which we seem to be tying to the modeling capability.
I believe object modeling, in all its varieties, is proving
fully applicable to the design and development of objects to
be realized by EJB.
On this list, I've heard tradeoffs, designs, and alternatives
for various domains debated -- all in fairly standard object
modeling contexts (maybe with some exception of transaction
granularities).
I am more interested in the interface between an EJB tier
and its client.
I wonder whether the EJB tier's object model will affect the
delivery of information to clients.
I'm a bit surprised that Chris from GemStone didn't mention
queries over EJB objects; maybe in our various prototyping
and development efforts we have not as yet reached the
stage where such proven access paradigms are needed?
My colleagues and I are formulating a position on using
database view technology in this context.
We're intrigued by the possibility that this will enable
connections between EJB tiers, possibly across organizations.
I look forward to an engaging discussion of this here.
Eric Hughes
Richard Monson-Haefel wrote:
>
> 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".
--
Eric Hughes The MITRE Corporation [EMAIL PROTECTED] 781-271-7486
===========================================================================
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".
