Rickard--
This is something we've done on our project with some degree of success.
Another advantage to using serializable proxies (which you probably already
knew) is that they are extrmely fast to download. And yet another advantage is
being able to do remote synchronization with the bean data using an event
mechanism.
At any rate, we implemented this by creating stateless session "helper" beans
in front of the entity beans that wrapped the finder methods. Instead of
accessing the entity home, the client would use the stateless session beans to
get references to the "entities". However, instead of returning the EJB
references, the ss bean would instantiate and return the serializable proxies
that implemented what we called our "business interface" (your Account
interface in Solution 2) instead. Very lightweight and very fast.
One alternative that we considered was to subclass the generated HomeImpl
object to override the objects returned from the finder. We opted against that
for flexibility reasons and also because we didn't want to start hacking
generated code (frought with peril from a maintenance perspective).
Jeff
Rickard �berg wrote:
> Problem:
> EJBObject extends Remote, thus only making it possible for the server to
> hand out stubs to RMI-objects. It is desirable to have the option of
> sending a Serializable proxy implementing the bean interface instead, in
> order to implement fault-management, load balancing, lazy-caching etc.
> That would also make it possible to implement EJB over plain JRMP (which
> is not an option currently due to the new design of 1.2-RMI).
>
> Solution 1:
> Change so that EJBObject does not extend Remote. This would allow for
> the following:
> // Written by bean developer
> interface Account
> extends EJBObject
> {
> long getBalance();
> ...
> }
>
> // Generated by container. Contains Account+EJBObject methods
> interface AccountEJB
> extends Remote
> {
> // Use explicit context transfer, but hidden from user
> long getBalance(IdentityImpl clientid, TxImpl currentTx);
> ...
> // EJBObject methods
> void remove(IdentityImpl clientid, TxImpl currentTx);
> }
>
> The objects sent from the server to the client are proxies implementing
> Account (and thus also EJBObject) which delegates to stubs implementing
> AccountEJB. The design of the AccountEJB-interface is vendor-specific.
>
> Solution 2:
> Change so that EJBObject does not extend Remote, and do not mandate that
> the bean interface implements EJBObject. This would allow for the
> following:
> // Written by bean developer
> interface Account
> {
> long getBalance();
> ...
> }
>
> // Generated by container. Contains Account+EJBObject methods
> interface AccountEJB
> extends Remote
> {
> // Use explicit context transfer, but hidden from user
> long getBalance(IdentityImpl clientid, TxImpl currentTx);
> ...
> // EJBObject methods
> void remove(IdentityImpl clientid, TxImpl currentTx);
> }
>
> The objects sent from the server to the client are proxies implementing
> Account and EJBObject which delegates to stubs implementing AccountEJB.
> The design of the AccountEJB-interface is vendor-specific.
> Sideeffect: beans can implement Account, thus ensuring consistency
> between interface and impl.
>
> Comments? This is an incompatible change to the existing interfaces, but
> it has some very nice effects IMHO, including making it possible to
> implement EJB over plain JDK-RMI(/w JRMP).
>
> /Rickard
>
> --
> Rickard �berg
>
> Computer Science student@LiTH
> @home: +46 13 177937
> Email: [EMAIL PROTECTED]
> Homepage: http://www-und.ida.liu.se/~ricob684
>
> ===========================================================================
> 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".
--
Jeff Gallimore
Lead Technical Consultant
Perspective Technology Corporation
http://www.perspect.com
(703) 821-8800 x358
===========================================================================
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".
