[ Team LiB ] Previous Section Next Section


Java Remote Method Invocation (RMI) technology run over Internet Inter-ORB Protocol (IIOP) extends Common Object Request Broker Architecture (CORBA) services and distributed computing capabilities to the Java 2 environment.

RMI over IIOP Dissected

RMI is the Java standard for distributed computing. In simpler terms, RMI enables networked applications to obtain a reference to an object that resides elsewhere in the network, and to invoke methods on that object as though it resides on the local virtual machine.

CORBA, which is defined by the OMG (Object Management Group), is a well-known distributed-object programming model that supports a number of languages such as C++ and Smalltalk.

IIOP is a communication protocol that works well over heterogeneous networks via the Internet. Because IIOP is a TCP/IP-based proxy, CORBA is one of the many architectures that use it as a communication protocol. The IIOP protocol connects CORBA products from different vendors, ensuring interoperability among them.

RMI-IIOP is essentially a marriage of RMI and CORBA. By extending RMI to work over IIOP, the possibilities become endless. In a homogeneous, Java-to-Java environment, RMI-IIOP opens the communication to use the standardized IIOP protocol. But the greatest benefit that can be leveraged from the marriage is that it allows for easier application and platform integration between the components written in C, Smalltalk, and Java components. The components interact using the Interface Definition Language (IDL). Using RMI over IIOP, objects can be passed both by reference and by value over IIOP.


The WebLogic Server 8.1 RMI-IIOP implementation has the following features:

  • IIOP-enabled communication in a homogeneous Java-to-Java environment— RMI clients can use the IIOP protocol to invoke objects running in WebLogic Server. The release of Java 1.3 JDK facilitates this capability.

  • CORBA integration— CORBA/IDL clients written in C++ or Smalltalk can be seamlessly integrated into the services in WebLogic. The Object By Value specification from the Object Management Group defines an enabling technology for exporting the Java object model into the CORBA/IDL programming model. This facilitated the exchange of complex data types between the two models. WebLogic Server can support Object By Value with any CORBA ORB that correctly implements the specification.

  • Heterogeneous clients can be connected to WebLogic Server EJBs.

  • Object Transaction Services 1.2 (OTS 1.2) support, which enables transactions in RMI-IIOP.

  • Hot code generation for iiop stubs.

  • A WebLogic IIOP client is fully clusterable.

  • CSIv2 (Common Secure Interoperability, version 2) provides security features such as client authentication, delegation, and privilege functionality.

  • Full support for the COS-Naming API.

  • Bi-directional interoperability between WebLogic Server and Tuxedo clients— This integration is described in detail in the earlier section on the WebLogic Tuxedo Connector.

Figure 34.10 indicates how WebLogic Server acts as a client and as a server for other ORB/RMI clients.

Figure 34.10. WebLogic—CORBA integration.


With WebLogic RMI over IIOP, remote interfaces can be written in the Java programming language and implemented using Java technology and the Java RMI APIs. Those interfaces can be implemented in any other language that's supported by an OMG mapping and a vendor-supplied ORB for that language. Additionally, clients can be written in other languages using the IDL derived from the remote Java technology–based interfaces.

Programming Models: IDL Versus RMI

RMI/IIOP can be used with IDL clients and RMI clients. Both models share the following characteristics:

  • Interoperable environment between heterogeneous systems

  • Use of ORB and IIOP as the transport protocol for distributed applications

The client program can use only one of the interfaces. That is, it can use either IDL or RMI, but not both.

RMI/IIOP with RMI Java Clients

This programming model combines the power of RMI with the underlying transport mechanism as IIOP. Pure WebLogic RMI clients that use t3 as the communication protocol need to distribute the WebLogic classes to the client layers. IIOP is an industry standard; this aids in easier migration as compared to t3, which is a proprietary standard of BEA.


