Go to the previous, next section.

Binding Names in ILU

Introduction

This chapter explains some of the issues around binding names to objects and services, and the various mechanisms that ILU provides to deal with them.

ILU Simple Binding

ILU includes a simple binding/naming facility. It allows a module to publish an object, so that another module can import that object knowing only its object ID (as defined in section ILU Concepts). The interface to this facility is deliberately quite simple; one reason is to allow various implementations.

The interface consists of three operations: Publish, Withdraw, and Lookup. Publish takes one argument, an ILU object. Publish returns a string that is needed to successfully invoke Withdraw. Withdraw undoes the effects of Publish, and takes two arguments: (1) the object in question, and (2) the string returned from Publish. In some langauge mappings, the string is not explicitly passed, but conveyed in the language mapping's representation of ILU objects. Lookup takes two arguments: an object ID and a type the identified object should have. If the object with that ID is currently being published, and has the given type (among others), Lookup returns that object.

The implementation shipped with this release of ILU can use either an ILU service, or a shared filesystem directory, to store information on the currently published objects. This choice must be specified at system configuration time. If the shared filesystem approach is used, this directory must be available by the same name, on all machines which wish to interoperate. The way in which clients interact with binding is the same, regardless of which approach is selected.

Listing the Registered Objects

The simple program ilusbls will list the currently registered objects. It may be invoked with an argument, in which case only those objects with string binding handles containing the argument as a substring will be listed.

Using Shared Files for Simple Binding

If simple binding is to be done with shared files, a default directory is compiled into the ILU library. This directory may be explicitly specified at system configuration time with the --with-binding-dir=DIRECTORY switch to configure. (The compiled-in setting may also be overridden at run time, by setting the environment variable ILU_BINDING_DIRECTORY to a different directory.) ILU creates a file in this directory for each published object. The name of the file is an 8-digit hex string, formed by taking the CRC-32 hash of the server ID and instance handle of the object. The file contains the string binding handle of the object and a random string, which serves as the `proof' that has to be provided when withdrawing a registration. Note that when using the shared file approach, the protection state of the directory must be such that programs calling Publish can remove files and create new files, and programs calling Lookup must be able to read files in the directory.

Using an ILU Service for Simple Binding

If an ILU service is used, the situation is a bit more flexible. The idea is that a program called ilusb is run on some machine, and exports the binding service via a specified port. All clients have compiled-in knowledge as to which machine and port the binding service is running on, and they contact the service to perform Publish, Withdraw, and Lookup calls. Each binding service is given a name, called a binding realm, which is the name of the `space' for which it provides simple binding services. There may therefore be many instances of the ilusb server running, even on a single machine, each one serving a different binding realm. It is often useful to establish multiple binding realms for different purposes. For instance, one might be used for everyday registration of services, another for testing, still another for experimenting.

To start the binding service, run the program ILUHOME/bin/ilusb. It takes the following options:

By default, ILU programs use the compiled-in binding realm, host, and port. However, they can be directed to use a different combination of these three, by defining the environment variable ILU_BINDING_SERVICE to a string of the form "REALM:HOST:PORT", before running the program. If you want only to override one or two of the compiled-in defaults, use a string with empty fields for the other parts. For example, if you just wanted to redirect to a particular host, you could use a string of the form ":foo.bar.company.com:", with empty strings for REALM and PORT.

The program ilusbls will list all the currently registered objects. It takes an optional string argument. If the argument is specified, only objects which have that string in their string binding handles will be listed.

CORBA CosNaming

Another rather different notion of binding is covered by the CORBA standard `COS Naming' service. An implementation of this service is installed with ILU if the configuration options include support for the C programming language, the OMG IDL interface definition language, and the CORBA IIOP wire protocol. The interface to the service is defined in `ILUHOME/interfaces/CosNaming.idl'.

To start the binding service, run the program ILUHOME/bin/ILUCosNaming. It takes the following options:

In general, the user shouldn't have to specify the hostname, server ID, instance handle, or filename; the defaults work pretty well. It is useful to specify the port in most applications, just so that the service always has the same string binding handle, which will be
ilu:SID/IH;IDL%3ACosNaming%2FNamingContext%3A1.0;iiop_1_0_1@tcp_HOST_PORT where SID, IH, HOST, and PORT are the values for the server ID, instance handle, hostname, and port, as given above.

You should look at any CORBA book, or the
COS Naming service specification itself, for more information on how to use the naming service with applications. Note that the ILU implementation does not include the client-side `Names Library' described in the specification. Applications are expected to use the service functionality directly.

Go to the previous, next section.