>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.
The reason that I do this is to cut down on:
1) The number of remote objects the client knows about.
2) The number of remote calls the client must issue.
For instance, say I have ten entity beans on my server. For a particular
application (say, an
analyst review program) I write a session bean to funnel all interactions
with the middle tier.
That way, the client only knows about the interface; I'm free to fiddle with
the underlying
entity beans. If I have another sort of client that would like to interact
with my domain objects
(say an image scanning device).
The _main_ reason, though, is to cut down on remote calls (at least this is
_my_ prime motivator).
Could you do the same thing with an enclosing entity bean? Sure. I like
session beans for this
use, though, because they're per-client (i.e. not shared among multiple
clients), so you can stash
conversational state info in them if you need to.
>
>>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...
>
>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".
===========================================================================
Tom Valesky -- [EMAIL PROTECTED]
http://www.patriot.net/users/tvalesky
===========================================================================
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".
