Hal,
Now, you have go me excited here! We are planning to use ObjectSpace Voyager
Application server and may be TopLink for the O/R mapping. What is this
SessionSynchronization interface? After speaking to people to TopLink, it
was not obvious to me that having container declared transactions was that
trivial?
Thanks,
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".
