Interoperability between omniORB2 and Java ORBs
This report reflects the current (March 1998) state of the Java ORB world. Things will (hopefully) improve in the future.
The tests used to compile this report comes from the omniORB2 testsuite which is distributed as part of the snapshot releases.
('Yes' is always good.)
ORB features (or missing bugs)
IDL compiler features
Comments on ORBs
Compatibility between OMG-supporting Java ORBs
An interesting aspect of the Java language mapping is that it defines the interface between the IDL-compiler-generated stubs and the ORB runtime, which should mean that Java runtimes with built-in ORBs can run applications built with other ORBs. Well, that's the theory, anyway. Does it work?
It seems that the OrbixWeb IDL compiler, in addition to being the only one able to compile
It's not always possible to see where the problem lies, but the VisiBroker stubs are definitely broken (they refer to a method (
Incidentally, source compatibility between the ORBs seems pretty good. (i.e. for once, I haven't noticed any problems).
It looks like the available Java ORBs are only just on the edge of being of acceptable quality. Java IDL is clearly useless until it can talk to little-endian GIOP implementations, and OmniBroker's inability to handle connection shutdown properly reduces its usefulness with omniORB somewhat (though since the source is available, it could be fixed). OrbixWeb has problems with redirected connections shutting down, which I believe causes problems with SPIRIT. I'm not sure if VisiBroker deals with this well enough, but it's at least better at it than the rest.
It would seem that at present, the best strategy is the rather odd one of using OrbixWeb's IDL compiler and VisiBroker's ORB runtime. Doing these kinds of tests does lead me to think that omniORB for Java isn't quite such a silly idea.
Interaction between CORBA and Java applet security
This is rather nasty, as the default Java applet security policy is to only allow network connections back to the host from which an applet was loaded (and, indeed, only if the same name is used for it in both cases [more detail]). This, of course, interacts rather badly with the CORBA philosophy of not really caring which machine an object actually resides on.
Most Java ORB vendors seem to deal with this by having a proxy running on the same machine as the Web server supplying the applets, and making all connections through that. I suspect that this may open lots of nice reverse security risks, in that (for instance) Visigenic's Gatekeeper doesn't seem to be able to prevent itself being used to access arbitrary objects unless its internal and external ports are on isolated networks.
Sun appear to intend to make the Java security model a little more flexible and fine-grained, which might improve things. A neat feature would be to provide a protocol for a JVM to ask a remote host 'are you willing to accept a connection from this applet?'. Hmm...
Please contact Sai Lai Lo, [email protected], for further information about this report.
For comments, suggestions and further information please contact us.
Copyright © 1999 AT&T Laboratories Cambridge, 24a Trumpington Street, Cambridge, England. CB2 1QA