Oracle® Internet Directory Administrator's Guide 10g (9.0.4) Part Number B12118-01 |
|
Directory Entries Administration, 5 of 5
A knowledge reference, also called a referral, is represented in the directory as a particular type of entry. When you create a knowledge reference entry, you associate it with the referral
object class the and extensibleObject
object class. Typically, you create knowledge reference entries at the place in the DIT where you want to establish the partition.
A knowledge reference provides users with a referral containing an LDAP URL. You enter these URLs as values for the ref
attribute. There can be multiple ref
attributes specified for any knowledge reference entry. Similarly, there can be multiple knowledge reference entries in the DIT.
See Also:
"Directory Partitioning" for an overview of knowledge references and a description of smart knowledge references and default knowledge references |
This section contains these topics:
A search result can contain regular entries along with knowledge references. When a user performs a search operation, Oracle Internet Directory looks for the knowledge reference entry within the specified scope of the search. If it finds the knowledge reference, then Oracle Internet Directory returns a referral to the client.
If a user performs an add, delete, or modify operation on an entry located below the knowledge reference entry, then Oracle Internet Directory returns the referral.
For example, suppose you want to partition the DIT based on the geographical location of the directory servers. In this example, assume that:
c=us
naming context is held locally on Server A and Server B in the United States.
c=uk
naming context is held locally on Server C and Server D in the United Kingdom.
In this case, you would configure knowledge references between these two naming contexts as follows:
c=uk
object on Server C and Server D:
dn: c=uk c: uk ref: ldap://host C:389/c=uk ref: ldap://host D:686/c=uk objectclass: top objectclass: referral objectClass: extensibleObject
c=us
object on Server A and Server B:
dn: c=us c: us ref: ldap://host A:4000/c=us ref: ldap://host B:5000/c=us objectclass: top objectclass: referral objectClass: extensibleObject
Results:
o=foo,c=uk
receives a referral.
o=foo,c=us
receives a referral.
o=foo,c=uk
on either Server A or Server B fails. Instead, Oracle Internet Directory returns a referral.
Oracle Internet Directory uses the namingcontext
attribute in the DSE to determine every naming context held locally by the server. Be sure that the namingContext
attribute correctly reflects the naming context information.
You specify default referrals by entering a value for the ref
attribute in the DSE entry. If the ref
attribute is not in the DSE entry, then no default referral is returned.
When configuring a default referral, do not specify the DN in the LDAP URL.
For example, suppose that the DSE entry on Server A contains the following namingContext
value:
namingcontext: c=us
Further, suppose that the default referral is:
Ref: ldap://host PQR:389
Now, suppose that a user enters an operation on Server A that has a base DN in the naming context c=canada
, for example:
ou=marketing,o=foo,c=canada
This user would receive a referral to the host PQR. This is because Server A does not hold the c=canada
base DN, and the namingcontext
attribute in its DSE does not hold the value c=canada
.
See Also:
"Knowledge References and Referrals" for a conceptual discussion of knowledge references |
Referral caching is the process of storing referral information so that it can be easily accessed again and again. Suppose that a client queries Server A, which returns a referral to Server B. The client chases this referral and contacts Server B which performs the operation and returns the results to the client. Without referral caching, the next time the client makes the same query to Server A, the entire procedure is repeated, an unnecessary consumption of time and system resources.
However, if the referral information can be cached, then, in each subsequent query, the referral information can be obtained from cache and Server B can be contacted directly. This speeds up the operation.
Client-side referral caching enables each client to cache this referral information and use it to speed up of referral processing.
Referral entries are stored in a configuration file on the client. When a client establishes a session, it reads the referral information from this configuration file and stores them in a cache. This cache remains static, with no further updates being added during the session. From this point on, for every operation, the client looks up referral information in the cache.
The directory administrator prepares this configuration file for clients to use.
The configuration file consists of one or more referral sets. Each referral set consists of:
Each referral entry consists of a sequence of lines, each of which corresponds to one referral URL. The line separator is CR LF or LF.
ref_file=ref_file_content ref_file_content=1*(referral_set) referral_set=hostname SEP ref_entry_set SEP ref_entry_set=ref_entry *(SEP ref_entry) ref_entry=1*(referralurl SEP) SEP=CR LF / LF CR=0x0D LF=0x0A
For example, consider two referral entries in a directory server running on host serverX:
dn: dc=acme, dc=com ref: ldap://serverA:389/dc=acme, dc=com ref: ldap://serverB:389/dc=acme, dc=com dn: dc=oracle, dc=com ref: ldap://serverC:389/dc=oracle, dc=com ref: ldap://serverD:389/dc=oracle, dc=com
Consider the following referral entry in a directory server running on host serverY:-
dn: dc=fiction, dc=com ref: ldap://serverE:389/dc=fiction, dc=com
The corresponding referral.ora
file looks like this:
ServerX ldap://serverA:389/dc=acme, dc=com ldap://serverB:389/dc=acme, dc=com ldap://serverC:389/dc=oracle, dc=com ldap://serverD:389/dc=oracle, dc=com ServerY ldap://serverE:389/dc=fiction, dc=com
|
![]() Copyright © 1999, 2003 Oracle Corporation. All Rights Reserved. |
|