How the Global Directory Agent Works
The GDA is an intermediary between CDS clerks in the local cell and CDS servers in other cells. A CDS clerk treats the GDA like any other name server, passing it name lookup requests. However, the GDA provides the clerk with only one specific service; it looks up a cell name in the GDS or DNS namespace and returns the results to the clerk. The clerk then uses those results to contact a CDS server in the foreign cell.
A GDA must exist inside any cell that wants to communicate with other cells. It can be on the same system as a CDS server, or it can exist independently on another system. You can configure more than one GDA in a cell for increased availability and reliability. Like a CDS server, a GDA is a principal and must authenticate itself to clerks.
CDS finds a GDA by reading address information that is stored in the CDS_GDAPointers attribute associated with the cell root directory. Whenever a GDA process starts, it creates a new entry or updates an existing entry in the CDS_GDAPointers attribute. The entry contains the address of the host on which the GDA is currently running. If multiple GDAs exist in a cell, they each create and maintain their own address information in the CDS_GDAPointers attribute.
When a CDS server receives a request for a name that is not in the local cell, the server examines the CDS_GDAPointers attribute of the cell root directory to find the location of one or more GDAs. The following figure shows how a CDS clerk and CDS server interact to find a GDA.
How the CDS Clerk Finds a GDA
The following steps summarize the GDA search that is illustrated in the preceding figure:
1. On Node A, a client application passes a global name, beginning with the /... prefix, to the CDS clerk.
2. The clerk passes the lookup request to a CDS server that it knows about on Node B.
3. The server's clearinghouse contains a replica of the cell root directory, so the server reads the CDS_GDAPointers attribute and returns the address of Node C, where a GDA is running.
4. The clerk passes the lookup request to the GDA.
The following figure shows how CDS and a GDA interact to find a name in a foreign cell that is defined in DNS. Suppose the name is /.../widget.com/printsrv1, which represents a print server in the foreign cell.
How the GDA Helps CDS Find a Name
The following steps summarize the name search that is illustrated in the preceding figure:
1. The client application passes the name /.../widget.com/printsrv1 to the CDS clerk.
2. The clerk passes a lookup request to a CDS server that it knows about on Node B.
3. The server's clearinghouse contains a replica of the cell root directory, so the server looks up the CDS_GDAPointers attribute and returns the address of Node C, where a GDA is running.
4. The clerk passes the lookup request to the GDA.
5. The GDA recognizes that the name is a DNS-style name, so it assumes that the second component is a cell name that is defined in DNS. It passes that portion of the name (widget.com) to DNS. For simplicity, the figure shows only one DNS server; more than one DNS server can actually be involved in resolving a global cell name.
Note: Although this example concerns the lookup of a DNS-style name, the sequence and execution of operations is nearly identical for a GDS name or a hierarchical cell name. If the GDA recognizes that a name is a GDS-style name, it passes the name to a GDS server, rather than to a DNS server. If the GDA recognizes that a name is a hierarchical cell name, it passes it to the CDS server of the top-most cell in the hierarchy, which is registered in one of the global namespaces. The CDS server in this cell "walks down" the cell hierarchy to locate the name.
6. DNS looks up and returns to the GDA information that is associated with the widget.com cell entry. The information includes the addresses of servers that maintain replicas of the root directory of the /.../widget.com cell namespace.
7. The GDA passes the information about the foreign cell to the clerk.
8. The clerk contacts the CDS server on Node E in the foreign cell, passing it a lookup request.
9. The Node E server's clearinghouse contains a replica of the root directory, so the server looks up the entry for printsrv1 in the root and passes the requested information to the clerk on Node A. For simplicity, this example shows the clerk contacting only one server in the foreign cell. While resolving a full name, the clerk may actually receive referrals to several servers in the foreign cell.
10. The clerk passes the information to the client application that requested it.
Note that both of the previous examples (the preceding figures) represent initial lookups. The CDS clerk caches the locations of GDAs once it discovers them. The clerk also caches the addresses of servers in foreign cells that it learns about, enabling it to contact the foreign servers directly on subsequent requests for names in the same cell.
Note also that a GDA knows its own cell name and can therefore avoid contacting a global directory service to look up names in its own cell. Furthermore, the GDA can recognize whether a cell name conforms to the GDS or DNS naming syntax, and it uses that knowledge to route a lookup request to the appropriate global directory service.