Skip navigation.
Downloads | Product Documentation | Support

Programming Stand-alone Clients

# Developing a CORBA/IDL Client

RMI over IIOP with CORBA/IDL clients involves an Object Request Broker (ORB) and a compiler that creates an interoperating language called IDL. C, C++, and COBOL are examples of languages that ORBs may compile into IDL. A CORBA programmer can use the interfaces of the CORBA Interface Definition Language (IDL) to enable CORBA objects to be defined, implemented, and accessed from the Java programming language. The following sections provide information on how to develop clients for heterogeneous distributed applications:

- Guidelines for Developing a CORBA/IDL Client
- Procedure for Developing a CORBA/IDL Client

# Guidelines for Developing a CORBA/IDL Client

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 Mapping to OMG IDL Specification
- CORBA/IIOP 2.4.2 Specification

## Working with CORBA/IDL Clients

In CORBA, interfaces to remote objects are described in a platform-neutral interface definition language (IDL). To map the IDL to a specific language, you compile the IDL with an IDL compiler. The IDL compiler generates a number of classes such as stubs and skeletons that the client and server use to obtain references to remote objects, forward requests, and marshall incoming calls. Even with IDL clients it is strongly recommended that you begin programming with the Java remote interface and implementation class, then generate the IDL to allow interoperability with WebLogic and CORBA clients, as illustrated in the following sections. Writing code in IDL that can be then reverse-mapped to create Java code is a difficult and bug-filled enterprise, and BEA does not recommend it.

The following figure shows how IDL takes part in a RMI-IIOP model.

Figure 8-1 IDL Client (Corba object) relationships

## Java to IDL Mapping

In WebLogic RMI, interfaces to remote objects are described in a Java remote interface that extends `java.rmi.Remote`. The Java-to-IDL mapping specification defines how an IDL is derived from a Java remote interface. In the WebLogic RMI over IIOP implementation, you run the implementation class through the WebLogic RMI compiler or WebLogic EJB compiler with the `-idl` option. This process creates an IDL equivalent of the remote interface. You then compile the IDL with an IDL compiler to generate the classes required by the CORBA client.

The client obtains a reference to the remote object and forwards method calls through the stub. WebLogic Server implements a `CosNaming` service that parses incoming IIOP requests and dispatches them directly into the RMI runtime environment.

The following figure shows this process.

Figure 8-2 WebLogic RMI over IIOP object relationships

## Objects-by-Value

The Objects-by-Value specification allows complex data types to be passed between the two programming languages involved. In order for an IDL client to support Objects-by-Value, you develop the client in conjunction with an Object Request Broker (ORB) that supports Objects-by-Value. To date, relatively few ORBs support Objects-by-Value correctly.

When developing an RMI over IIOP application that uses IDL, consider whether your IDL clients will support Objects-by-Value, and design your RMI interface accordingly. If your client ORB does not support Objects-by-Value, you must limit your RMI interface to pass only other interfaces or CORBA primitive data types. The following table lists ORBs that BEA Systems has tested with respect to Objects-by-Value support:

Table 8-1 ORBs Tested with Respect to Objects-by-Value Support

Vendor | Versions | Objects-by-Value
--- | --- | ---
BEA | Tuxedo 8.x C++ Client ORB | Supported
Borland | VisiBroker 3.3, 3.4 | Not supported
Borland | VisiBroker 4.x, 5.x | Supported
Iona | Orbix 2000 | Supported (BEA has encountered problems with this implementation)

For more information on Objects-by-Value, see "Limitations of Passing Objects by Value" in Programming WebLogic RMI.

# Procedure for Developing a CORBA/IDL Client

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

1. Follow steps 1 through 3 in Developing a J2SE Client.
2. 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 Programming WebLogic Enterprise JavaBeans. Also reference the Java IDL specification at Java Language Mapping to OMG IDL Specification.

The following compiler options are specific to RMI over IIOP:

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` valuetype.
`-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.

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

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 that comes with WebLogic Server.

4. 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 (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.

5. 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`.