RMI-IIOP                                          Edit   Peter Komisar

This is a quick edit of the JavaWorld article RMI over IIOP by Akira Andoh and Simon Nash.
You can see I have quoted the original so much, you might as well go over and read it at  http://www.javaworld.com/javaworld/jw-12-1999/jw-12-iiop.html


RMI-IIOP, developed jointly by IBM and Sun, is a new version of Remote Method Invocation
RMI for IIOP (Internet Inter-ORB Protocol) that combines RMI's easy programming features
with CORBA's interoperability.

RMI and CORBA have developed independently as distributed-objects programming models.
RMI is a Java-based, easy-to-use programming model for distributed objects. CORBA (the
Common Object Request Broker Architecture), defined by the OMG (Object Management Group),
is a well-known distributed-object programming model that supports a number of languages. The
IIOP protocol connects CORBA products from different vendors, ensuring interoperability among
them. RMI-IIOP is a mating of RMI and CORBA, models which have historically not been capable
of communicating with each other. For example, RMI's native protocol, JRMP (Java Remote
Method Protocol), cannot connect with other protocols.

If the only programming language that you require in a new project is Java, only  RMI and JRMP
are needed. However, legacy software is in most cases programmed in languages other than Java
and in such situations, developers need CORBA.

 RMI-IIOP supports both JRMP and IIOP protocols.
 

 "A server binary (i.e., a class file) created using RMI-IIOP APIs can be exported as either
   JRMP or IIOP. You don't have to rewrite its Java source code, or recompile it when
   changing from JRMP to IIOP, or vice versa. You need only change parameters such as Java
   system properties when running it. Alternatively, you can determine the protocol used by
   specifying it in the Java source code. The same flexibility applies to RMI-IIOP client code.

   When you export an RMI-IIOP object on your server, you do not  necessarily have to choose 
   between JRMP and IIOP. If you need a single server object to support both JRMP and IIOP 
   clients, you can export your RMI-IIOP object to both JRMP  and IIOP simultaneously. In 
   RMI-IIOP terminology, this is called dual export.

   RMI-IIOP APIs support both JRMP and IIOP protocols. This means that, without rewriting 
   the source code of an RMI (JRMP) object, it can be called by a new RMI-IIOP client. Similarly, 
   without rewriting the source code of an RMI (JRMP) client, you can replace an RMI (JRMP) 
   server object with a new RMI-IIOP object that a CORBA client can also call. Thus, RMI-IIOP 
   preserves existing  investment in RMI (JRMP) binaries, because RMI-IIOP can communicate 
   with them without  any source-code changes or recompilation."

                                                                    -from "RMI over IIOP" by Akira Andoh and Simon Nash 
.

Interoperability with CORBA

An RMI-IIOP client (an RMI program with no Corba literacy required) calls a CORBA server.
A CORBA client (written to the CORBA spec, no RMI literacy required ) calls an RMI-IIOP
server. The established technique separating interface from implementation is employed allowing
users of both RMI-IIOP and CORBA to access the services of the other protocol. An RMI
Java interface file is serves as the interface to RMI-IIOP users, while IDL is the interface to
CORBA users. The actual  implementation hidden.

Caveat
 

"An RMI-IIOP client cannot necessarily access all existing CORBA objects. The semantics 
of CORBA objects defined in IDL are a superset of those of RMI-IIOP objects, which is why
an existing CORBA object's  IDL cannot always be mapped into an RMI-IIOP Java interface. 
It is only when a specific CORBA object's semantics happen to correspond with those of 
RMI-IIOP that an RMI-IIOP client can call a CORBA object...However, the incompatibility 
here shouldn't be overstated. The restrictions apply only when dealing with existing CORBA objects." 
                                                                    -from "RMI over IIOP" by Akira Andoh and Simon Nash 
.

A corresponding IDL can be generated with the rmic tool when creating a new distributed object
using the RMI-IIOP Java interface.

Design Considerations

Two major prerequisites that shaped the design of the RMI-IIOP protocol: the RMI semantics had to
be left as intact as possible, and CORBA needed to be enhanced so that RMI semantics could be
implemented using the CORBA infrastructure. Fortunately, the CORBA community recognized this
and accepted the following major changes so that RMI-IIOP could become a reality.

1) the Objects by Value specification - already available to RMI users in the form of Java object
serialization, is a CORBA specification intended to make other languages implement a similar capability.

2) The Java-to-IDL Mapping specifications -used to convert RMI Java interfaces into CORBA IDL
definitions, (not be confused with the IDL-to-Java mapping already defined in CORBA 2.2.)

Current Status
 

"OMG has already officially accepted both specifications for CORBA 2.3, but current CORBA implementations will have to play catch. For example, an IDL-to-Java compiler that conforms to CORBA 2.3 is available from Sun for use in conjunction with the RMI-IIOP ORB (object request broker), but it is currently an early access version suitable only for exploring the interoperability of CORBA and RMI-IIOP, and not for production use. Furthermore, the IDL-to-Java compiler distributed by Sun for use with the Java IDL ORB in Java 1.2 does not conform to CORBA 2.3, so it cannot be used to test interoperability with RMI-IIOP. This situation will be resolved over the next few months as CORBA vendors introduce new versions of their products that support CORBA  2.3. For example, the next version of the Java 2 Platform, Standard Edition will include both RMI-IIOP and a production-quality IDL-to-Java compiler that supports CORBA 2.3." . 
                                                                                                -from "RMI over IIOP" by Akira Andoh and Simon Nash 