In this programming model, non-Java clients and Java objects can seamlessly interoperate in the same environment using RMI/IIOP as the transport mechanism. IDL interfaces can be generated from the Java code, which can integrate with the WebLogic Server. The model involves an ORB and a compiler that creates an IDL interface.

RMI/IIOP with a Tuxedo Domain

The WebLogic to Tuxedo Connector described earlier uses RMI/IIOP as the underlying transport mechanism to integrate Tuxedo domain applications with the WebLogic Server. WTC also enables Tuxedo to invoke WebLogic Server EJBs and other applications in response to a service request.


Enterprise JavaBeans use RMI over IIOP for their distributed object model. EJB interoperability in heterogeneous server environments is achieved when EJBs are implemented using the RMI over IIOP protocol. Coupling EJBs with CORBA with RMI/IIOP provides the following advantages:

  • Enterprise beans in one EJB server can access enterprise beans in another EJB server.

  • A non-Java platform CORBA client can access any enterprise bean object.

  • A Java client using an ORB from one vendor can access EJBs residing on another J2EE-compliant EJB server.

The mapping information needed for the CORBA/IDL clients can be generated from the EJB interfaces using the WebLogic utility weblogic.ejbc. The IDL files it generates represent the CORBA definition of the EJB interface.

WTC and CORBA Interoperability

WTC enables objects deployed in WebLogic Server to invoke CORBA objects deployed in a Tuxedo domain. The CORBA Java outbound API defines the following procedures for the interoperability of WebLogic Server objects into Tuxedo CORBA objects:

  • Instantiate the WTC ORB in the bean.

    ORB orb = (ORB)c.lookup("java:comp/ORB");
  • Obtain object references. The CosNaming service is used to get a reference to an object in the remote Tuxedo CORBA domain.

    org.omg.CORBA.Object greetingfactory_oref = orb.string_to_object("corbaname:tgiop


    helloWorld is the domain ID of the Tuxedo domain specified in the Tuxedo UBB.

    Greeting_factory is the name that the object reference was bound to in the Tuxedo CORBA CosNaming server.

  • Invoke the target method.

In Listing 34.6, the code provides an example of invoking a simple WTC ORB using the concepts described earlier.

Listing 34.6 Simple WTC ORB Invocation
throws RemoteException
   System.out.println("Welcome " + aName);

   try {
    // Initialize the ORB.
     String [] greets
     Properties Prop;
     Prop = new java.util.Properties();

     ORB orb = (ORB)c.lookup("java:comp/ORB");
    // Get the Greeting factory.
    org.omg.CORBA.Object greeting_fact_oref =

    //Narrow the Greeting factory.
    GreetingFactory greeting_factory_ref =

    // Find the simple object.
    Greeting greet = greeting_factory_ref.find_greeting();

    // find salutation
    String salutation = GreetingFactoryHelper.findSaluation(aName);
    // Format a Greeting
    org.omg.CORBA.StringHolder wish=
     new org.omg.CORBA.StringHolder("Hello "+salutation+" "+ aName);

    return wish.value;
   catch (Exception e) {
    throw new RemoteException("Unable to invoke TUXEDO CORBA server: " +e);

Additionally, Tuxedo CORBA objects can invoke EJB services deployed in WebLogic Server. The CosNaming service has bound WebLogic Server's name service, which the client can use to locate the required service.


There are some inherent limitations to using RMI-IIOP on both the client and server. Some of the limitations are

  • Because the RMI server object and the IDL client have different type systems, it could potentially cause name conflicts and classpath problems. The client classes and server-side classes should be separate.

  • Incorrect marshalling of unchecked exceptions.

  • Value types as defined in the CORBA specification have to be used for passing objects by value. Value type implementations are bound by the platform they're defined on.

  • Java types that have their own serialization logic (that is, have writeObject() defined in them) are mapped to custom value types in IDL. Custom code has to be written for unmarshalling such objects on the client.

    [ Team LiB ] Previous Section Next Section