Simon Nash wrote:
>
> 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.
First, thanks for such a detailed response. It is nice to get this kind
of information on this list.
As with serialization, there are some types of valuetype and interface
changes that will break marshalling compatibility (eg, changing the
inheritance hierarchy)... and some that will break semantic
compatibility
(eg, renaming an attribute).
Of course, you can encounter these types of problems whether you have
dynamically downloaded code or not. But at least if you
> >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.
That is unfortunate. There are plenty of situations where dynamic
classloading behavior isn't desirable: burned-in applications with
low RAM constraints, highly secure apps that don't want to risk
"foreign code", Java-to-executable compiled apps, etc.. And I would
guess that dynamic classloading won't be part of many of the low-end
Java2 Micro Edition reference profiles.
Also, I did not find any part of the specification that described
the interpretation of the TAG_JAVA_CODEBASE profile. I assume that
the codebase is an URL... but what types of URL schemes must a
conforming implementation support? http? https? http or https
with proxy and/or socks support? ftp? file? Is there documentation
available for this?
> 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.
Interesting point. I hadn't thought that convincing developers to
move from RMI-JRMP was such a big issue.
> 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.
Of course, it is possible that in a couple of years, other CORBA
language
bindings will be [mostly] irrelevant... as Java captures the lion's
share
of the distributed systems development market. That seems to be the
trend,
and it doesn't look like it will reverse any time soon. And at that
point,
Java will go its own way... and the OMG/CORBA will wind up like OSF/DCE.
(I'm not being cynical. I'm just describing what I see.) Maybe not,
but
it will certinaly give Sun and friends more weight in moving the OMG in
a Java-centric direction.
-eric
===========================================================================
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".
