John Aguayo

Introduction

The CORBA 2.x specifications for a Naming Service define a mechanism that allows applications to locate and obtain references to objects (or services). Given a reference to an initial naming context and a name, an application would be able to traverse through the naming contexts until they found the object (or service) they were looking for. As mentioned by OMG, being able to obtain object references is a cornerstone of CORBA. The Naming Service provides a way of publishing objects in a central location by binding names (which are sequences of naming contexts) to objects. What is achieved is a tree like hierarchy similar to a filesystem where there are a series of directories and files. A user who is given a full path to a file and wished to find that file would traverse the directories until they reached the file they were looking for. Similarly an application given an initial naming context and a name (which is defined as a sequence of naming contexts) would traverse the naming contexts until they reach the final naming context which would be the reference to the object they were looking for.

The specifications for the service was flexible since it didn't place too many restrictions on how an implementation built the Naming Service nor did it place too many restrictions on how a client might traverse a Naming Service. It also was able to define a set of structures representing names that were bound to object references.

In time, people started to notice that there was not a uniform way that naming service providers and users were utilizing the naming server. Service implementers and users were establishing their own conventions. Enhancements to the naming service was identified that the OMG felt would increase "interoperability" and portability of applications that use the service. Hence an RFP for an Interoperable Naming Service was created.

The RFP was seeking proposals that would address issues such as the specification of a name string syntax, a standard way for clients to "bootstrap" an initial naming context, and additional support for URL based names.

The purpose of this document is to address the enhancements and modifications in the Interoperable Naming Service specification and demonstrate how they might affect the implementation and use of the Naming Service mechanism.

RFP

The RFP defined a set of mandatory requirements that must be met. The requirements include the following:

• Submissions shall clarify the semantics of the Id and Kind fields in NameComponents with respect to identity comparisons.

• Submissions shall specify interfaces and mechanisms to enable independently developed CORBA applications (that may also use different ORB implementations) to initialize in such a way that after initialization they share a common, initial naming context.

• Submissions shall define the concept of a stringified name and specify how that concept is to be used interoperably by CORBA applications.

• Submissions shall specify a relationship between CosNaming::Names and Uniform Resource Locators (URLs) that enables CORBA applications to use URLs in naming the parts of a distributed application.

The participants involved in creating the proposal were

1. Syntax definition for stringified names


The RFP stated that one of it's mandatory requirements was a definition of the concept of a stringified name as well as how it was to be used. With the CORBA 2.x specification, once an initial naming context was obtained, the application would need to build a Name object (which is just a typedef'd sequence of NameComponent) and use the NamingContext methods to bind, or resolve, an object or other naming context.
As defined in the CosNaming module, the Name object is really just a sequence of NameComponent structures. Each structure had an id and a kind field. The Name object would be passed to one of the NamingContext methods
 

Bind(in Name, in Object)
Rebind(in Name, in Object)
Bind_context(in Name, in NamingContext)
Rebind_context(in Name, in NamingContext)
Resolve (in Name)


For example, if an application wanted to resolve a Name it might have the following piece of code
 

// create the Name object
NameComponent name[] = {
new NameComponent("path", ""),
new NameComponent("sub-path", "")
};

//resolve the path
org.omg.CORBA.Object ref = ncRef.resolve(name);
SimpleObject obj = SimpleObjectHelper.narrow(ref);
 

Notice how the NameComponent object is a sequence of other NameComponent objects.
The resolve method would search for a Binding structure whose Name field matched the Name field sent as an argument to the resolve method.
Looking at the structure of a Name, it is clear that the Name is similar to how a directory structure might be defined. For example, a path to object d could be defined as "/a/b/c/d" or similarly as the sequence of NameComponents
  
NameComponent name[] = {
new NameComponent("a", ""),
new NameComponent("b", ""),
new NameComponent("c", ""),
new NameComponent("d", "")}
 
