Using RMI-IIOP with a CORBA/IDL client enables interoperability between non-Java clients and Java objects. If you have existing CORBA applications, you should program according to the RMI-IIOP with CORBA/IDL client model. Basically, you will be generating IDL interfaces from Java. Your client code will communicate with WebLogic Server through these IDL interfaces. This is basic CORBA programming.

The following sections provide some guidelines for developing RMI-IIOP applications with CORBA/IDL clients.

For further reference see the following Object Management Group (OMG) specifications:

• Java Language to IDL Mapping Specification at http://www.omg.org/cgi-bin/doc?formal/01-06-07

• CORBA/IIOP 2.4.2 Specification at http://www.omg.org/cgi-bin/doc?formal/01-02-33

• Working with CORBA/IDL Clients
  

Learn how the IDL takes part in the RMI-IIOP model.

Figure 4-1 IDL Client relationships

Description of "Figure 4-1 IDL Client relationships"

• Java to IDL Mapping
  

Learn about the object relationships when using RMI-IIOP to connect a client and server.

Figure 4-2 WebLogic RMI over IIOP object relationships

Description of "Figure 4-2 WebLogic RMI over IIOP object relationships"

• Objects-by-Value
  

Learn how to develop RMI over IIOP application with CORBA/IDL.

To develop an RMI over IIOP application with CORBA/IDL:

1. Define your remote object's public methods in an interface that extends java.rmi.Remote.

   This remote interface may not require much code. All you need are the method signatures for methods you want to implement in remote classes. For example:

   public interface Pinger extends java.rmi.Remote {
   public void ping() throws java.rmi.RemoteException;
   public void pingRemote() throws java.rmi.RemoteException;
   public void pingCallback(Pinger toPing) throws java.rmi.RemoteException;
   }
   

2. Implement the interface in a class named interfaceNameImpl and bind it into the JNDI tree to be made available to clients.

   This class should implement the remote interface that you wrote, which means that you implement the method signatures that are contained in the interface. All the code generation that will take place is dependent on this class file. Typically, you configure your implementation class as a WebLogic startup class and include a main method that binds the object into the JNDI tree. For example:

   public static void main(String args[]) throws Exception {
     if (args.length > 0)
     remoteDomain = args[0];
     Pinger obj = new PingImpl();
     Context initialNamingContext = new InitialContext();
     initialNamingContext.rebind(NAME,obj);
     System.out.println("PingImpl created and bound to "+ NAME);
   }
   

3. Compile the remote interface and implementation class with a Java compiler. Developing these classes in an RMI-IIOP application is no different than doing so in normal RMI. For more information on developing RMI objects, see Developing RMI Applications for Oracle WebLogic Server.

4. Generate an IDL file by running the WebLogic RMI compiler or WebLogic EJB compiler with the -idl option.

   The required stub classes will be generated when you compile the IDL file. For general information on the these compilers, refer to Understanding WebLogic RMI and Developing RMI Applications for Oracle WebLogic Server. Also reference the Java IDL specification at Java Language Mapping to OMG IDL Specification at http://www.omg.org/technology/documents/index.htm.

   The following compiler options are specific to RMI over IIOP:

   Table 4-2 RMI-IIOP Compiler Options

   Option	Function
   -idl	Creates an IDL for the remote interface of the implementation class being compiled
   -idlDirectory	Target directory where the IDL will be generated
   -idlFactories	Generate factory methods for value types. This is useful if your client ORB does not support the factory value type.
   -idlNoValueTypes	Suppresses generation of IDL for value types.
   -idlOverwrite	Causes the compiler to overwrite an existing idl file of the same name
   -idlStrict	Creates an IDL that adheres strictly to the Objects-By-Value specification. (not available with appc)
   -idlVerbose	Display verbose information for IDL generation
   -idlVisibroker	Generate IDL somewhat compatible with Visibroker 4.1 C++

   The options are applied as shown in this example of running the RMI compiler:

   > java weblogic.rmic -idl -idlDirectory /IDL rmi_iiop.HelloImpl

   The compiler generates the IDL file within sub-directories of the idlDirectoy according to the package of the implementation class. For example, the preceding command generates a Hello.idl file in the /IDL/rmi_iiop directory. If the idlDirectory option is not used, the IDL file is generated relative to the location of the generated stub and skeleton classes.

5. Compile the IDL file to create the stub classes required by your IDL client to communicate with the remote class. Your ORB vendor will provide an IDL compiler.

6. The IDL file generated by the WebLogic compilers contains the directives: #include orb.idl. This IDL file should be provided by your ORB vendor. An orb.idl file is shipped in the /lib directory of the WebLogic distribution. This file is only intended for use with the ORB included in the JDK.

7. Develop the IDL client.

   IDL clients are pure CORBA clients and do not require any WebLogic classes. Depending on your ORB vendor, additional classes may be generated to help resolve, narrow, and obtain a reference to the remote class. In the following example of a client developed against a VisiBroker 4.1 ORB, the client initializes a naming context, obtains a reference to the remote object, and calls a method on the remote object.

   Code segment from C++ client of the RMI-IIOP example

   // string to object
   CORBA::Object_ptr o;
   cout << "Getting name service reference" << endl;
   if (argc >= 2 && strncmp (argv[1], "IOR", 3) == 0)
     o = orb->string_to_object(argv[1]);
   else
     o = orb->resolve_initial_references("NameService");
   // obtain a naming context
   cout << "Narrowing to a naming context" << endl;
   CosNaming::NamingContext_var context = CosNaming::NamingContext::_narrow(o);
   CosNaming::Name name;
   name.length(1);
   name[0].id = CORBA::string_dup("Pinger_iiop");
   name[0].kind = CORBA::string_dup("");
   // resolve and narrow to RMI object
   cout << "Resolving the naming context" << endl;
   CORBA::Object_var object = context->resolve(name);
   cout << "Narrowing to the Ping Server" << endl;
   ::examples::iiop::rmi::server::wls::Pinger_var ping =
     ::examples::iiop::rmi::server::wls::Pinger::_narrow(object);
   // ping it
   cout << "Ping (local) ..." << endl;
   ping->ping();
   }
   

   Notice that before obtaining a naming context, initial references were resolved using the standard Object URL (see the CORBA/IIOP 2.4.2 Specification, section 13.6.7). Lookups are resolved on the server by a wrapper around JNDI that implements the COS Naming Service API.

   The Naming Service allows WebLogic Server applications to advertise object references using logical names. The CORBA Name Service provides:

   • An implementation of the Object Management Group (OMG) Interoperable Name Service (INS) specification.

   • Application programming interfaces (APIs) for mapping object references into an hierarchical naming structure (JNDI in this case).

   • Commands for displaying bindings and for binding and unbinding naming context objects and application objects into the namespace.

8. IDL client applications can locate an object by asking the CORBA Name Service to look up the name in the JNDI tree of WebLogic Server. In the example above, you run the client by entering:

   Client.exe -ORBInitRef NameService=iioploc://localhost:7001/NameService