field-theory.org
the blog of wolfram schroers

Using the Naming Service

The source code can be downloaded as a gzipped .tar-file.

This is the fourth and final part of the CORBA tutorial which implements a distributed object system. This example expands the previous example two and demonstrates the Naming service, a way to locate distributed objects in the network.

The source code has been developed and tested using the mico ORB on MacOS X. On other systems, the Makefile(s) may need to be adjusted properly. The files can also be downloaded on the software section of this site.

Table of contents:

Previous setup of the server
The Naming service
Running the system

Previous setup of the server

Up to now we have not bothered about the “boilerplate” initialization code at the beginning of either the client and the server. When we look a little closer we see that it consists of two parts: first, the ORB itself is initialized, then an entity labeled POA (Portable Object Adapter) is setup. The latter proceeds by using a control file called ior.dat. Essentially, ior.dat contains information like the TCP/IP address, port number etc. about the service. IOR is the abbreviation for Interoperable Object Reference, a piece of data that uniquely identifies a service in the network. It is written by the server and subsequently read by the client.

Thus, in order to connect clients to servers, the control file needs to be passed around. While this has been done in the initialization section of each program so far, we will now look into a frequently used alternative that can be used to pass around the IOR without the need of additional network services.

The Naming service

Control files limit the general applicability of an object; either one needs a distributed file system or it is necessary to pass that file around by “some other means”. For a large enterprise such a system can quickly become cumbersome. CORBA offers a solution — while the IOR is still needed to match clients and servers, it need not be passed around as a file. Instead, it can be provided by a CORBA service called Naming service. The Naming service essentially stores the IOR under a name (similar to a single-purpose distributed file system) and makes it available to all clients on the network.

The cool thing about this setup is that the Naming service is just like any CORBA service, i.e. all the infrastructure to talk to it is already in place if a valid CORBA implementation got to this point. The downside is that in order to talk to the Naming service, some way of calling it must be in place and that way should better be independent of IORs!

The way mico ORB solves this problem is by passing a human-readable URL around which contains the TCP/IP address, the port number and an ID identifying the Naming service server. This is similar to a raw IOR, but can actually be typed by a user at the command line. Once communication to the Naming service is established, a file-system-like CORBA server matches up IORs with names. Thus, any server can store its IOR under a given name and any client can retrieve it as long as it knows the name.

While the specific interface of the CORBA Naming service is beyond the scope of this introduction – good documentation can be found e.g. on CORBA explained simply – it is instructive to take a closer look at the work flow that the server server.cc implements:

  1. Initialize the ORB.
  2. Instantiate the objects you want to distribute.
  3. Connect them to the ORB.
  4. Register the IOR with the Naming service:
    1. Get the Naming service context itself.
    2. Construct the entry which identifies our object.
    3. Store the entry with the IOR in the naming service tree.
  5. Enter the CORBA event loop (which waits for and handles remote requests).

This work flow will make sure that clients can connect to the server as soon as they manage to connect to the Naming service. Hence, looking at the client client.cc, we identify the following elements:

  1. Initialize the ORB.
  2. Obtain the IOR from the Naming Service:
    1. Get the Naming service context itself.
    2. Construct the entry which identifies our object.
    3. Find the node in the naming service tree with the correct entry.
  3. Connect to the object.
  4. Use the object as usual.

The rest of the code, protocol.idl, protocol_impl.cc and protocol_impl.h stays the same. I have added the specific commands (see below) to run the server and the client on the local host to the Makefile as a reminder.

Running the system

The setup is slightly more complicated now since we need to start the server that provides the Naming service first. Unfortunately, this is vendor specific and the exact calling convention depend on the implementation used. Again, we stick with the mico ORB and use different processes on the localhost (IP: 127.0.0.1, port: 12456) to run the client and the server.

Putting everything together the command for starting both the Naming service and the Protocol server becomes:

  $ nsd -ORBIIOPAddr inet:127.0.0.1:12456 &
  $ ./server -ORBInitRef \
      NameService=corbaloc::127.0.0.1:12456/NameService

The client also needs to be notified of the Naming service in the same way as the server was:

  $ ./client -ORBInitRef \
      NameService=corbaloc::127.0.0.1:12456/NameService \
      "Hello, world."

Note that the line that initializes the ORB “consumes” the parameters leading to the initialization. Put into practice, the working example looks like this:

Using CORBA example code 4

Again, the functionality stays the same as in the previous two examples. The flexibility, however, has increased notably since all we need to do now is to make sure the network routing and firewalls are properly configured; we do not need to worry about the file ior.dat anymore.

This part concludes our example codes for CORBA. You can return to the CORBA overview to read about some of the more advanced aspects or to study further literature on the subject.