Go to the previous, next section.
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.
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.
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.
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.
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()-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".
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.