1. Technical Field
This invention relates to the field of network directory services and, more particularly, to a system and method for interfacing a directory assistance system with a tree-based Lightweight Directory Access Protocol (LDAP) interface.
2. Description of the Related Art
A directory is a mechanism that clients can use to locate entries and attributes about those entries. Clients are often people (for example, someone xe2x80x9cquerying the directoryxe2x80x9d), but could also be programs (for instance, an application looking up an attribute about a user). Entries might include network resources such as printers or web pages or people (a xe2x80x9cwhite pagesxe2x80x9d directory). In addition to the clients and entries, the type of query being used to access the information is also important. The query structure defines the semantics of retrieving information from the directory. Different combinations of client type, entry type, and query type result in different kinds of directory applications. In sum, directories can be thought of as databases with the important characteristic that the number of database read operations generally exceeds the number of write operations by at least an order of magnitude. In addition, directory servers can be defined as repositories of attribute/value pairs that clients can use to locate entries and attributes using structured queries.
Directory Assistance (DA) solutions incorporate directories and directory servers which can provide phone numbers stored in the directories to callers via an operator service center. Typically, a caller dials xe2x80x9cinformationxe2x80x9d (e.g. xe2x80x9c411xe2x80x9d) to get the phone number of a person or business. Subsequently, the DA system employs an indexed referencing mechanism to obtain the requested information. Present DA systems have a proprietary interface for accessing information contained therein.
Each DA system typically organizes data stored therein differently from other data stored in other DA systems. Yet, presently, there exists a business need for customers of DA systems, for instance telecommunications companies, to share or even sell access to the disparately organized information stored in each DA system. Notwithstanding, the problem of sharing or selling access to customer DA system data has not been solved in both a standard manner and in an open systems environment.
Currently communication mechanisms between different DA systems and different installations of the same DA system have been implemented in closed, controlled environments. For instance, a customized Internet program in combination with hypertext markup language (HTML) pages have been provided to users in order to grant Intranet access to a proprietary DA system positioned behind a firewall. However, no solution has been devised that provides for an open standard for facilitating data interchange between disparate DA systems, which does not require specially written applications or programmer support in order to implement.
Moreover, current DA systems utilize proprietary interfaces which cannot be easily externalized directly to outside applications. Specifically, providing external access to a DA system implicates security concerns as well as training issues with the interface itself. For example, exposing the proprietary interface of a DA system can require the creation of a security mechanism to control access to the system. Moreover, exposing the proprietary interface of a DA system can require the training of users in the use of the DA system. Notably, training can further implicate the creation of documentation and the assembly of a support team. The training can be required because the proprietary interface to the DA system is not always intuitive. In consequence, users of the system must understand the proprietary nature of the underlying information stored in the DA system in order to use it. Finally, providing external access to a DA system can create a migration problem for users migrating from a proprietary DA system. In particular, applications designed to interact with the proprietary interface to the DA system can be compromised when transitioning to a different DA system or a different interface to the DA system.
Unlike the proprietary interfaces of current DA systems, the lightweight directory access protocol (LDAP) is an open industry standard directory services protocol which can provide a consistent and controlled system for accessing data. LDAP represents a simple, albeit powerful directory service which is capable of performing powerful directory service queries as well as allowing clients to issue commands that add, delete or modify directory service entries. Although the underlying storage of the information between LDAP servers can be disparate, the LDAP protocol does not expose this disparity to users of an LDAP interface. In LDAP, the basic unit of information consists of an entry. Entries are stored in directories. Directory entries are arranged in a hierarchical tree-like structure that can reflect real-world boundaries, for example a location or organization. The hierarchical tree-like LDAP structure enables users of a directory service to navigate through information stored therein in a known manner. Furthermore, through standard interfaces, the schema or organization of the attributes in an LDAP directory are obtainable. Consequently, LDAP applications, for example LDAP enabled web browsers like Netscape Communicator or Microsoft Internet Explorer, can use an LDAP directory interface without requiring of its users special training or knowledge of the underlying information system.
LDAP, a simplification of the X.500 directory access protocol (DAP), is defined in the request for comment, RFC-1777, xe2x80x9cLightweight Directory Access Protocolxe2x80x9d, available from the Internic HTTP server having the fully-qualified URL: ds.internic.net/rfc/rfcl777.txt and incorporated herein by reference. Specifically, LDAP defines a reasonably simple mechanism for Internet clients to query and manage an arbitrary database of hierarchical attribute/value pairs over a TCP/IP connection using port 389.
The LDAP directory service model is based on entries. An entry is a collection of filter attributes that has a name, referred to as a distinguished name (DN). The DN can be used to refer to the entry unambiguously. Each of the entry""s attributes can have a type and one or more values. The types typically are mnemonic strings, for example xe2x80x9ccnxe2x80x9d for common name, or xe2x80x9cmailxe2x80x9d for e-mail address. The values can depend on the type of corresponding attribute. For example, a mail attribute may contain the value xe2x80x9cjohnd@xyz.comxe2x80x9d. Similarly, a jpeg photo attribute may contain a photograph in binary JPEG format. An entry""s DN can be constructed by taking the name of the entry itself, referred to as the relative distinguished name (RDN), and concatenating the names of the RDN""s ancestor entries. For example, the entry for John Doe can have an RDN xe2x80x9ccn=John Doexe2x80x9d and a DN of xe2x80x9ccn=John Doe, o=xyz, c=USxe2x80x9d.
In LDAP, directory entries are arranged in a hierarchical tree-like structure that reflects political, geographic, and/or organizational boundaries. Entries representing countries can appear at the top of the tree. Below the country entries are entries representing states or national organizations. Below the state or national organization entries can exist entries representing people, organizational units, printers, documents, or other categorizational sub-units. Notably, the hierarchy in LDAP is a hierarchy of entries within a database, not a hierarchy of server connections, or other network configuration information.
LDAP entries generally are typed by an objectclass attribute. For example, in order to restrict searches of a directory to entries exclusively including access control lists, the search phrase xe2x80x9cobjectclass=aclxe2x80x9d can be specified so that only entries purporting to be access control lists are located. LDAP permits a user to control which attributes are required and allowed for a particular object class, thus determining the schema rules that the entry must obey. The choice of attribute names and the hierarchical structure of LDAP are derived from LDAP""s X.500 roots. However, it is important to note that LDAP is not an X.500 directory. Rather, it is the protocol between parties transacting business relating to any hierarchical, attribute-based directory. In the degenerate case, the hierarchy can be a single level and the attributes could be arbitrarily proprietary.
LDAP defines operations for interrogating and updating the directory. Furthermore, LDAP provides operations for adding and deleting an entry from the directory, changing an existing entry, and changing the name of an entry. Still, the primary operation of LDAP is to search for information stored in the directory. Consequently, the LDAP search operation allows some portion of the directory to be searched for entries that match some criteria specified by a search filter. A client can request information from each entry that matches the criteria. For example, a user can search the entire directory subtree below XYZ Corporation for people with the name John Doe, retrieving the e-mail address of each entry found. Alternatively, LDAP permits a user to search the entries directly below the entry for United States (c=US) for organizations containing the string xe2x80x9cAcmexe2x80x9d in the organization name, which organizations further have a fax number. RFC-1558, xe2x80x9cA String Representation of LDAP Search Filters,xe2x80x9d available from the Internic HTTP server having the fully-qualified URL: ds.internic.net/rfc/rfcl558.txt and incorporated herein by reference, specifies the syntax for the filters that can define a search. Using the searching facility, client developers can easily provide powerful search capabilities.
In performing a directory query, LDAP clients can choose filter attributes in the directory tree, for example a search location, and filter the search therefrom. Sample xe2x80x9cbasexe2x80x9d values can include xe2x80x9cst=FL . . . c=usxe2x80x9d or xe2x80x9cI=Boca Raton, I=Highland Beach Directory, st=FL, . . . , c=usxe2x80x9d. Additionally, an LDAP search can begin from almost any node in the LDAP directory tree. The LDAP client merely can set the search base to determine the point in the tree to begin the search. Advantageously, an LDAP search can return a result set with respect to each matching entry""s location in the LDAP directory tree. The result set can be communicated to an LDAP client using an LDAP distinguished name (DN) which indicates to the LDAP client the path to the LDAP directory entry, for example xe2x80x9cdn: cn=John Doe, I=Boca Raton, I=Highland Beach Directory, st=FL, . . . , c=usxe2x80x9d. In this example, xe2x80x9cJohn Doexe2x80x9d is located in the city of xe2x80x9cBoca Ratonxe2x80x9d, in the directory of xe2x80x9cHighland Beachxe2x80x9d, in the state of xe2x80x9cFLxe2x80x9d, and a country xe2x80x9cUSxe2x80x9d.
The LDAP directory service is based on a client-server model. Specifically, one or more LDAP servers contains the data comprising the LDAP directory tree. An LDAP client can connect to an LDAP server and transmit a request for data. The server either can respond with the data, or if the data is not available locally, the server can attempt to connect to another server, typically another LDAP server, that can fulfill the request. LDAP uses this referral capability to implement cooperating communities of disjoint LDAP servers, and to force all database changes to be referred to certain master LDAP servers. Notably, when LDAP servers employ the same naming convention, no matter which LDAP server a client connects to, the connecting client sees the same view of the directory. That is, a name presented to one LDAP server references the same entry that it would at another LDAP server.
At the lowest level, any client requiring access to directory information can connect to an LDAP server over a TCP/IP connection. Subsequently, the client can transmit LDAP commands to the LDAP server over the TCP/IP connection. Notably, to transmit an LDAP command, only a Domain Name System (DNS) name or explicit Internet protocol address for the LDAP server and a port number, for example port 389, are required. Upon receiving the transmitted LDAP command, the LDAP server can process the LDAP command and, if possible, reply with directory information. Hence, to command an LDAP server having the URL directory.xyz.com, a client could specify in an LDAP client, xe2x80x9cIdap://directory.xyz.com/ less than LDAP command greater than xe2x80x9d where Idap: invokes port 389, directory.xyz.com is a valid DNS name and  less than LDAP command greater than is a LDAP protocol command issued to the LDAP server by the LDAP client.
The following source code written in the xe2x80x9cCxe2x80x9d programming language illustrates an example method for issuing an LDAP command from a client to an LDAP server and receiving from the LDAP server responsive directory information:
LDAPv3.1 provides a xe2x80x9cplug-inxe2x80x9d architecture which permits a third party provider to integrate services into an LDAP server and consequently obtain processing control when a user of the host LDAP server specifies the node of the plug-in in the LDAP tree. An LDAP server plug-in is a shared object or library containing functions external to the functions provided with the LDAP server. Plug-in functions can be written to perform the following tasks: Validating data before the server performs an LDAP operation on the data; performing some user-defined action after the server completes an LDAP operation; and, performing extended operations; providing alternate matching rules when comparing certain attribute values. In the present invention, the LDAP plug-in is used to replace an existing back-end database with the database of a proprietary DA system.
When employing an LDAP server plug-in, on startup, the LDAP server can load the specified shared object or library and can call the plug-in functions stored therein during the course of processing various LDAP requests. Notably, the LDAP server can invoke a plug-in function at several points in the process of servicing an LDAP request. For example, the LDAP server can call the LDAP server plug-in functions before executing an LDAP operation; when the LDAP server is to add, modify, delete, or find entries in the database; before writing an entry to the database; after reading an entry from the database; after executing an LDAP operation; when an LDAP request contains an extended operation; when the LDAP server indexes an attribute; and, when an LDAP server filters candidates for search results based on an attribute. In the present invention, the plug-in function can be called during the execution of an LDAP operation. In most cases, when the LDAP server calls an LDAP server plug-in function, the LDAP server passes a parameter block to the plug-in function. The parameter block can contain data relevant to the operation performed by the plug-in function. For example, in an LDAP add operation, the parameter block can contain the entry to be added to the directory and the DN of that entry. As a result, the server plug-in function can access and modify data in the parameter block. Further, if the LDAP server plug-in function is invoked before an LDAP operation executes, the plug-in function can prevent the LDAP operation from executing. For example, a plug-in function can validate data before a new entry is added to the directory. If the data is invalid, the plug-in function can abort the LDAP add operation and return an error message to the LDAP client.
Still, LDAP has not been integrated with current DA systems. In fact, the integration of LDAP with existing DA systems could prove problematic, particularly where the data in the DA system is structured in a manner incompatible with the hierarchical tree-like structure of traditional LDAP-compliant systems. Hence, there remains a need not only for a method and system for attaching the LDAP protocol onto existing DA systems, but also for a method of abstracting the underlying DA system so that the data contained therein appears to be structurally organized in a typical LDAP hierarchical tree-like directory structure.
Large scale Directory Assistance (DA) systems use proprietary database structures having proprietary access in order to minimize access times and all scaling to millions of directory listings. However, the modern trend of open, standards-based access to directory information, exemplified by the Lightweight Directory Access Protocol (LDAP) compel operators of proprietary DA systems to deploy parallel systems that can be costly to implement and maintain. A system and method in accordance with the inventive arrangements permits operators of proprietary DA systems to implement and maintain a single DA system which, in consequence of the present invention, can support multiple access types.
A method for mapping a LDAP interface to a DA system can include the following steps. First, LDAP compatible search arguments for searching an LDAP database can be extracted from an LDAP request. Second, the LDAP compatible search arguments can be converted to search arguments compatible with a DA system database. Third, the DA system database can be queried using the converted search arguments. Fourth, a result set of listings from the DA system database can be received in response to the query. Finally, the result set can be converted to a result set compatible with LDAP.
Preferably, each of the five steps can be performed in a plug-in to the LDAP server. Additionally, the method can include the step of receiving the LDAP request from an LDAP client. Moreover, the method can include the step of receiving the LDAP request in an LDAP server.
In the preferred embodiment, the LDAP request is an LDAP filtered attribute. Consequently, in the preferred embodiment, the step of converting can include the step of mapping search arguments in the filtered attribute to search arguments compatible with the DA system database. Notably, the mapping step can comprise consulting a locality resolution database, each record in the locality resolution database mapping a locality to a locality ID set, identifying in the locality resolution a database record corresponding to the search arguments; and, forming a DA system database query statement with a locality ID set contained in the identified record. Furthermore, the locality ID set can include at least one of an area code, book and location.
A system for mapping a LDAP interface to a DA system can include the following components: an LDAP client for transmitting LDAP requests for directory information; an LDAP server for receiving and processing the LDAP requests; a DA system for providing directory information responsive to DA system compatible requests for the DA system directory information, the DA system directory information stored in a DA system database; and a plug-in coupled to the LDAP server. Significantly, the plug-in can intercept the LDAP requests, extracting therefrom LDAP compatible search arguments for searching an LDAP database, and convert the LDAP compatible search arguments to search arguments compatible with the DA system database. Additionally, the plug-in can query the DA system with the converted search arguments, receive a result set of listings therefrom in response to the query, convert the result set to a result set compatible with LDAP, and pass the LDAP compatible result set to the LDAP server. Finally, the LDAP, server can provide the LDAP compatible result set to the LDAP client.
In the preferred embodiment, the LDAP request is an LDAP compatible search. Preferably, the plug-in can convert the LDAP compatible search arguments to search arguments compatible with the DA system database by mapping search arguments in the filtered attribute to search arguments compatible with the DA system database. As such, the system can further include a locality resolution database wherein the mapping is determined by the locality resolution database, each record in the locality resolution database mapping a locality to a locality ID set. Furthermore, the locality ID set comprises at least one of an area code, book and location.
The system can further include a file update program for loading locality and directory information in the DA system database and a locality processor for producing a load file based on the locality information. Notably, the load file can interface the locality resolution database with the plug-in. Furthermore, the load file can further interface an LDAP database with the plug-in.
USPTO Backgrounds
USPTO Backgrounds