Page 3 of 6
> java ior.IorServer IOR:000000000000001949444c3a696f722f53696d706c654f626a656374 3a312e3000000000000000010000000000000030000100000000000a737 465656c7261696e00079e00000018afabcafe000000023bd4cf8d00000008 0000000000000000 Ready for client requests to simple object...
The IOR may be a String, but it certainly is not human readable.
For this simple example, I am going to run the client application from the same directory as the IorServer application. The client application initializes the ORB, reads in the stringified IOR from the simple.ior file, and converts the IOR to a SimpleObject CORBA reference (proxy).
package ior;
import org.omg.CORBA.ORB;
import java.io.*;
public class IorClient {
public static void main(String args[])'
throws IOException {
//initialize ORB and stringify object
ORB orb = ORB.init(args, null);
//read stringified object to file
FileReader fr = new
FileReader("simple.ior");
BufferedReader br = new
BufferedReader(fr);
String ior = br.readLine();
org.omg.CORBA.Object obj = orb.string_to_object(ior);
SimpleObject proxy = SimpleObjectHelper.narrow(obj);
//invoke methods
proxy.invoke();
System.out.println("Invoked method on simple object");
}
}
In CORBA, the org.omg.CORBA.Object interface defines a CORBA proxy (object reference). It is analogous to java.rmi.Remote in RMI. The choice of the interface name is unfortunate, since it collides with the java.lang.Object class name if the org.omg.CORBA package is imported. But I digress.
The string_to_object() method returns a CORBA Object implementation, which refers to a SimpleObject servant. In Java, a program would typically down-cast the reference to a SimpleObject and invoke the reference's methods.
When using CORBA, however, a narrow must be performed. Narrowing is performed using the IDL-to-Java-compiler-generated XXXHelper class -- SimpleObjectHelper in this case. Attempting a simple cast will cause a ClassCastException. Strange, but true.
The COS Naming Service is an OMG-specified extension to the core CORBA standard, where COS stands for Common Object Service. This naming service allows an object to be published using a symbolic name, and it allows client applications to obtain references to the object using a standard API. The COS Naming Service can reside on any host accessible within the network and enables applications to publish, lookup and list CORBA object references from any network host.
A namespace is the collection of all names bound to a naming service. A name space may contain naming context bindings to contexts located in another server. In such a case, the name space is said to be a federated name space since it is a collection of name spaces from multiple servers. An interesting point is that the location of each context is transparent to the client applications; they will have no knowledge that multiple servers are handling the resolution requests for an object.
Java 2 ships with a compliant implementation of the COS Naming Service, called tnameserv. The command-line syntax for running tnameserv is:
> tnameserv [-ORBInitialPort ####]
The tnameserv runs on port 900 unless specified otherwise using the -ORBInitialPort command-line parameter.
The Java IDL COS Naming Service implementation supports transient bindings only, which means objects must be reregistered
each time the naming service is restarted. The COS Naming Service implementations for Iona and Inprise are much more sophisticated
and scalable, since they support persistent bindings, load balancing, and customization. The JDK tnameserv naming service is more than adequate to get developers started on a project. When rolling out your applications, you will
want to purchase a commercial implementation to gain persistent naming and load balancing capabilities.
A COS Naming Service stores object references in a hierarchical name space; much like a filesystem uses a directory structure to store files. Specifically, bindings maintain the association between a symbolic name and an object reference, while naming contexts are objects that organize the bindings into a naming hierarchy. Like the root directory in a filesystem, the initial naming context provides a known point to build binding hierarchies. To complete the filesystem analogy, a binding maps to a file and a naming context maps to a directory. Thus, a naming context can contain multiple bindings and other naming contexts.
Consider a company that maintains an administrative database of devices on the network. These devices implement an administrative CORBA interface that defines attributes for querying current state and performing basic configuration tasks. Figure 2 depicts a possible naming hierarchy and illustrates that the same object may occur in multiple places within a naming hierarchy. For example, each printer is listed under a building and under printers.

Figure 2. Example naming hierarchy
In this article, a dash (-) is used to separate each naming component. For example, building-461-fax 1 would denote the fax 1 node located under the 461 context, which happens to be bound to the building context. The name building-461-fax 1 is known as a compound name because it consists of more than a single binding.
Before performing any tasks using the COS Naming Service, you must obtain a reference to the initial naming context. There are two standard ways to get the initial naming context:
org.omg.CORBA.Object resolve_initial_references(String name) method to obtain well-known services, where the name parameter specifies the requested service. Example services include the interface repository and the COS Naming Service.
The name NameService requests a reference to the naming service. The following code demonstrates how to obtain a reference to the COS Naming Service:package ior;
import org.omg.CosNaming.*;
import org.omg.CosNaming.NamingContextPackage.AlreadyBound;
import org.omg.CosNaming.NamingContextPackage.CannotProceed;
import org.omg.CosNaming.NamingContextPackage.NotFound;
import org.omg.CORBA.*;
public class NamingServer { public static void main(String
args[]) throws NotFound, CannotProceed,
org.omg.CORBA.ORBPackage.InvalidName,
org.omg.CosNaming.NamingContextPackage.InvalidName {
//initialize ORB
ORB orb = ORB.init(args, null);
//obtain reference to the naming service
org.omg.CORBA.Object objRef;
objRef = orb.resolve_initial_references(NS);
//narrow reference to a NamingContext
NamingContext ncRef; ncRef = NamingContextHelper.narrow(objRef);
. . . }
}
The ORB uses the parameters passed into init() to locate the COS Naming Service on the network. The Java IDL ORB looks for the following parameters: