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 server will use a randomly assigned free port, and the CORBA IOR for the service will differ
from invocation to invocation. If you want the service to have an unchanging CORBA IOR or ILU SBH,
this must be specified.
-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,
the default used is "CosNaming_HOSTNAME", where HOSTNAME is the hostname being used.
-ih IH -- this allows specification of an instance handle for the root object
exported by the naming service. This defaults to "root".
-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 its CORBA IOR 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.
-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.
ilu:SID/IH;IDL%3Aomg.org%2FCosNaming%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.