[omniORB] POA/BOA IOR compatibility

[Duncan Grisby]

On Friday 12 January, Peter Rapier wrote:

> The problem we had was that our omniOrb 2.6 server object's IOR did not work
> with a client based on BEA's M3.  It did string_to_object but using the
> object reference did not work. We wound up bootstrapping the object another
> way.
> The other things we are hearing I can not verify, but I do know there are
> some users (of our products) under the general belief that POA based orbs
> won't interoperate with our omniorb 2.6 server.  We do not need any of the
> POA enhancements. Our concern is interoperability.  I am investigating the
> IOR issue in light of the above.

omniORB 2.6's IORs are perfectly valid for all versions of the CORBA 2
specification, so any ORB which fails is buggy. Nothing has changed
between omniORB 2 and omniORB 3, except that the object key within the
IOR can now vary in length rather than always being 12 bytes long. To
clients, object keys are just an opaque sequence of bytes, so it is
irrelevant whether the server is based on the BOA or POA.

If your client ORB has difficulties with an omniORB IOR when using
string_to_object, but not when receiving it by some other means, the
ORB is very broken. The stringified form of an IOR is exactly the same
as the form which is transmitted in an operation parameter, just
written as hex digits rather than binary data.

I think it is a bit of a waste of effort to try to come up with
corbaloc based schemes without finding out exactly what M3 has a
problem with.

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --