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:

- `-r REALM-NAME` -- this allows specification of the REALM-NAME which the server will serve. The default is the compiled-in realm name.
- `-h IP-ADDRESS` -- this allows overriding the compiled in IP address for the machine. This switch is mainly for multi-ported machines (machines which have two or more different IP addresses).
- `-p PORT` -- this allows overriding the compiled in PORT specification. This is the port on which the server listens for connections.
- `-f FILENAME` -- this allows you to specify the name of a file in which the server will store a backup of the various registrations currently active. If the server is restarted, and this file already exists, the server will read this file, and use the registrations in it as the current set of registrations. This file should be in a directory which can be read and written by the user identity under which the `ilusb` program is running. The default is a file called ``/tmp/ILUSimpleBindingService.REALM-NAME'`.
- `-s` -- this option enables `protected' operation. This prevents active registrations from being overridden; `Withdraw` must be called first, to remove the current registration, before a new registration for the same object can be made. This is useful in an environment which only wants to permit certain users to change certain registrations. However, without secure communications, this operation is not truly secure, and enabling it is often clumsy for casual use of the simple binding service. The default is unprotected operation.

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:

- `-p PORT` -- this allows specification of the port on which the server will listen for connection requests. If this is not specified, the default port will be 9999. If you'd like the service to pick a free port, specify 0 for the value of PORT. Note that if you do specify 0, the IOR of the service will change from invocation to invocation, as different port numbers are used.
- `-h HOSTNAME` -- this allows overriding the default hostname for the machine. This switch is mainly for multi-ported machines (machines which have two or more different IP addresses). The default hostname is whatever is returned by the ``gethostname()`` system call on your machine.
- `-sid SID` -- this allows specification of a server ID for the root object exported by the naming service, and all subsequent naming contexts created in that server. If none is specified, but an instance handle is specified, the default used is `"CosNaming_HOSTNAME"`, where HOSTNAME is the hostname being used. This option is not generally useful.
- `-ih IH` -- this allows specification of an instance handle for the root NamingContext exported by the naming service. If none is specified, but a serverID is specified, this defaults to `"root"`. If neither server ID nor instance handle is specified, the root NamingContext is exported with an object key, instead. This option is not generally useful.
- `-f FILENAME` -- this allows you to specify the name of a file in which the server will store a backup of the various registrations currently active. If the server is restarted, and this file already exists, the server will read this file, and use the registrations in it as the current set of registrations. This file should be in a directory which can be read and written by the user identity under which the `ILUCosNaming` program is running. The default is a file called ``/tmp/ILUCosNaming.SID'`, where SID is the server ID specified or defaulted to for the program.
- `-ior` -- if this option is specified, the service will write the CORBA IOR of its root `NamingContext` to the standard output after it has successfully initialized. This is sometimes useful when this service is being used with a non-ILU CORBA ORB.
- `-ior_to_file FILENAME` -- if this option is specified, the service will write the CORBA IOR of its root `NamingContext` to the file with the specified FILENAME after it has successfully initialized. This is sometimes useful when this service is being used with a non-ILU CORBA ORB.
- `-publish` -- if this option is specified, the service will register its root `NamingContext` with ILU's simple binding.
- `-sid_and_ih_from_IOR STRINGIFIED-IOR` -- it is sometimes useful to use the `ILUCosNaming' program to mimic the name service provided by another ORB. In particular, this means that the root object should have the same server ID and instance handle provided by that other service. To accomplish this, you can start `ILUCosNaming` with the stringified IOR for that other service, and it will use the server ID and instance handle in that IOR for its server ID and instance handle. Note that you may also need to specify the port and hostname with the `-h` and `-p` options to exactly mimic the other service. This option is not generally useful.
- `-object_key KEY` -- will export the root NamingContext object with the object key KEY. If no value is specified, and if neither a server ID nor an instance handle is specified, will export the root NamingContext with the object key `"NameService"`.

In general, the user shouldn't have to specify the hostname, server ID, object key, 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
`iioploc://HOST:PORT/NameService`, if no other options are specified, or `ilusbh:SID/IH;IDL%3Aomg.org%2FCosNaming%2FNamingContext%3A1.0;iiop_1_0_1@tcp_HOST_PORT`, if either SID or IH are specified.

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.