[omniORB] RMI over IIOP

[Daniel Popowich]

Duncan Grisby writes:
 > 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.

I wouldn't say it's bad.  The interfaces I'm compiling are explicitly
for RMI use, so while not ideal, using RMI over IIOP at least gives
some tool to allow non java code to communicate with servers written
in java.  In particular, I was hoping to be able to use omniORBpy to
offer simple scripting tools to communicate with some servers; any
weirdnesses in the Java->IDL->python mapping I'd hide on the python
side with nice class definitions.

 > >     % 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.

Foo.idl references ::CORBA::WStringValue which is defined in Java's
orb.idl as a valuetype:

    // IDL not generated by rmic, do not edit
    // These are all in IDL module CORBA
    // The Java classes are in the package org.omg.CORBA
    // See ValueType Semantics:Standard Value Box Definitions (5.3) in CORBA 2.3 spec

    #ifndef __org_omg_CORBA__
    #define __org_omg_CORBA__

    #pragma prefix "omg.org"

    module CORBA{

	valuetype StringValue string;
	valuetype WStringValue wstring;

    };

    #include "ir.idl"

    #pragma prefix ""

    #endif

omniORB doesn't support wstring either, if I'm not mistaken.

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

Oh well.  Back to the drawing board.

Thanks,

Daniel