Rickard,
You've definately raised some interesting ideas. If I had to choose, however, I
would not want to implement a serious EJB server over JRMP, since IIOP affords a
much more robust paradigm for EJB server development. For reasons such as
context propogation, load-balancing, etc, many EJB server vendors are choosing
to build ground-up from an ORB, and support RMI by using RMI-IIOP.
If you support RMI-IIOP with a professional ORB that supports CORBA
objects-by-value and the Java-to-IDL mapping (only JavaIDL at the moment) and
also supports CORBA request interceptors (JavaIDL does not support this I
believe), then you can perform load-balancing and transparent fail-over in the
request interceptors. Plus you get context propogation from IIOP, so all your
problems are solved.
If you want to hack around RMI-JRMP, you can definately do that (as you
propose).. another possibility is if you perform the load-balancing and
transparent fail-over by modifying RMI's stubs and skeletons, which you can
create by using "rmic -keepgenerated". You could modify the stubs and skeletons
to transparently receive contexts and perform load-balancing and transparent
fail-over. As far as I know, the only other vendor doing something like this is
WebLogic, who has their own re-implementation of Java RMI. In general, I firmly
believe that it should not be the responsibility of the container vendor to do
this, but unfortunately you may have to wait awhile before ORB technology
catches up, and RMI-IIOP GAs.
Hope that helps,
-Ed
--
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
===========================================================================
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".
