Data processing: software development – installation – and managem – Software program development tool – Managing software components
Reexamination Certificate
1999-05-06
2003-05-13
Morse, Gregory (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
Managing software components
C717S120000, C717S121000, C717S123000, C717S170000, C717S171000, C707S793000, C707S793000
Reexamination Certificate
active
06564370
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field
This invention relates generally to providing directory services in a distributed computing environment and, in particular, to a method for associating a signature with a given attribute in a directory.
2. Description of the Related Art
A directory service is the central point where network services, security services and applications can form an integrated distributed computing environment. Typical uses of a directory services may be classified into several categories. A “naming service” (e.g., DNS and DCE Cell Directory Service (CDS)) uses the directory as a source to locate an Internet host address or the location of a given server. A “user registry” (e.g., Novell NDS) stores information about users in a system composed of a number of interconnected machines. The central repository of user information enables a system administrator to administer the distributed system as a single system image. Still another directory service is a “white pages” lookup provided by some e-mail clients, e.g., Netscape Communicator, Lotus Notes, Endora and the like.
With more and more applications and system services demanding a central information repository, the next generation directory service will need to provide system administrators with a data repository that can significantly ease administrative burdens. In addition, the future directory service must also provide end users with a rich information data warehouse that allows them to access department or company employee data, as well as resource information, such as name and location of printers, copy machines, and other environment resources. In the Internet/intranet environment, it will be required to provide user access to such information in a secure manner.
To this end, the Lightweight Directory Access Protocol (LDAP) has emerged as an IETF open standard to provide directory services to applications ranging from e-mail systems to distributed system management tools. LDAP is an evolving protocol that is based on a client-server model in which a client makes a TCP/IP connection to an LDAP server, sends requests, and receives responses. The LDAP information model in particular is based on an “entry,” which contains information about some object. Entries are typically organized in a specified tree structure, and each entry is composed of attributes.
LDAP is rapidly becoming the standard protocol for accessing attributes in client-server based distributed directories. While standardized protocols like LDAP are advantageous, the key to accessing a proper attribute in a directory service is implementation of a robust directory schema. Schema standardization, however, will be much more problematic.
In particular, standardized schema rules will state that each application should store its attributes in a part of the schema that is unique to the application. This rule will exist to prevent applications from storing attributes in the same location in the schema, which may give rise to interfering attributes. Other attributes, however, such as user credentials, will be stored in locations that are standardized so that all applications can access the same attribute. These so-called common attributes will move forward and change format as needed to address new application capabilities. However, attributes used by multiple applications must remain the same to support legacy applications. One solution to this problem may be to create new locations for new versions of attributes, but this creates a synchronization problem. The representative schema in
FIG. 1
illustrates why this is the case. If the attribute is migrated in the original location, legacy (i.e. down level clients) may not work.
For purposes of illustration, attribute Attrib
x
[ ] is assumed to be a set of attributes, such as a complex object. The attribute Attrib
x
[ ] may be a flat list, a linked list, an array, or any other convenient data structure. With the first release (e.g. V
1
.
0
) of a given subsystem or application, the schema puts Attrib
x
[ ] at a given location (e.g., \DIR
1
\DIRA) in the schema. When the second release (e.g., V
1
.
1
) of the same subsystem or application occurs, the schema is extended, with the next version of Attrib
x
[ ] (V
11
) being added as shown. A similar extension is provided when the next release (V
1
.
2
) occurs, and so on. Thus, in the prior art, with each new release, the schema leaves the old attributes unchanged and where they were, and stores the new attributes somewhere else. This extension must occur without disruption to down level (i.e. earlier versions) of the subsystem or application. With multiple versions and this complex schema, the directory is required to implement additional routines to synchronize the attributes. This is an expensive and complex task for standard directory operations.
The present invention addresses these problems.
BRIEF SUMMARY OF THE INVENTION
According to the invention, attributes are stored in a directory together with a signature that identifies given information, e.g., the purpose and version of the attribute. Thus, when an attribute is migrated to a new value, e.g., upon the release of a new application version, the directory schema need not be extended. Rather, the attribute may be maintained in the schema is the same location as was used with an earlier application version. This directory schema enables a directory client application to query an attribute and determine its version. In addition, a new client application can perform attribute conversion for down level attributes that it understands how to convert and interpret. Further, this schema facilitates the implementation of an attribute conversion layer to a directory client so that new attributes may be easily converted to legacy format on behalf of a legacy application. Alternatively, an attribute proxy may be used for this purpose.
Thus, according to the present invention, attributes of objects that are used by more than one directory application are provided with additional information, an attribute signature. The signature may be plaintext, or it may be encoded or encrypted. An attribute used by more than one directory application is a common attribute. An attribute signature may comprise a name of an owning application (i.e. the application that generates the signature), data identifying a version of the attribute, a timestamp, other identifying information and, optionally, a given function to be applied to the attribute. Use of attribute signatures enables an application to query an attribute to determine its version and to efficiently manage information in the directory.
Thus, for example, a method for managing information begins by storing in the directory an attribute that is shared by a plurality of applications together with a signature identifying a then-current version of the attribute. In response to a query from an application, the signature is used to determine whether the application expects to receive an earlier version of the attribute (e.g., because it is a down level, or earlier, version of the application). Whether or not the application expects to receive an earlier version of the attribute, a query is initiated to the directory for the then-current version of the attribute. This query is initiated by an attribute leveling plug-in or proxy. The then-current version of the attribute is then returned from the directory. The plug-in or proxy, however, returns the earlier version of the attribute to the down-level application. This operation ensures that the directory operation initiated by the down level client does not fail.
The foregoing has outlined some of the more pertinent objects and features of the present invention. These objects and features should be construed to be merely illustrative of some of the more prominent features and applications of the invention. Many other beneficial results can be attained by applying the disclosed invention in a different manner or modifying the invention as will be described. Accord
Burwell Joseph R.
International Business Machines - Corporation
Judson David H.
LaBaw Jeffrey S.
Morse Gregory
LandOfFree
Attribute signature schema and method of use in a directory... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Attribute signature schema and method of use in a directory..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Attribute signature schema and method of use in a directory... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3018297