Interoperability between omniORB2 and Java ORBs

The tests used to compile this report comes from the omniORB2 testsuite which is distributed as part of the snapshot releases.

Summary

Key

('Yes' is always good.)

ORB features (or missing bugs)

OMG

Supports the OMG IDL/Java mapping.

End

Has a proper endian-ness independent GIOP decoder. Tested by connecting to Alpha and SPARC-based omniORB servers. It may seem that this is a silly thing to bother testing, but two ORBs fail here (JacORB and JavaIDL are both big-endian).

Nam

Is able to use an arbitrary naming service found by resolve_initial_references("NameService")

Sdn

Correctly handles shutdown of connections to servers. Tested by waiting for an omniORB server to close the connection and seeing if the Java ORB re-opened it.

SRd

Correctly handles shutdown of connections to servers found by redirection. Tested by using the 'tombstone' example, waiting for both it and the server to close connections and then seeing if the Java ORB re-connected.

Note that the next test in the omniORB test suite, changing the destination object of the tombstone and killing the original destination, doesn't work. The client ORB should refer back to the tombstone, but none of the Java ORBs tested do so.

IDL compiler features

Pkg

Allows the Java package of the output to be set

scp

IDL compiler is capable of compiling scopetest.idl into compilable Java

seq

IDL compiler is capable of compiling seq1.idl (and everything it #includes) into compilable Java. These tests are rather weak, but only one IDL compiler passes them.

Comments on ORBs

Sun Java IDL 1.1

• Supports OMG Java/IDL mapping.
• Disagrees with old omniNames about IDL prefix for CosNaming. Can be fixed by using omniNames version of Naming.idl with an added #pragma JavaPackage "org.omg".
• Uses a bootstrap protocol for resolving initial references. This is not an OMG standard, and is not supported by omniORB2. It seems to be documented in the Interoperable Naming Service specification. Comes with a server for this which can be made to point to an arbitrary server (though this isn't documented).
• Seems not to like omniORB's connection-dropping habits. I could have sworn this version used to work, though.

• IDL bugs

  4106017

  Float expressions aren't handled properly

  4049820

  Nested scopes are handled badly

  And many, many more. The IDL compiler is close to useless.

• Apparently only does big-endian GIOP. What are Sun on?

Visigenic Visibroker for Java 3.0

• Supports OMG Java/IDL mapping.
• CosNaming not supplied as standard, but Naming.idl works fine.
• No obvious way to add the NameService to the initial references.
• Uses its own firewall by default if running as an applet. Use <PARAM name=ORBdisableLocator value=true> to make applets connect directly. The documentation says it should attempt a direct connection first, but it seems not to.

Visigenic Visibroker for Java 3.1

• See above.
• Apparently now gets firewalling (or lack thereof) right.
• The only ORB to handle dropped forwarded connections properly, but it still screws up on redirected dropped forwarded connections.
• IDL compiler can't handle short '\ooo' and '\xhh'character constants.

Netscape Navigator 4.04 (Visigenic ORB)

• Works, but beware of applet security restrictions.

OrbixWeb 2.0.1

• Does not support OMG Java/IDL mapping.

OrbixWeb 3.0

• Initial references can be set through the system properties.
• IDL compiler seems to core dump sometimes...
• ... but it handles seq1 and scopetest correctly.

JacORB 0.6c

• Does not support OMG Java/IDL mapping.
• Free (GPLed).
• IDL compiler doesn't understand #pragma at all.
• No way to set package of generated Java (interfaces without modules end up in package 'Global'.
• GIOP implementation incomplete (e.g. only big-endian)

OmniBroker 2.0

• Supports OMG IDL/Java mapping
• Free for non-commercial use (with sources).
• Have to build the C++ version to get the IDL compiler.
• Throws COMM_FAILURE if omniORB closes a connection on it.
• Naming service specified by -ORBnaming .
• seq1.idl breaks the IDL compiler:

  Assertion failed: false, file TypeCode.cpp, line 500
  Abort (core dumped)
  

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 scopetest.idl and seq1.idl, is also the only one capable of producing half-way portable stubs. As before, the test I used was pretty crude -- just seeing if the standard omniORB 'echo' example worked -- but even so, many things broke.

It's not always possible to see where the problem lies, but the VisiBroker stubs are definitely broken (they refer to a method (_orb) of org.omg.CORBA.portable.ObjectImpl which isn't specified by the standard).

Incidentally, source compatibility between the ORBs seems pretty good. (i.e. for once, I haven't noticed any problems).

Conclusions

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, slo@uk.research.att.com, for further information about this report.