The former format referred to as a stringified format is much easier to read, and much easier to deal with for other I/O purposes such as serialization.
To be able to represent a Name in stringified format, a well defined syntax was required.
The syntax was defined as follows:
The "/" character would separate NameComponents in the stringified format.
The "." character would separate the id and kind field in the stringified format.
The "\" character would act as an escape character in case a NameComponent had a "/" or "." in it's id field.
Given a stringified name, the writers decided that to extend the NamingContext IDL interface to include methods that will allow a client to convert a string to a Name (to_name) and a name to a string (to_string).
Given these functions, a client could just take a stringified name and pass it as an argument to the to_name method. If the name follows the syntax defined, what is returned would be the Name version of the string.
The following is the extended interface added to the CosNaming module to provide the string to name to string conversion.

 interface NamingContextExt: NamingContext {
 
typedef string StringName;
typedef string Address;
typedef string URLString;

StringName to_string(in Name n)

raises(InvalidName);


Name to_name(in StringName sn)

raises(InvalidName);


exception InvalidAddress {};

URLString to_url(in Address addr, in StringName sn)

raises(InvalidAddress, InvalidName);


Object resolve_str(in StringName n)

raises(NotFound, CannotProceed, InvalidName, AlreadyBound);
};
 
2. Initial Naming Context configuration


One of the mandatory requirements of the RFP was that a specification should state mechanisms and interfaces defining a common way for CORBA applications to obtain an initial naming context. When a CORBA application is started, before an object can be resolved, an initial naming context must be obtained. This naming context is the starting point for an application when it attempts to resolve a name referring to an object. Since there is no specification on how an application goes about obtaining an initial naming context, different vendors have implemented this different ways. 
For example, with the JAVA IDL, an initial naming context for the Naming Service might be obtained in one of two ways.
One way is by using the two command line arguments, -ORBInitialHost <host_name> and -ORBInitialPort <port>, as follows
 

C:\java anApp -ORBInitialHost shrike.depaul.edu -ORBInitialPort 2345


When the application is executed, one of the first lines of code is usually


org.omg.CORBA.ORB orb = ORB.init(args, null);


This call initializes the ORB with arguments passed from the command line. The arguments, -ORBInitialHost and -ORBInitialPort, specify the host and port where the COS Naming Service is located.

Now with a call to the ORB method resolve_initial_references( ), the application can obtain a reference to the initial naming context. The following code demonstrates how this is done.
 

//obtain reference to the naming service
org.omg.CORBA.Object objRef;
objRef = orb.resolve_initial_references("NameService");

//narrow reference to a NamingContext
NamingContext ncRef;
ncRef = NamingContextHelper.narrow(objRef);


This approach, however, is proprietary to the JAVA IDL.

A more flexible approach, suggested by Andy Krumel, in his article to JavaWorld was to use the published IOR of the Naming Service. He suggests that the IOR be passed as an argument in the command line, and the argument then be used in an ORB method call string_to_object( ), to obtain a reference to the initial naming context. This is demonstrated in the following piece of code
 

//initialize the ORB
org.omg.CORBA.ORB orb = ORB.init(args, null);

org.omg.CORBA.Object ref;
NamingContext ncRef;

//get naming context reference using IOR
String ior = args[0];
ref = orb.string_to_object(ior);

//narrow reference to a NamingContext
ncRef = NamingContextHelper.narrow(ref);


With Andy's approach, the client only need the IOR in order to obtain a reference to the initial naming context.

The writers of the specification took an approach, which is a combination of the two.

The writers specified two command line arguments, -ORBInitRef and -ORBDefaultInitRef, which can be passed to the ORB.init( ) method.

The format of the -ORBInitRef argument is
 

-ORBInitRef <ObjectID>=<ObjectURL>


where <ObjectID> represents the id of a service defined in the CORBA specification such as the NameService. The definition of <ObjectURL> is any URL scheme supported by the ORB method string_to_object( ). This includes the iioploc and iiopname URL schemes defined in the new specification.

Now, if the application were started with
 

C:\java anApp -ORBInitRef NameService=IOR:...


Or
 

C:\java anApp -ORBInitRef NameService=iioploc:...


The line of code
 

objRef = orb.resolve_initial_references("NameService");


would return a reference to the initial naming context for the Naming Service based on the command line argument.

The format of the -ORBDefaultInitRef argument is
 

-ORBInitRef <ObjectURL>


The definition of <ObjectURL> is any URL scheme supported by the ORB method string_to_object( ). This command line argument assists in the resolution of an initial reference that may not have been specified with the -ORBInitRef argument.

For example, if the application were started with
 

C:\java anApp -ORBInitRef NameService=IOR:... -ORBDefaultInitRef iioploc:...


If the application had the following line of code,
 

objRef = orb.resolve_initial_references("OtherService");


The application would use the URL associated with the ORBDefaultInitRef argument to attempt to resolve the name.

The specification went on to define the order that the call to resolve_initial_references would attempt to resolve a given name. The order would use the value of the ORBInitRef argument, if possible, followed by the ORBDefaultInitRef argument and finally if not resolved with those two URLs, the call would use any pre-configured ORB settings.
 

