All valid points, but I think the issues can be mitigated to a degree by
having entity beans that have relatively coarse granularity (i.e. entity
bean != a data base row, but a graph of underlying domain objects ).
-Chris.
> -----Original Message-----
> From: Hal Hildebrand (Work) [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, August 11, 1999 8:29 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Different beans/remote access
>
> > The problem is that we end up with:
> >
> > client --> statefull session bean --> stateless session bean -->
> entitity
> > beans --> database
> >
> > Each arrow is a remote invokation, with the overhead of network latency
> and
> > the marshaling and unmarshaling of data.
> >
> > May be I am missing something, but I can not see how a large system can
> be
> > implemented like that. If your application server provides optimzation
> > whereby co-located beans end up calling each other using local method
> calls,
> > then at least you solve the performance hit. YOu still have to deal with
> the
> > overhead of generating all these extra java files for each bean, even
> the
> > dummiest and most passive one.
> >
> > Can anyboddy provide some useful insight on how to deal with this?
>
> client --> stateful session bean -> database
>
> Forget the entity beans. Use an O-R mapping tool in the stateful session
> bean for your domain entities.
>
> You're also forgetting in your budget analysis, the remote communication
> substructure that is used for each bean. There's some ways to amortorize
> this cost, but none of the methods are as fast, nor as lightweight as
> simply
> using an O-R mapping tool to manipulate the "entities" in the database
> while
> in a stateful session bean.
>
> You can't beat the low overhead of this method, as doing nothing is
> certainly always faster than doing something. Caching, pooling, and all
> that fanciful stuff still costs. It's also complicated and ugly code
> that
> sucks up resources. AND the entity implementation is undoubtedly using
> the
> *same* or at least similar O-R mapping mechanism for the container managed
> persistence.
>
> You'd have to have a pretty darn good reason to give *every* one your
> entities in the domain a communication/security/transactional identity.
> "Because they are there and easy" is simply not a good enough reason,
> imho.
> This is poor engineering - just my opinion.
>
> Good reasons for entity beans include federation of databases, distributed
> locations of the various application databases, wrapping of legacy
> systems,
> etc.
>
> ==========================================================================
> =
> 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".
