On Mon, 8 Nov 1999 16:21:11 -0600, Eric R. Williams <[EMAIL PROTECTED]> wrote:
>5. Class incompatibility. The RMI-IIOP client application may have
>been compiled against a different version of the RMI interface or
>valuetype classes that are served up by the remote codebase. In
>this case, the classes won't work on the client.
>
For valuetypes, there are versioning semantics that handle the case
of a locally loaded class being at a different level from the level
that was used to transmit the valuetype data. For remote interfaces and
stubs, a locally loaded version with the same name will be used in
preference to downloading. This still requires semantic compatibility
between local and remote versions, but it does not require identical
matching.
>6. There will probably be vendors who will not support dynamic
>classloading. Oracle's JServer (in the database) comes to mind.
>Assuming you use one of these servers to connect to another server,
>you won't be able to use dynamic classloading.
>
This is a mandatory part of the RMI-IIOP spec. Any ORB vendor who does not
support valuetype and stub code downloading is not compliant with the
OMG Java to IDL mapping.
>> I don't want to create a religious debate. It seems that the "pure" CORBA
>> camp feels dynamic class marshalling is a very bad activity. Maybe it is not
>> possible for CORBA to support this behavior.
>
>CORBA is the point of view I come from. And, yes, it would be extremely
>difficult to do this with pure CORBA. How would a C++ server running
>on Solaris provide a COBOL implementation of a valuetype on an S390?
>Outside Java-land, you have system, language and compiler variations
>that make this problem intractible.
>
>
>> RMI has to resort to the aid of
>> an HTTP server (or shared file system) to support class marshalling. I would
>> think that CORBA (with its separate ORB) could support this behavior
>> securely and more efficiently than RMI.
>
>Interesting thought. But it appears that support for classloaing was
>tacked-on
>to the spec for Java, rather than designed to be tightly integrated with
>CORBA.
>They could have added support for iiop: codebases and enhanced the
>interface
>repository to serve up implementation files... but they didn't. They
>simply
>added a tagged profile to the IOR to refer to the codebase. If I had to
>take
>a wild guess at why... I'd say they realized that it was intractible as
>a general CORBA problem, but that they could implement a simple hack
>that
>would make it work for Java and would enable the retention of RMI-JRMP
>semantics in RMI-IIOP.
>
You are correct that the initial objective in providing CORBA support for
downloadable stubs was to emulate RMI-JRMP capabilities and semantics.
This is important, since without that we will not be able to establish
RMI-IIOP as a crediable alternative to RMI-JRMP. Despite this, one of our
biggest PR problems has been convincing people that RMI-IIOP does fully
support RMI-JRMP code downloading semantics for both value types and stubs
when Java is at both ends.
However, RMI-IIOP is different from RMI-JRMP in this area in the following
important respect. The RMI-JRMP programming model requires downloadable
code, as well as Java at both ends, but the RMI-IIOP programming model
requires neither of these. In RMI-JRMP, you use Java casts to obtain an
object reference of a different type from the type by which the reference
is currently known. In RMI-IIOP, you make "narrow" calls. The "narrow"
model does not require that the initially loaded stub be castable to all
possible implementation types. Therefore, the RMI-IIOP programming model
allows the construction of systems where all code is statically deployed,
as well as multi-language systems, in addition to systems that use
JRMP-style downloading. It also works over JRMP.
It is possible that at some future time a more general CORBA solution to
code downloading might be added. The inhibitor to this is the cross-
language mandate of CORBA. Fully integrated code downloading would require
CORBA to move in a more language-specific direction than is currently the
case. Some in the OMG would like to see closer integration between CORBA
and Java, while others resist any move that appears to depart from strict
language neutrality. So what is there today is a compromise that both
camps can live with. We would welcome user feedback on how it can be
improved.
Simon Nash
===========================================================================
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".
