ACE+TAO Opensource Programming Notes/Dealing with IORs

As described earlier, the raw IOR string for tying together client and server isn't the preferred method to getting the two sides to talk together. In a production environment, the usual method is to use a naming service. This serves both as a way to advertise a location for a service, and as a method to keep the effective IOR of the service constant. You might have noticed, had you played with the previous server example more than once that the IOR string tended to change. With this method, you can ensure both consistency and readability.

The infrastructure used by CORBA programs to perform such address registration and lookups is the naming service. For TAO, the naming service is started with several command line args. In the examples below, the arg "-ORBEndPoint" is used to define where the service will listen, and the arg "-ORBDaemon" is designed to force the daemon to actually act like a daemon. Oddly enough, none of the services (daemons) you will be compiling with TAO will actually act like daemons, unless you use this optional arg.

The endpoint is critical to running any TAO service or compiled client/server app. If you don't supply one, the default endpoint is the multicast endpoint. This default endpoint is described as being useful for apps where performance isn't an issue, or for testing. That being said, this author couldn't get the multicast IIOP endpoint to work on a stock Linux FC4 system, even though the Linux system swore that multicasting was up and running. I was able to verify the bug by running the multicast test app under the ACE framework test directory. To ensure that anyone reading this is able to get something up and running, we will therefore set up a client with the explicitly defined endpoint of "localhost".

There are two basic forms of this endpoint, there is the service advertising its services, and the client trying to find a service. To make this discussion intuitive, we will assume that in each example, a naming service server is running and reachable from your test box. To get the naming service started, try the following:

Naming_Service -ORBEndPoint iiop://localhost:12345 -ORBDaemon

This should set up your naming service on port 12345 on the localhost interface. To test that this is up and working, try the following:

nslist -ORBInitRef NameService=corbaloc:iiop:localhost:12345/NameService

This should then produce the following output:

Naming Service:
---------

This shows that your naming service is up and running , but reporting no services yet. To see what a service looks like, try the following command to start the event service (which we will be using in later examples):

CosEvent_Service -ORBInitRef NameService=corbaloc:iiop:localhost:12345/NameService -ORBDaemon

Now, when you run nslist again, you will see the following output:

Naming Service:
---------
  CosEventService: object reference:   Protocol: IIOP,   Endpoint: 10.0.0.53:32802

Finally, we have a working set of servers we have connected together with IIOP endpoints. When you connect your clients and servers together, you will be using the same process... start the naming server, possibly the event service (or others) and then start in with your clients and servers. For linux, the people associated with the ACE+TAO project have provided RPM packages with script files designed to interract with linux's boot facilities which will start the naming service (and the others) automatically.