Implementation Repository User's Guide

In order for a server to make use of the Implementation Repository, it must communicate with the IMR to keep it up to date on such things as the server's running status. These functions now are contained within the POA, so when a Persistent POA is used on a server that has -ORBUseIMR specified, it will communicate with an Implementation Repository, if one is available.


How is the IMR used?

The main steps for the lifetime of a server that uses the IMR are generally the following:

  1. Register name and startup commands with the IMR using tao_imr
    Example: tao_imr -ORBInitRef ImplRepoService=file://implrepo.ior add plane -c "airplane_server -i -ORBInitRef ImplRepoService=file://implrepo.ior"

    Note that the name used to register the server is the name of the POA which the objects are created in. So in this example, the airplane_server creates a POA called "plane" and activates its servants under it.
  2. Start the server once to generate an IMR-ified IOR
  3. Start clients and pass them the above IOR
  4. Clients will use the IOR, which will automatically go through the IMR
  5. The IMR will start the server if it is not already running
  6. At any time when the server is not currently in use by a client, it can be shut down using tao_imr
    Example: tao_imr -ORBInitRef ImplRepoService=file://implrepo.ior shutdown plane
  7. After the server isn't needed anymore, it can be removed from the IMR database using tao_imr
    Example: tao_imr -ORBInitRef ImplRepoService=file://implrepo.ior remove plane

So what does the server need to do?

As of TAO 1.0.9, the Implementation Repository support on the server-side has been integrated into the POA. Previously, the IR_Helper class needed to be used explicitly. Now only the "-ORBUseIMR 1" command line argument needs to be used.

There are a couple of restrictions on the server though. Only objects within a persistent POA will be supported by the IMR. Also the Implementation repository will key its entries on POA name. What this means for the server is that each server must have unique persistent POA names.


What are activation modes

Each server can have one of three different types of activation modes:


Using the tao_imr ior command

First, some background.

For the longest time, there was no way with TAO's Implementation Repository to register a server and then start using the client immediately. The server had to be started once just for the purpose of creating an IOR for the client to use. The problem was that it was very difficult to create an IOR without running the server.

It would be nice to be able to generate a valid IOR without requiring the program to be run. A valid IOR in this case requires two major things. First it requires the endpoint of the IMR. This is relatively easy to get, since it is encoded in the IMR's IOR. Second it also requires an object key. At the least, this involves both the POA hierarchy and the object name.

So if we knew the POA and object names, then we should be able to create an IOR for the server. One possibility would be to have tao_imr ask for both the POA and the object, and then create the POA hierarchy to generate an IOR. Doing the generation is this manner (letting the POA create the reference) shields us from changes in the IOR generation schemes. Since we are using the same code that the server would use, our IORs would be up to date.

It ends up there is an easier way to do this. The Interoperable Naming Service is intended to be used in situations where an IOR could be created by hand. Using the same information as above, it is not difficult to take the endpoint information from the IMR and attach the POA name. For example, let's say that we are running the IMR on ringil.ece.uci.edu at port 5000. The endpoint would be "iioploc://1.1@ringil.ece.uci.edu:5000". If we are creating an IOR for the nestea server, we'd just need to attach "/nestea_server" to the end of the endpoint. Now we have an IOR.

So what does this mean for the server?

The main issue here is that the server must be changed to support the simplified name. The code to do this is just one line:

this->orb_->_tao_add_to_IOR_table (poa_name, server_obj.in ());

This line, as taken from the nestea_server example, just uses the same poa_name as registered with the IMR and associates it with the server_obj object in the IOR table. Because the IMR will be able to handle the simplified name (if it uses the POA name scheme) then this IOR will work.

Just one more thing, each object that needs an IOR needs to be registered with the IOR table. But this raises the problem of uniqueness; they all can't have the same name. The IMR will actually only look at the name part of the simplified IOR up to the first "/". So both "iioploc://1.1@ringil:5000/nestea_server/foo" and "iioploc://1.1@ringil:5000/nestea_server/bar" will be treated by the IMR as objects in the "nestea_server" server.


Last update to this document: 2000/02/07 16:58:59

Back to Implementation Repository