Overriding the Built-in ORB
iPlanet^TM Application Server Samples

Updated June 11, 2001

iPlanet Application Server relies on a built-in ORB to support RMI/IIOP access to EJBs from Java application clients. When implementing servlets and EJBs that access backend CORBA-based applications residing outside of the application server, you may need to override the built-in ORB classes with ORB classes from commercial products such as VisiBroker or Orbix 2000. To support backend access to CORBA-based applications, there are several methods by which you can override the implementation classes of the built-in ORB with the corresponding classes of a commercial ORB. This document provides an overview of the approaches and outlines the pros and cons of each approach. All of the approaches are standard means of specifying the implementation classes of ORBs in Java 1.2 environments.

After reviewing the available methods, refer to the section Simultaneous Built-in and Commercial ORB Support for an explanation of how to support both the bundled iPlanet ORB for RMI/IIOP access to EJBs and a commercial ORB to access backend CORBA-based applications.

Overview of Override Methods

There are a number of methods for overriding the built-in ORB implementation classes with the implementation classes of a commercial ORB of your choice. You can specify the ORB implementation classes:

As properties on ORB.init()
As entries in the JVM's orb.properties file
As properties on the Java command line

Keep in mind that each of these methods require that the commercial ORB classes be added to the CLASSPATH of the application server. Only the method by which you inform the ORB of which implementation classes to use varies with each method.

ORB.init() Properties Method

The sample applications use this approach to demonstrate how one can programmatically override the ORB classes being used by the application server. After having added the commercial ORB classes to the application server's CLASSPATH, the application specifies the ORB classes to use as properties on the ORB.init() call.

For example:

...
Properties orbProperties = new Properties();
orbProperties.put("org.omg.CORBA.ORBClass", "com.iona.corba.art.artimpl.ORBImpl");
orbProperties.put("org.omg.CORBA.ORBSingletonClass", "com.iona.corba.art.artimpl.ORBSingleton");
orb = ORB.init(args, orbProperties);
...

The main benefit of this approach is that RMI/IIOP access to EJBs housed in the application server will still be performed using the built-in iPlanet ORB classes while only access from servlets and EJBs to backend CORBA-based applications will use the third party ORB classes. This is the cleanest method of supporting simultaneous use of multiple ORBs in the application server environment.

A slight drawback of this approach is that your client application is explicitly specifying the ORB implementation class names on the ORB.init() call. This drawback can be mitigated by defining the implementation class names as environment settings in your web.xml and/or ejb-jar.xml files.

orb.properties Method

In Java 2 1.2 environments, the JVM's orb.properties file contains property settings to identify the ORB implementation classes that are used by default throughout the JVM. To override the use of the built-in iPlanet ORB classes, you can simply modify the orb.properties file to specify third party ORB classes and restart the application server.

For example, to set the implementation classes to specify the Orbix 2000 classes one would make the following modification to the orb.properties file:

install_dir/ias/usr/java/jre/lib/orb.properties

Before:

org.omg.CORBA.ORBClass=com.netscape.ejb.client.ClientORB
org.omg.CORBA.ORBSingletonClass=com.sun.corba.ee.internal.corba.ORBSingleton
javax.rmi.CORBA.UtilClass=com.netscape.ejb.client.Util
javax.rmi.CORBA.StubClass=com.sun.corba.ee.internal.javax.rmi.CORBA.StubDelegateImpl
javax.rmi.CORBA.PortableRemoteObjectClass=com.sun.corba.ee.internal.javax.rmi.PortableRemoteObject

After:

org.omg.CORBA.ORBClass=com.iona.corba.art.artimpl.ORBImpl
org.omg.CORBA.ORBSingletonClass=com.iona.corba.art.artimpl.ORBSingleton
javax.rmi.CORBA.UtilClass=com.netscape.ejb.client.Util
javax.rmi.CORBA.StubClass=com.sun.corba.ee.internal.javax.rmi.CORBA.StubDelegateImpl
javax.rmi.CORBA.PortableRemoteObjectClass=com.sun.corba.ee.internal.javax.rmi.PortableRemoteObject

The javax.rmi classes are used to support RMI/IIOP client access to EJBs housed in the application server. Since these classes are not used for access to backend CORBA servers, you do not need to override these settings.

The main benefit of this approach is that it involves only a one time setting for all applications deployed to the application server. There is no need for each servlet and/or EJB that is acting as a client to a backend CORBA application to specify the ORB implementation classes.

The main drawback of this approach is that setting orb.properties overrides the ORB used for RMI/IIOP access to EJBs housed in the application server. Since only the built-in iPlanet ORB is supported for RMI/IIOP, taking the orb.properties approach effectively breaks RMI/IIOP access to EJBs. If your environment does not require RMI/IIOP support, then this approach might be the most straightforward for your environment.

Command Line Method

One can also specify the ORB implementation classes on the Java command line. However, this approach is difficult to use on NT because the application server's command line is not as exposed to the administrator as it is on UNIX through the ias/bin/kjs shell script. An example of specifying the implementation classes on the command line follows:

java -Dorg.omg.CORBA.ORBClass=com.iona.corba.art.artimpl.ORBImpl -Dorg.omg.CORBA.ORBSingletonClass=com.iona.corba.art.artimpl.ORBSingleton ...

Summary of Benefits and Drawbacks

The following summary is based on the perspective of setting the ORB implementation classes in the application server environment.

Approach	Benefits	Drawbacks
ORB.init(args, props)	Easiest means to support both the bundled iPlanet ORB for front-end RMI/IIOP access to EJBs and a commercial ORB to access backend systems. Don't have to specify command line arguments. Don't have to modify orb.properties file.	Each ORB.init() caller in your servlets and EJBs must specify the implementation class names. Product-specific class names are hardcoded unless environment settings are used.
orb.properties	Doesn't force servlets and EJBs to specify product-specific ORB implementation classes. Set once and forget about it.	Either commercial ORB classes or built-in ORB classes can be specified. Not both. Disables RMI/IIOP support.
Command Line Properties	May work well on UNIX if your environment has no plans to use RMI/IIOP.	On UNIX, requires script changes in ias/bin/kjs shell script to set properties for either built-in ORB or commercial ORB. On NT, requires modification of Java command line arguments in the application server's Registry.

Simultaneous Built-in and Commercial ORB Support

If your environment requires support for both accessing EJBs via RMI/IIOP through the bundled iPlanet ORB and accessing backend CORBA-based applications through a commercial ORB, then you should consider the ORB.init() Properties approach as the cleanest manner in which to configure the application server to use two ORBs concurrently.

With the ORB.init() properties approach, you need only add the commercial ORB classes to the application server CLASSPATH and specify the appropriate implementation classes in the servlet or EJB source code. No modifications are necessary to either the application server's orb.properties file or the Java command line.

The EJB-based samples include RMI/IIOP clients that can use RMI/IIOP with the iPlanet ORB at the same time EJBs use a third party ORB to access backend CORBA components.