The RMI-IIOP implementation from Sun dynamically loads classes from the
server in a fashion identical to that of RMI-JRMP. IMHO, any CORBA ORB
which claims RMI-IIOP functionality, but can't dynamically load stubs and
implementations, just simply is not implementing RMI semantics correctly.
The Sun reference should be used as a barometer.
ORBs compliant with CORBA 2.3 should be able to download stubs and run the
Sun RMI-IIOP example programs without change. I think this is critical
functionality for large scale deployment and interoperability of EJB servers
and EJB clients.
To understand how CORBA implements this functionality, please reference the
CORBA 2.3 spec. In particular, the pass by value specification,
http://www.omg.org/cgi-bin/doc?formal/99-10-10 should shed some light on how
this works.
As for security issues, I think these are well addressed in Java 2 and
dynamic class loading makes environment configuration much easier and
extensible than having to deploy clients with all the classes that a server
can (and might in the future) deploy.
> I thought that RMI-IIOP did *not* dynamically load classes from the
> server.... this type of thing is not standard CORBA. (Ie, you can't
> assume what "language" is on the other end... no guarantees that it
> is Java.)
>
> And IMO, dynamic class loading (ie, from the impl server) was one of
> the biggest drawbacks of RMI-JRMP. It opens up more avenues for
> security
> attacks, does not perform as well as local classes, and introduces a
> constant source of environment misconfiguration.
>
===========================================================================
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".
