Rickard,
The stubs that the RMI system hands out are Serializable and, by default,
implement the client side of a simple RPC. The easiest way to create the
stubs is to use rmic. That doesn't mean that you always have to use rmic or
that you are restricted to using the default implementation. You can easily
create more sophisticated stubs that implement your desired
fault-management, load balancing, lazy-caching etc. while still taking
advantage of the underlying services that allow you to hide (and
transparently download) your own proxies. And do the entire thing in a
compatible fashion.
IMHO, the most important feature of RMI is that it allows you to think in
terms of "remote interfaces" instead of "remote interfaces + proxies". The
'Remote' interface should be viewed as a simple marker that signals the VM
that there are attached stubs (or custom proxies) that it should manage for
you through the RMI system.
Clearly, if you are not using RMI (e.g. in a CORBA environment where class
downloading and on-the-fly binding is not available), the above advantage is
not realizable and RMI is really a moot point.
If the spec is relaxed to allow non-Remote EJBObjects, you will have to
manually handle and distribute the proxies, a quite error-prone process.
>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).
I don't see your point. If you are referring to the RMI system not defining
a standard transaction context and/or client identity passing mechanism, I
agree. Otherwise, there is at least one existing EJB server implemented on
top of the standard 1.2 RMI (w/ JRMP), that subclasses the standard
RemoteStubs, implements JNDI Referenceable and provides re-connect features
in the case of a server failure. And load-balancing has been demonstrated in
the labs :-)
Imre Kifor
Valto Systems
-----Original Message-----
From: Rickard �berg <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Monday, March 08, 1999 2:36 AM
Subject: EJBObject thoughts
>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".
>
===========================================================================
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".
