Chris Raber <[EMAIL PROTECTED]> wrote:
>
>EJB encourages one to expose components as fine grained remotable objects,
>by making domain objects (enity beans) directly remote.
I understand. My EJB training encouraged
remoting only session beans, which shield the network from entity interaction.
There's nothing in the EJB spec claiming that all EJBeans should be
remoted. But you're right, remoting entities does seem to be the default
treatment from most EJB server vendors. :(
>Any reasonable scale projects that have been successful with CORBA, have
>treated remote objects as with a coarse grained "service" orientation.
Aka, session beans.
>Our flagship GemStone/Smalltalk server provides a totally transparent
>client/server partitioning capability. One's object model can be
transparently
>replicated to the client, and changes to objects are flushed to the server
>automatically.
Beautiful! IMHO that's the best load-balancing mechanism yet, and
probably superior to standard EJB servers. I see much value in client-side
session beans, but migrating entities does seem risky: entities contain
private corporate data, and optimal entity deployment requires locality
especially for (JDBC) connection pooling and perhaps other scalability issues.
But yes, let's consider pushing sessions to the client.
===========================================================================
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".
