4 Replies Latest reply: Mar 25, 2010 2:49 PM by 843793 RSS

    obtaining an IOR for RMI-IIOP

      Hi -

      I'm working to modify a C program (gnuplot) so that it can remotely call functions in Java.

      My current plan is to use RMI-IIOP on the Java side. I'd like to create a class that implements java.rmi.Remote via some local implementation class, instantiate it, then obtain a stringified IOR for that object and pass it to gnuplot, which can then use the IOR to call remote methods.

      Also, I'm planning to use CORBA DII on the client side, since I want a generic program where the remote method names can be set by user options at run time.

      Does this make sense? I'm working with this tutorial code:


      and am stuck on obtaining an IOR in the server code.

      Any help would be appreciated...
        • 1. Re: obtaining an IOR for RMI-IIOP
          You're on the right track here apart from the stringified IOR - do you have to use that? If you really need to, see here, although it appears to be a work-in-progress, but it's better (simpler) to use Java's COSNaming service if you can. The Java side of that is easiest via JNDI.
          • 2. Re: obtaining an IOR for RMI-IIOP
            It looks like your link would be exactly what I'm looking for, but it's unwritten.

            I want to avoid using a separate naming process, which rules out COSNaming, right?

            Let me simplify my question - how can I convert a Remote object into an org.omg.CORBA.Object? This seems like a required operation for RMI-IIOP (under the hood). If I could figure how to do it in my code, now...

            Edited by: BrentBaccala on Mar 22, 2010 9:22 PM
            • 3. Re: obtaining an IOR for RMI-IIOP
              (a) Have it extend PortableRemoteObject instead of UnicastRemoteObject
              (b) process it with rmic -iiop -idl
              (c) bind it with JNDI instead of to the RMI Registry
              (d) take the generated IDL to the C++ client and use it to generate whatever has to be generated
              (e) avoid using Java classes in the remote interface

              Why do you want to avoid a separate naming process? 'orbd' is free with Java.
              • 4. Re: obtaining an IOR for RMI-IIOP
                Well, I figured it out. The key method is remoteToCorba in com.sun.jndi.toolkit.corba.CorbaUtils. Here's my server code:
                import java.io.*;
                import org.omg.CORBA.ORB;
                import com.sun.jndi.toolkit.corba.CorbaUtils;
                public class HelloServer {
                    public static void main(String[] args) {
                        try {
                            // Step 1: Instantiate the Hello servant
                            HelloImpl helloRef = new HelloImpl();
                            // Step 2: Initialize the ORB
                            ORB orb = ORB.init(args, null);
                            // Step 3: Convert the Hello servant to a CORBA object
                            org.omg.CORBA.Object corba_obj;
                            corba_obj = CorbaUtils.remoteToCorba(helloRef, orb);
                            // Step 4a: Announce the IOR to STDOUT
                            String ior = orb.object_to_string(corba_obj);
                            System.out.println("IOR: " + ior);
                            // Step 4b: Announce the IOR to a file
                            FileWriter fw = new FileWriter("hello.ior");
                            System.out.println("Hello Server: Ready...");
                         } catch (Exception e) {
                            System.out.println("Trouble: " + e);
                And here's the matching client code:
                import java.io.*;
                import org.omg.CORBA.ORB;
                import javax.rmi.PortableRemoteObject;
                public class HelloClient {
                    public static void  main( String args[] ) {
                        HelloInterface hi;
                        try {
                            // Step 1: Initialize the ORB
                            ORB orb = ORB.init(args, null);
                            // Step 2: Obtain the stringified IOR from a file
                            FileReader fr = new FileReader("hello.ior");
                            BufferedReader br = new BufferedReader(fr);
                            String ior = br.readLine();
                            // Step 3: Convert the IOR to a CORBA object reference
                            org.omg.CORBA.Object objref = orb.string_to_object(ior);
                            // Step 4: Narrow the CORBA object reference to the concrete type
                            hi = (HelloInterface) PortableRemoteObject.narrow(
                                objref, HelloInterface.class);
                            // Step 5: Invoke the method.
                            hi.sayHello( " MARS " );
                        } catch( Exception e ) {
                            System.err.println( "Exception " + e + "Caught" );
                            e.printStackTrace( );
                The other two files are unchanged from the original example:
                import java.rmi.Remote;
                public interface HelloInterface extends java.rmi.Remote {
                   public void sayHello( String from ) throws java.rmi.RemoteException;
                import javax.rmi.PortableRemoteObject;
                public class HelloImpl extends PortableRemoteObject implements HelloInterface {
                   public HelloImpl() throws java.rmi.RemoteException {
                       super();     // invoke rmi linking and remote object initialization
                   public void sayHello( String from ) throws java.rmi.RemoteException {
                       System.out.println( "Hello from " + from + "!!" );
                Compilation and usage is straightforward:
                javac *.java
                rmic -iiop HelloImpl
                java -cp . HelloServer
                java -cp . HelloClient
                It gives warnings about using a Sun proprietary interface, but that's the only problem that I've had with the Java end. Getting the C end working has been more challenging. ORBit seems to have some serious interoperability problems. I haven't gotten it working yet with Java.