Using Unique Server Entry Names to Identify Individual Servers and Objects
We know that servers store their binding information in CDS where clients can find it. But so far, we've been treating CDS like a black box. If a DCE cell consisted of just a few servers or objects and a handful of users, CDS could be as simple as a data file accessible to both servers and clients. Finding unique names for objects would probably not pose a big problem. And you could probably even devise some effective scheme for protecting objects from unauthorized use. But DCE cells can include many hundreds or even thousands of objects. Large cells will likely contain many similar or even identical servers which need convenient and effective ways to offer their services to clients.
DCE CDS answers this need by providing a hierarchical (tree-structured) name system that servers use to store binding information. CDS acts much like a hierarchical file system of directories that stores names and other information instead of files. You can build on its hierarchical structure, imposing directory names that can correspond to your company's organizational structure.
Servers have CDS names like /.:/admin/finance/payroll/check_writer. When this check_writer server exports its server entry name to CDS, CDS stores it in a directory named /.:/admin/finance/payroll. Consequently, clients won't confuse this check_writer with another check_writer named /.:/admin/finance/accts_payable/check_writer. Thus, unique server entry names fill a critical administration need, providing a way to access and control individual servers.
Part 4 of this guide provides more information about CDS and the structure and uses of CDS names. For our current purposes, it's enough to know how and why CDS directory names help make potentially identical server entries unique.
While servers themselves often manage exporting and removing their names and binding information from CDS, sometimes administrators need to manually add, change, or remove binding information. For instance, when a server host machine crashes unexpectedly and stays offline for a long time, its resident servers cannot remove their entry names and binding information from CDS. Clients can waste time looking for these phantom servers. The dcecp program provides the rpcentry object that you can use to manage server entry names and their binding information in CDS.
Before we get to the actual management tasks, let's examine a server entry to see exactly what it is we'll be managing. The following figure shows possible information in a server entry.
Possible Information in a Server Entry
The top part of the figure contains bindings. Each binding consists of an interface UUID/version pair (called an interface identifier) and a binding. The interface identifier identifies an interface offered by the server and its binding information indicates the host address and network transport to use to access that interface. The following example of a binding (shown in dcecp syntax) indicates the server is on the host with internet address 120.101.13.157 and is available using the User Datagram Protocol (UDP).
{nacdg_ip_udg 120.101.13.157}
When an interface identifier is available over a several transports, the server entry contains bindings (one binding for each transport). Servers can offer more than one interface. Multiple interfaces can be available through a single endpoint. That is, different interfaces can have the same bindings.
The lower part of the figure contains object UUIDs. Object UUIDs offer additional information to clients; they identify specific objects or resources managed by the server. For instance, one print server offers printers on floor 2 while another print server offers printers on floor 1. In this case, object UUIDs let clients select printers on the appropriate floor. In other words, object UUIDs help clients distinguish from among otherwise identical services.
Although application servers can manage their own server entries in CDS, you may find it more convenient (and more straightforward) to manually add, remove, or change information in a server entry. There are four methods for managing server entries in CDS:
· Server entry names can be hard coded into an application. You can change server entry information in the source code but you need to recompile and rerun the application before the entry names take effect.
· Server entry names can be stored as the entryname attribute of the server's configuration information (using the server object) where it's accessible to the application. This is more convenient than recompiling but, more importantly, this method places the server's entry name in a standard (platform-independent) place where administrators can see it too. You might need to restart an application to use this method, however.
· Server entry names can be passed to an application through environment variables or arguments. While these are effective methods and they are more convenient than recompiling, they are not platform-independent. This means you might need different approaches on different operating systems.
· Server entry names can be directly managed in CDS by using the DCE control program's rpcserver object. This manual method does not require recompiling or restarting applications.
The next topics discuss how to use the rpcserver object to manually manage server entries in CDS.
More:
Creating a Server Entry in CDS
Deleting a Server Entry from CDS
Exporting Binding Information to a Server Entry in CDS
Importing Binding Information from a Server Entry in CDS
Viewing Information in a Server Entry
Removing Binding Information from a Server Entry in CDS