.

Development procedure

To do a RMI-IIOP to RMI-IIOP client server almost all that needs to be done is to use the -iiop
parameter when using the rmic compiler and be aware of differences in the architecture incurred by
using the new protocol. The new stub and skeleton ties in with the IIOP protocol. Though procedures
are similar, the runtime environment in RMI-IIOP is different in that communication is made through a
CORBA 2.3-compliant ORB, using IIOP for communication between servers and clients. Also there
are implementation differences when running over IIOP. Distributed garbage collection is not supported
by CORBA, which uses explicit destruction and persistent object references with transparent passivation
and activation. The RMI registry is replaced by JNDI with the CosNamingor LDAP service provider,
and RMI activation is replaced by the Portable Object Adapter. Remote object references must be
downcast using a programmatic narrow( ) method instead of a direct Java language cast. Other RMI
semantics, such as object serialization, are fully supported over IIOP.

 An RMI Java interface file that was used to define the RMI-IIOP

1) A Java interface file is passed to the rmic compiler and the -idl option is specified.  rmic automatically
generates the corresponding IDL file (MyObject.idl).
2) Using a CORBA 2.3-compliant IDL compiler, the stub is generated in the  language of choice.
3) Through the stub, a CORBA client can access the RMI-IIOP object that was created.

An RMI-IIOP client using a CORBA object

1) produce a skeleton in the language of choice
2) use this skeleton to produce a pure CORBA object. based on the RMI Java interface file
3) access the RMI-IIOP client

RMI-IIOP and Java IDL
 

As previously explained, an RMI-IIOP client cannot necessarily access an existing CORBA. If you want
to use Java to access existing CORBA resources, Java IDL is recommended Conversely, if  you want to
export Java RMI resources to CORBA users, you should use RMI-IIOP.

It is speculated that RMI will be integrated into RMI-IIOP. Sun currently states it intends to support all
three protocols.

Differences in development procedure in the Server

To conclude, examining the differences in procedures between conventional Java RMI and
RMI-IIOP shows what needs to be done to convert from Java RMI to RMI over IIOP.

1) Because the usual base class of  RMI-IIOP servers is PortableRemoteObject, you must change
    this import statement accordingly, as well as the derivation of the implementation class of the remote
    object.  // import javax.rmi.PortableRemoteObject;

2) The class used as the naming service has changed to InitialContext, so this associated import
     statement must also be changed. // import javax.naming.InitialContext;

// public class MyObjectImpl extends PortableRemoteObject implements MyObject

3) Use an InitialContext to request naming registration of a remote object.
      // InitialContext.rebind("Robocop",ObjRef);

4) After completing the Java coding, you must generate a tie for IIOP, using the rmic compiler with
     the -iiop option.
 
Ties mentioned, (in respect to CORBA), in the Java Developer's Handbook Heller&Roberts...

Another class may be used in between the skeleton and the implementation that delegates the method calls to the appropriate implementation class. These delegation-based skeletions are referred to as Ties.  Java IDL provides a tool for creating a Tie by specifying  the -ftie flag to the idltojava application on the command line

5) run the CORBA CosNaming tnameserv as a name server instead of rmiregistry.

6) For CORBA clients, you must also generate IDL from the RMI Java interface, using the rmic
    compiler with the -idl option.

In the Client

 1) import changes as for the Server

   // import javax.rmi.PortableRemoteObject;
   //  import javax.naming.InitialContext;

2)  Create a local InitialContext object reference from the registered object name, on which you
     call lookup( ). The lookup( ) method returns a java.lang.Object, and you must then use the
     narrow( ) method of PortableRemoteObject to cast its type.

      // InitialContext IC = new InitialContext(env);
      // Object obj = IC.lookup("Robocop");
      // MyObject myobj =(MyObject)PortableRemoteObject.narrow(obj,MyObject.class);

3) You generate stubs for IIOP using the rmic compiler with the -iiop option.
 
 
Finally, the Conclusion of the Akira Andoh and Simon Nash RMI-IIOP article quoted

  "RMI-IIOP combines RMI's ease of use with CORBA's interoperability and mission-critical infrastructure. Its RMI-centric programming model enables interoperability with, and  migration from, existing RMI code. The ability to use IIOP and generate IDL allows seamless integration into a CORBA infrastructure. Its close association with EJB and its inclusion (starting with the next release) in the core Java 2 Platform will establish it as a foundation technology for enterprise middleware. By bringing Java and CORBA together as a strong and well-integrated combination, RMI-IIOP enhances the value of both technologies. This  protocol offers developers access to the best of both worlds, and makes both worlds better."
.