Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
2000-03-23
2002-07-23
Amsbury, Wayne (Department: 2171)
Data processing: database and file management or data structures
Database design
Data structure types
Reexamination Certificate
active
06424976
ABSTRACT:
BACKGROUND
This invention relates generally to directory syntaxes and, more particularly, to a forward compatibility syntax for facilitating forward, as well as backward, compatibility between servers.
Personal computers or workstations may be linked in a computer network to facilitate the sharing of data, applications, files, and other resources. One common type of computer network is a client/server network, where some computers act as servers and others as clients. In a client/server network, the sharing of resources is accomplished through the use of one or more servers. Each server includes a processing unit that is dedicated to managing centralized resources and to sharing these resources with other servers and/or various personal computers and workstations, which are known as the “clients” of the server.
Directories and directory services are often provided to enable an environment for a digital entry of a particular resource. One example of a directory service is Novell Directory Services (“NDS”), developed by Novell, Inc. of Provo, Utah. NDS provides a logical tree-structure view of all resources on the network so that clients can access them without knowing where they are physically located. The entry of a resource is only available by directly accessing the directory.
Novell Directory Services (“NDS”) is an object-oriented implementation of directory services that enables a user to build a model of a network using sophisticated naming schemes and a powerful distributed database. NDS provides everyone on the network with access to all network resources, regardless of whether the users or the resources are located. NDS may be divided into multiple, cooperating pieces, but it performs as a single, coherent information system.
In a directory, a syntax is an intrinsic type. In any distributed directory, such as NDS, syntaxes are difficult to add or change because there is almost always a mixture of older and newer versions of the directory on the various servers. The older versions do not understand the added or changed syntax while the newer ones do. This presents a serious problem in the context of replication because it results in inconsistent replicas between older and newer versions of the directory and even between the newer, but different, versions thereof.
One solution is to provide the servers having the older versions of the directory (“older servers”) with the ability to handle a “blob”; that is, a chunk of data that is not understood by an older version of the directory but that can be replicated as a blob to both older servers and servers having newer versions of the directory (“newer servers”). Most directories have referential integrity with respect to the names of objects, meaning that if an object is renamed, or even deleted, all references to that object will be updated and react accordingly. As will be explained in greater detail below, referential integrity can present problems in connection with the use of blobs.
Currently, issues of backward compatibility in connection with directory syntaxes are handled on a case-by-case basis. For example, as previously suggested, if a new syntax consists solely of data, it is easy to pass between older and newer servers because nothing is going to act on it to change it (i.e., it presents no issues with respect to referential integrity), so the syntax can be handled as a blob. A problem is presented, however, if the new syntax includes a value that will change, such as the name of an object. In particular, when an object is renamed, every reference to the object has to be changed to reflect the new name. This is easy when the server holding a copy of the new syntax supports the new syntax and therefore understands which part of it is the name. In contrast, when the server holding the copy of the syntax is an older server that does not support the new syntax, it will not understand that part of it is a name. In the latter situation, when the name that forms a portion of the new syntax is updated, the system will function as if all instances of the name have been updated and when the syntax stored on the older server is sent to a server that supports the new syntax, that server will assume the name has been updated, which it has not. Clearly, this is a problem.
The following illustration highlights the problem. Consider a group object G with two member attributes referring to objects A and B. If A is renamed to C, every server holding a copy of G needs to be informed of the name change so that it can update its member list to show C instead of A. Special tags are kept on object A/C until the system is sure that all objects referring to that object have been informed of the name change. Now suppose that the two member attributes of G are not member attributes, but are some new kind of attribute involving a distinguished name (“DN”) and other data as well. If G is held on an older version of the directory and the new attribute is stored as a blob, then the referential integrity of the directory will be broken because the old version of the directory does not know how to properly update the blob to reflect the changed name. Clearly, in situations such as these, blobs are not an adequate solution.
Accordingly, what is needed is a forward compatibility syntax that provides backward compatibility with older directory syntaxes and eliminates the problems associated with using simple blobs.
SUMMARY OF THE INVENTION
The present invention, accordingly, provides a system and method for implementing a forward compatibility syntax in a directory services environment, such as an NDS environment. In one embodiment, the invention comprises two primary components. The first component involves taking an attribute according to a new syntax that is supported by newer servers, but not by older servers and separating data with respect to which referential integrity is not a concern (hereinafter “blob data”) from data with respect to which referential integrity is a concern (hereinafter Distinguished Names (“DNs”)), and recombining the two types of data according to a forward compatibility (“FC”) syntax that is supported by both older and newer servers. The second component involves the recognition that only certain, i.e., newer, servers understand and convert between the FC syntax and the actual new syntax, while the older servers just handle the FC syntax without actually needing to understand it.
In one aspect, an attribute according to a new syntax (“new attribute”) is created on a newer server. When the new attribute is to be replicated to an older server that does not support the new syntax, the first server converts the new attribute from the new syntax to a forward compatibility (“FC”) syntax, which includes two portions: a DN portion for containing data with respect to which referential integrity is a concern, and a data portion for containing data with respect to which referential integrity is not a concern. The older server is capable of recognizing and dealing with the DN portion of the FC syntax as a name; the remainder of the data is handled as a blob.
Accordingly, when, such as in the illustration set forth above, the name of an object contained in the DN portion of the FC syntax is changed, the older server is capable of recognizing the DN portion of the syntax as a name and updating it accordingly, thereby preserving the referential integrity of the system.
Subsequently, when an attribute according to the FC syntax (“FC attribute”) is to be replicated from an older server to a newer server that does support the new syntax, the server to which the FC attribute is replicated handles conversion of the attribute back to the new syntax format.
A technical advantage achieved with the invention is that it can accommodate new syntaxes containing data with respect to which referential integrity is a concern, such as DNs.
Another technical advantage achieved with the invention is that the conversion takes place only on newer servers, so that no upgrades to older servers are necessary to support a new syntax.
REFERENCES:
patent:
Hinckley Mark
Izatt Layne
Jarvis Brian
Amsbury Wayne
Haynes and Boone LLP
Novell Inc.
LandOfFree
Method of implementing a forward compatibility network... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method of implementing a forward compatibility network..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method of implementing a forward compatibility network... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2868875