Supplementary material for Chapter 17:
CORBA CASE STUDY

Java CORBA with Java 2, Version 1.4

The main change between Java versions 1.3 and 1.4 is the inclusion of a Portable Object Adapter (POA). CDK3 page 678 discusses the Object Adapter, which is an important component of of the server architecture shown in Figure 17.6. The POA is useful because it is designed to interwork with code written for different implementations of CORBA.

For programmers that are accustomed to the earlier versions, the main changes affecting them are:

the use of the POA is visible in the Java code generated by the IDL compiler,
server programs must interact with the POA, primarily to register CORBA objects with it.

Code Generated by the IDL compiler

The IDL compiler is now called idlj. As with earlier versions, it generates proxy classes and a class to correspond to each of the structs in the IDL interface as well as helper and holder classes (see CDK3 page 674). The main differences in the generated code are:

The class names of server skeletons end in POA e.g. ShapeListPOA. As before, each servant class should be defined to extend the corresponding skeleton class.
The Java interface corresponding to each IDL interface is built from two interfaces. The name of the first ends in Operations - this interface just defines the operations of the IDL interface. The second interface has the same name as the IDL interface and implements the operations in the first interface as well as those in an interface suitable for a CORBA object. For example the IDL interface ShapeList, results in two Java interfaces ShapeListOperations and ShapeList.

The programs in CDK Figures 17.2 - 17.5

A Java 1.4 version of each of the programs in the figures in Section 17.2.1 is available on this under additional material on this website. The changes that were required are described below.

We have also provided (in pdf) a new version of pages 673-677of the book. The changes affect the subsection on pseudo objects (p 673) and the first part of Section 17.2.1, up to but not including the subsection on the client program.

Implementing the server to use the POA

The code required in a version 1.3 server is outlined on pages 674 - 6 and an example is given in Figure 17.4. We now suggest how to alter this example to use the POA with the 1.4 version. The main method must be altered so that it activates a POA and registers the new instance of ShapeListServant with it. We require some additional imports:

import org.omg.PortableServer.*;
import org.omg.PortableServer.POA;

As before, it creates and initializes the ORB (line 1). But lines 2 and 3 should be replaced with the following code:

// get reference to rootpoa & activate the POAManager
POA rootpoa = POAHelper.narrow(orb.resolve_initial_references("RootPOA"));
rootpoa.the_POAManager().activate();

// create servant - note that we pass the servant a reference to the POA
ShapeListServant SLSRef = new ShapeListServant(rootpoa);

// register the servant with the POA and get an object reference for it
org.omg.CORBA.Object ref = rootpoa.servant_to_reference(SLSRef);
ShapeList SLRef = ShapeListHelper.narrow(ref);

The code from lines 4-7 need not be altered. However, to conform with the names used above, line 7 should be replaced by:

ncRef.rebind(path, SLRef);

The two lines of code after line 7 are for starting the server running. They should be replaced by:

// wait for invocations from clients
orb.run();

The servant classes

As in version 1.3, each servant class extends the corresponding skeleton class and implements the methods of an IDL interface using the method signatures defined in the equivalent Java interface. All of the servant classes need an additional import:

import org.omg.PortableServer.POA;

In addition, a servant class must be defined to inherit from the corresponding POA skeleton e.g.

class ShapeListServant extends ShapeListPOA

It is only factory classes such as ShapeListServant (those that create their own CORBA objects) that require additional changes. (see Figure 17.3). We now discuss these changes in the context of Figure 17.3.

The changes in this class affect the definition of one of the instance variables, the constructor and the method newShape.

Instead of the instance variable ORB theOrb, we have

POA theRootpoa;

The constructor passes on a reference to the root POA so that this method can register new Shape objects as they are created.

public ShapeListServant(POA rootpoa){
 theRootpoa = rootpoa;

The new version of the method newShape is as follows:

version++;
Shape s = null;
ShapeServant shapeRef = new ShapeServant( g, version);
try {
	 org.omg.CORBA.Object ref = theRootpoa.servant_to_reference(shapeRef);
	 s = ShapeHelper.narrow(ref);
} catch (Exception e) { ...}
if(n >=100) throw new ShapeListPackage.FullException();
theList[n++] = s;
return s;

Note that the main difference is that the new CORBA object is registered with the root POA instead of with the ORB. This invocation of the root POA returns a remote reference to the new CORBA object , which is converted to type Shape, stored in the list of graphical objects and then returned. Note that with the version 1.4 skeletons it is not possible to cast the ShapeServant reference into the type Shape as we did in our version 1.3 example.

Documentation on Java 2 version 1.4 CORBA

See the document on the changes in CORBA IDL between versions 1.3 and 1.4 . This gives the changes in more detail than we have here. It also tells you how to use the version 1.4 idlj compiler to produce code compatible with version 1.3 server programs.

An example of a hello world program using the POA and Java 1.4 is available here.

See detailed description of the POA for a good description of the functionality of the POA. This is essential reading if you want to know how to configure its policies, including for example threading, lifespan, naming of CORBA objects.

Supplementary material for Chapter 17: CORBA CASE STUDY