[omniORB] RMI over IIOP

[Duncan Grisby]

On Thursday 28 December, Daniel Popowich wrote:

> I want to use omniORB to communicate with remote services written in
> java.  Unfortunately, I work in a java shop where most developers do
> not want to have to know IDL.  At first glance, RMI over IIOP seems to
> be the answer: java-only developers can still work with java and those
> that want/need to develop in C++ or python can run 'rmic -iiop -idl'
> to generate idl from the java remote interfaces.  When I use omniidl
> on the the output from rmic I get the following error:

I think that this sort of approach is, in general, a bad idea. It's
normally the case that the Java interfaces in question are badly
arranged for distributed use, unless they were specifically designed
for use with RMI. It's usually better to manually write a sensible
abstraction in IDL, and a small amount of glue code to adapt the IDL
to the existing Java. That said, it would be nice if RMI-IIOP could be
used for simple situations.

>     % rmic -d .. -idl  javatest.FooServer
>     % omniidl -bpython -I /usr/java/jdk1.3/lib Foo.idl
>     /usr/java/jdk1.3/lib/orb.idl:13: omniORBpy does not support valuetype

You may be able to avoid the specific problem you are having. orb.idl
is meant to contain ORB-specific definitions for built-in CORBA
things, so if Java is doing the right thing (which it quite possibly
is not), you should be able to put omniORB's idl directory first on
your include search path, so you get omniORB's orb.idl (which is
actually empty) rather than Java's.

Unfortunately, you'll probably find that Foo.idl also contains
valuetypes, so it's likely that this approach will only move the
problem somewhere else.

> Is there any time frame for support of valuetype?  What other gotchas
> are there?  Are there other solutions?

valuetype is on the list of things to do, but we don't have any
definite time frame for it.

Cheers,

Duncan.

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