1.8 NDS Architecture
The DS agent within an NDS server processes requests from three types of clients. Two, the NDAP and LDAP clients, have similar functionality and have full access to the directory, its entries, schema, operations, and background processes. The third client, the bindery client, has restricted access and must go through a bindery emulator which makes the directory appear as a flat bindery database and hides all functionality that isn't available in the NetWare 3.x bindery. See Bindery Services for more information about bindery emulation.
The DS agent also communicates with other NDS servers. The agent establishes a client connection with another NDS server and uses the connection to read, write, and search entry information, to perform partition operations, and to synchronize data. The following figure illustrates these communication paths.
Figure 1-3 NDS Communcation Paths
1.8.1 LDAP Clients and Applications
LDAP clients and applications currently interface with NDS through the Novell LDAP server. The LDAP server communicates directly with the DS agent on its server as well as with DS agents on other NDS servers. The client determines whether NDS returns referrals or uses referrals to traverse the tree and go remote to find the information on other NDS servers.
Since LDAP clients and applications do not require Novell client software, the LDAP application is responsible for establishing a connection and authenticating to the NDS server. It is also responsible for ensuring platform dependencies are met. For example, an LDAP application that uses Java and runs on a client workstation must have a JVM installed. An LDAP JNDI application must have a Java service provider installed.
1.8.2 NDAP Clients and Applications
NDAP clients and applications require Novell client software which includes support for various languages (C/C++, Java, and JNDI) and includes a JVM and a Java service provider. Scripting components have been built on top of these languages to allow additional methods for NDS access.
The client software establishes and manages the authentication to the NDS tree. It formulates the application's request into an NDAP request that is sent to the DS agent. The application can use the connections established by the client software or it can establish its own connections.
1.8.3 DS Agents
DS agents are responsible for managing the information stored in the NDS database and coordinating distributed operations with other servers. The agents manage all NDS requests, including the following:
- Security (authentication and access control)
- Entry management (add, delete, modify, search, read)
- Partition operations (split, join, move)
- Replica operations (add, delete, change type)
- Replica and schema synchronization
- Schema management (read and write)
1.8.4 Directory and Schema Database
The NDS database contains two main types of information: directory and schema. The directory contains entries with their attributes and values. Novell applications usually refer to entries as objects and attributes as properties. For more information on how NDS organizes, uses, and allows access to this information, see eDirectory Objects.
The schema portion of the database contains the object class definitions and the attribute definitions. These definitions control the information that can be added to the directory. For example, the schema contains a definition for a User object. This definition determines where in the NDS tree a user entry can be located, what the user entry can be named, and what attributes must have values before a user entry can be created.
1.8.5 Background Processes
The DS agent communicates with the background processes that keep the NDS database synchronized with other NDS servers and purged of obsolete data. These processes run without user intervention, although some allow for limited user management. For more information about the processes, see Section 4.7, Background Processes. For information on commands for managing the processes, see Directory Services Trace Utilities.
1.8.6 OS Resources
The NDS server accesses operating system resources, such as disk space and memory, through a primitive layer interface. This layer isolates this functionality so that NDS can be implemented on multiple operating systems such as NetWare, NT, and Solaris.