Phillipe
> -----Original Message-----
> From: Fajeau, Philippe [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, August 19, 1999 6:19 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Entity beans vs session beans - OO paradigm.
>
> What are the implications of using entity beans (versus session beans) for
> the highest level objects and an O/R mapping tool for the subordonate
> objects? I have read a few times that it is good practice to provide
> clients
> access to the entity beans through session beans. I see that as the old
> MIS
> way of separating data and behavior and a direct violation of the OO
> approach where data and behavior are modeled in one object. And I am
> talking
> about real behavior not just a buch of get and set.
>
>
I disagree. Facade is a well established oo pattern. That is what we are
talkingabout when putting SBs in front of EBs. Exposing all the remote
behavior of EB's is dangerous from a performance perspective. Also there is
the use of views and various use cases which may require different facades.
To me the "old MIS" aspect of the discussion is more about whether EB's are
good for anything or not. I will respond to Ian's note on this separately,
but in short every EJB based system is not a legacy system wrapper, and the
component market place needs a model where components are behavior and
state.
> From what I am reading it almost look like to model a real object in EJB
> one
> needs two beans: an entity beans (data) and a session bean (behavior).
> Weird...
>
No, session beans are about a set of service exposed to the client. Entity
beans are wrapper around a chunk of domain objects (imho).
> Could it be the IBM (big MIS shop) influence that led to this framework...
>
> Philippe
>
> -----Original Message-----
> From: Hal Hildebrand (Work) [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, August 12, 1999 9:24 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Different beans/remote access
>
>
> > Hal,
> >
> > The model you describe looks OK, but then I am not sure that EJB brings
> a
> > lot to the table. Especially if the O/R mapping tool in not tightly
> > integrated with the EJB container. In this case, you do not get
> declarative
> > transactions. What about the integration of JTS bases distributed
> > transactions provided by the container and the O/R mapping tool own
> > transaction mechanism? Not sure about security... Looks almost like a
> > classical RMI or CORBA based architecture. Am I missing something
> (again)?
> >
> > Philippe
>
> Using the SessionSynchronization interface makes it trivial to tightly
> integrate the O-R tool into the container. This gives you all the
> declarative transaction capability of the container. If the O-R tool
> doesn't automatically generate this code, it's trivial to add to the bean.
> For example, it is really, really simple to do this using TopLink. Using
> BeanManaged transactions gives the control back to the O-R tool, if that's
> what you require.
>
> Security comes for free, and is no way changed by this scenario.
>
> As to the difference between the classical RMI/CORBA architecture, there
> are
> four main differrences:
>
> 1) You don't have to write the container
> 2) You don't have to implement your own declaritive transactions
> 3) You don't have to implement your own security.
> 4) You don't have to re-invent yet another component architecture
>
> Yes, this is similar to the classic architecture, but all the hard
> problems
> you'll have to solve over and over and over if you do this manually are
> done
> for you in EJB. Also, using this method, it is portable to ANY EJB
> container which uses JDBC.
>
> This is the whole point of a component architecture. It's not rocket
> science. It's just boiling water the same old way. However, now everyone
> boils water the same way, and doesn't have to re-invent combustion every
> time they do it, or move to a different vendor.
>
> Writing servers for this model is still a very hard problem to solve, and
> simply using CORBA/RMI does nothing for you except provide the remote
> communications mechanism. Security, transactions, etc are completely left
> as an excercise to the developer.
>
> > > 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".
===========================================================================
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".