3. URL Names


The RFP required that proposals specify how an application might utilize URLs as well as specify the relationship between URLs and Names. The specification defined two URL formats, iioploc and iiopname, which are very similar to the ftp and http formats.

The iioploc URL is similar to the IOR (which is also a valid URL). The iioploc URL specifies the address where a CORBA service can be found.

The iiopname URL is similar to the iioploc URL but it also a stringified name that identifies a binding in a naming context.

The BNF for iiopname as defined in the proposal is
 

<iiopname> = "iiopname://"[<addr_list>]["/"<string_name>]

<addr_list> = [<address> ","]* <address>

<address> = [<version> <host> [":" <port>]]

<host> = DNS Style Host Name | ip_address

<version> = <major> "." <minor> "@" | empty_string

<port> = number

<major> = number

<minor> = number

<string_name>= stringified Name | empty_string

1. Defining id and kind attributes for CosName comparison


The Name type defined in the CosNaming module consists of a sequence of NameComponent structures. When a client application needs to obtain a reference to an object given an instance of Name (a process known as resolving), the application would need to build the Name sequence, and call the resolve( ) method of the object referencing the naming server object.

The following piece of code shows how this works
 

// create the Name object
NameComponent name[] = {
new NameComponent("path", ""),
new NameComponent("sub-path", "")
};

//resolve the path
org.omg.CORBA.Object ref = ncRef.resolve(name);
SimpleObject obj = SimpleObjectHelper.narrow(ref);


The NameComponent structure has two fields, the id field and the kind field. When attempting to resolve the sequence of NameComponent structures, a product implementing a CORBA ORB would need to compare two NameComponent structures for equality. The problem is that there is no specifications defining what made two NameComponent structures equal. The result of having no specifications was that different vendors had different implementation of equality.

The simple resolution to this was to define two NameComponents being equal if both the id and kind fields are equal.
 

2. Other Enhancements


The following are enhancements that addressed open issues in the OMG issues database. The writers felt that addressing these issues would help increase the interoperability of the Naming Service
 

• The semantics of the BindingIterator operations were defined clarified. This included defining the values returned from the operations, what values are acceptable for parameters and when exceptions should be thrown.
  
  
• A clearer definition of the effects of the methods calls NamingContext.list(0, BindingList, BindingIterator) and BindingIterator(0, BindingList). The former method call will indicate that all bindings are to be returned via an iterator. The latter method call will raise an exception.
  
  
• A clearer definition of when a BindingIterator can return fewer bindings than requested was specified. The next_n or next_one method calls will return n, or 1, binding respectively, so long as there are still bindings to retrieve.
  
  
• A BindingIterator must be destroyed explicitly.
  
  
• Define semantics of NotFound.why. The why attribute of the NotFound exception was defined as type NotFoundReason which is an enum with values being missing_node, not_context, or not_object.
  
  
• The Names library was removed from the specification. The writers specified that the library did not hide the representation of names as the original specification touted it would. It required functionality that could only be implemented on the client side and hence would need to be ported to different combinations of operating systems, language bindings, compiler versions, and ORB versions.
  
  
• The specification states that characters of size greater than 8 bits will not be supported. According to the writers of the specification, they did not see a way of making the new submission upwardly compatible with the existing Naming Service if names containing wide characters (those with size greater than 8 bits) were allowed. Since upward compatibility was a requirement and no vendors were yet supporting wide characters, the new specification does not support wide characters.

Any host with a CORBA ORB has the ability to publish or use objects through the use of the CORBA Naming Service. The enhancements in the Interoperable Naming Service specification will ease the ability of hosts to locate objects through such mechanisms as stringified names and new URL schemes. More importantly, the new specifications will reduce the amount of parity between ORB vendors by adding clearer definition to some parts of the CORBA 2.x specifications.

References

Chapter 3: Naming Service Specification, Object Management Group, 1995

Locating CORBA Objects Using JAVA IDL, JavaWorld, 02/1999, Andy Krumel

IIOP Specification: A Closer Look, UNIX Review, Gabriel Minton, 1997

Interoperable Naming Service, Object Management Group, BEA Systems, Inc., Cooperative Research Centre for Distributed Systems Technology (DSTC Pty Ltd), Inprise Corporation, IONA Technologies, PLC, 1998

RFP/orbos/97-12-20, Object Management Group, 1997