The information presented here is an overview, and some points are glossed over. For full details see the text of the standard, X.500/ISO 9594. Information on implementation specifics can be found in the Isode release manual set.
Entries in the database are organized into a hierarchical tree. This tree structure is known as the DIT, short for directory information tree. At the top of the tree is a notional root beneath which is a set of country entries. Below each country there are typically a number of organizational entries, and in some cases (like that of the United States) entries of other types, such as states or provinces. An illustration of the database's tree structure is shown in Figure 3-1.
Figure 3-1. Example Directory Tree
Each entry has a naming component, called its relative distinguished name (RDN). The RDN consists of one or more distinguished attribute-value pairs from the entry. The attribute may have more values which are not relevant to the entry's RDN. For country entries the RDN of an entry is specified as being the countryName attribute; the name of the entry for Great Britain is countryName=GB, usually abbreviated to c=GB. The RDN specifies the name relative to its parent entry. The distinguished name (or DN) on the other hand specifies exactly where the entry is positioned in the DIT. The DN of an entry is the concatenation of an entry's RDN with the sequence of RDNs of all entries above it in the tree. In Figure 3-1 the DN for the entry "o=Dr. Materna GmbH" is as follows:
c=DE, o=Dr Materna GmbHThe structure and content of the directory information tree is enforced by a set of rules called the directory schema. The schema used by the EuroView project is specified in EuroView deliverable D4.1.
From a technical standpoint the advantage of using a distributed database is that the system is scaleable. The directory should work just as well with many participating organizations as it does with just a few. Also the introduction of a new server does not require reconfiguration of every other server in the system, though more of this later.
1. Determine which DSA contains the required data.
2. Request the data from that DSA.
In X.500, step 1 is the critical phase. In order to satisfy this step, each DSA contains some knowledge of other DSAs in the system. Knowledge of another DSA is referred to as a knowledge reference. A knowledge reference describes a DSA in terms of how to reach it and also what data it is responsible for. Specifically, it contains the following information:
• Type of reference.
• DSA contact point (its address).
• DSA authority, in other words the data it has access to or has further knowledge of (this is referred to as specific knowledge).
The unit of data authority in the knowledge scheme is a naming context. A naming context is a set of entries contained in a partial subtree, as well as a set of knowledge references. Each naming context can only be mastered by a single DSA, but copies can be held by other DSAs. The DSA holding the master version of a naming context is said to have administrative authority over that naming context.
In the case of a DSA holding all of the data belonging to an organization the one and only naming context held by that DSA is all of the data for that organization. The partial DIT in Figure 3-2 shows the data subtree for Dr. Materna. In the simple case described above, the whole subtree corresponds to a single naming context.
Figure 3-2. A Naming Context
The example DIT in Figure 3-1 is shown divided into a set of naming contexts in Figure 3-3.
Figure 3-3. Example DIT
A DSA must contain a minimal set of knowledge references for each of the naming contexts it has authority over:
1. Superior Reference The DSA must have a reference to a superior DSA that is 'nearer' to, and knows how to get to, the root of the directory tree. So in Figure 3-3 DSA 4 must contain a reference to either of DSA 1, 2 or 3.
2. Subordinate References The DSA must have references to all DSAs that hold naming contexts subordinate to contexts for which it has authority. So, looking at the same diagram, DSA 1 must have references to its subordinates: DSA 2 and DSA 3. Similarly DSA 2 must hold references to DSA 4 and DSA 5.
In general terms a DSA uses its superior reference when it is requested to supply data which it does not hold. Subordinate references are employed when a DSA is requested to obtain data in a subordinate context. Looking at Figure 3-3, the DSA for Spain (DSA 3) will contact its subordinate, DSA 6, for information on information held in the "o=Sema Group" subtree.
Another important form of DSA reference is the cross reference, which refers to a DSA holding data in a non-local and/or non-subordinate naming context. By holding a cross reference a DSA gains knowledge of how to directly access the data held in a naming context, without resorting to a superior reference. This has the effect of limiting the number of hops required to access that data to one.
Figure 3-4 depicts a chained operation. The operation represented is a request by a user at Dr. Materna in Germany for data in Sema Group in Spain. In this diagram the order of interactions is defined by the numbers associated with the interaction arrows. The individual requests made are:
1. Materna client DUA requests Materna DSA for data.
2. Materna DSA uses its superior reference to contact the DSA for Germany.
3. German DSA uses a subordinate reference of the root to contact Spanish DSA.
4. Spanish DSA uses a subordinate reference to contact the DSA for Sema.
5. The Sema DSA returns a request result, which is chained back through the established connections.
Figure 3-4. Chaining Mode
This example shows how the system might work. It is important to note that the number of steps taken will in fact be reduced by establishing cross references between the Materna and Sema DSAs. In this case the Materna DSA would connect to directly the Sema DSA, eliminating the need to contact the national servers.
Cross references between EuroView DSAs will be established by hand. The use of cross references in this way has the cost of reducing the scalability of the infrastructure because the number of cross references increases exponentially against the number of DSAs. This is not a problem with the EuroView infrastructure as use of this technique is likely to be reserved for the central EuroView DSAs running at the project partner sites.
The client (be it a DSA or DUA) must take note of that reference and then pass the original request to the referenced DSA.
Figure 3-5. Referral Mode
Referral is a request mode often used when a stronger level of security is required, because referral mode requires that the client connect directly with each DSA contacted. In chaining mode the data may pass through several extra DSAs.
• Fault tolerance. If one DSA is down then another may hold the required data.
• Optimization. A DSA holding replicated data may be nearer to the user.
• Access to unreachable data. Data held on a private or inaccessible network can be made available by replicating data to a more accessible DSA (e.g. a user on the Internet may not be able easily reach a DSA running on an X.25 network).
Figure 3-6. Relay DSAs
Figure 3-6 shows a relay DSA acting as a relay for access to DSA 1 (sitting on a private X.25 network). The relay advertises itself as an access point for the data actually held in DSA 1.
Figure 3-7. Transport Bridges
One of the important conclusions from the user survey was that many validation sites use one protocol for internal LAN use and another for any external connection. It is not unusual for a site to have users working on a TCP/IP local network, with X.25 used for external access. If there is a local DSA that is connected to the LAN and has external connectivity the problem goes away, as users can connect to the DSA using TCP/IP, with the DSA then making external connections using X.25. In many cases EuroView users will not employ a local DSA and will access the central service. In this situation a transport bridge can be used as an alternative. A transport bridge is a protocol gateway that uses the Isode communicatons stack to convert calls from one network protocol to another.