Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
2000-02-02
2003-12-16
Robinson, Greta (Department: 2177)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000, C709S203000, C709S241000
Reexamination Certificate
active
06665674
ABSTRACT:
TECHNICAL FIELD
The invention relates to apparatus and methods for client access to information stored in an open directory and, in particular, to a framework for open directory extensibility that enables pre-processing and post-processing of operations used to access the information stored in the open directory.
BACKGROUND OF THE INVENTION
Directory servers known in the art store information in connected hierarchical tree structures. Information records held in a directory are only limited by rules imposed by a directory schema that govern any particular record type. Pointers can be set between a point in the directory and any other point in the directory. Although the rules imposed by the directory schema perform general directory data validation, the validation checks are not comprehensive in current directory server implementations.
A Lightweight Directory Access Protocol (LDAP) is an emerging Internet Engineering Task Force (IETF) standard which is gaining popularity in the industry as a mechanism by which to access a directory. The IETF LDAP specification itself provides a protocol for accessing information held by a persistent store, such as a directory.
A schema specification defines managed objects and attributes. These objects and attributes are specified through a data dictionary that provides a standard set of object classes. An object belongs to one or more object classes which define the attributes of the object. Generally, the schema is extensible by deriving other object classes (e.g. by modifying existing object classes and/or adding new object classes) according to methods known in the art so that the schema specification may be tailored to specific requirements.
The IETF standard provides some facilities to assist interoperability of certain network device management and network service management functionalities. However, an implementer using LDAP is also provided with extensions enabling the specification of vendor-specific schema, and an Application Program Interface (API) which may be used to access the elements of that vendor-specific schema. Once an LDAP schema is published, other implementers have a common mechanism by which that schema may be accessed, for example, by service provisioning, billing, and/or management applications. Various vendors are developing LDAP schema specifications to provide an API which their customers may use to integrate the vendor's equipment and services into the customer's internal service provisioning, management, customer care, billing solutions, and the like.
There are a few areas in which the IETF has either just begun to realize, or has not yet begun to realize the need for LDAP standardization. Such areas are schema validation and LDAP message processing.
LDAP message processing mechanisms can provide means by which schema providers may deliver code that: ensures that updates to a directory information tree are consistent with syntactic and semantic checks which are required for maintaining integrity of information stored in the directory; and perform any necessary side-effect changes which may be required as a result of any particular information access action in providing a service. For example, the deletion of one object may require a cascade of associated changes in other objects. A standardized LDAP message processing mechanism is particularly important for situations where it is desired to provide an LDAP schema and the LDAP protocol as an API for other services. If the schema provider cannot provide the code to enforce consistency checks and required side-effect processing, then it becomes more likely that the information stored in a directory will lose integrity, with unpredictable results. Typically in providing a service a prescribed behavior is specified in processing information access messages. Some of this prescribed behavior can be provided via a designed schema description and other prescribed behavior can be provided via specific execution code.
Some of the current LDAP directory server vendors have addressed the need for schema validation through proprietary APIs in their directory server products. In order to provide multi-vendor LDAP server support, this requires that vendors provide LDAP clients coded to support the differences across all vendor products, as well as support for each vendor's proprietary API set. Moreover, LDAP clients need to have knowledge of the combined schema across all vendors.
Generic (i.e. directory independent) solutions have been proposed which monitor LDAP requests between clients and a directory server, providing access to a directory, to provide directory vendor neutral validation. An example of such solutions includes the LDAP Trigger Access Process Gateway (LTAP gateway) recently proposed by Lucent/Bell Labs. This proposal teaches the use of a “trigger gateway” implementing a proprietary SQL database-based trigger mechanism providing a schema validation limited to proceed/do not proceed decisions. Lucent/Bell Labs are currently seeking patent protection for their solution.
Other related art is described in U.S. Pat. No. 5,983,234 entitled METHOD AND APPARATUS FOR GENERICALLY VIEWING AND EDITING OBJECTS, which issued Nov. 9, 1999 to Tietjen et al.; and U.S. Pat. No. 5,893,107 entitled METHOD AND SYSTEM FOR UNIFORMLY ACCESSING MULTIPLE DIRECTORY SERVICES, which issued Apr. 6, 1999 to Chan et al.
Access to information stored in a central directory server is enabled via a distributed data network, including intranets (local area networks) and internets (wide area networks), from remote client computers executing LDAP aware client software applications. The current implementations, such as the ones mentioned above, teach that the schema be partly enforced by the LDAP client application and partly by the directory server. The more reliance there is on proprietary solutions, such as the ones mentioned above, the greater an overhead created for a user of provided services in keeping up-to-date with the development of the proprietary solutions.
The problem stems from the fact that access to centrally stored information is provided on different vendor directory servers. The complexity of the data access for service offerings provided on multiple directory servers is increased if each directory server is provided by a different vendor. Directory server vendors are not necessarily service providers. In a competitive environment, various client applications may be required to enable access to a wide range of information. Not only are those various client applications necessary, they also need to be kept up-to-date. Upgrading the various client applications, at different times, to different versions, leads to a high overhead due to financial outlay and time required.
There is therefore a need to provide a framework for open directory extensibility that permits directory independent information access such that directory servers and client applications may be independently developed and maintained.
SUMMARY OF THE INVENTION
It is an object of the invention to provide a framework for open directory extensibility that permits directory independent information access.
It is another object of the invention to provide methods and apparatus for processing directory access messages according to a prescribed process.
It is another object of the invention to enable a schema specification to be implemented and enforced through schema validation in an interoperable manner independent of an underlying directory server implementation.
It is a further object of the invention to enable the implementation of schema consistency checks once and enforcement of the schema specification against all directory client access.
It is a further object of the invention to enable a single entity to validate LDAP messages according to a schema description in a layer interposed between LDAP clients and a directory server.
It is yet another object of the invention to enable a single entity to process directory messages according to a specification defining side-effects, in a layer interposed betw
Buchanan James H.
Connell Brian D.
Dunn Bruce E.
Gibson Robert T.
Macfarlane Ian A.
(Ogilvy Renault)
Nortel Networks Limited
Robinson Greta
Wood Max R.
LandOfFree
Framework for open directory operation extensibility does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Framework for open directory operation extensibility, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Framework for open directory operation extensibility will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3138264