The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
It is relatively standard in many industries to store information in on-line directories that conform to the X.500 standard. The lightweight directory access protocol (LDAP) provides relatively simple mechanisms for accessing and updating data that is contained in such directories. Because LDAP was designed to be used in conjunction with Transmission Control Protocol/Internet Protocol (TCP/IP), LDAP is especially useful for accessing and updating directory data via the Internet.
Although LDAP can be used to access and update data stored in LDAP directories, LDAP does not provide much of the rich functionality that database query languages, such as Structured Query Language (SQL) provide. SQL is firmly established and widely recognized. It is not surprising, then, that many applications have been designed to send SQL queries to a database server in order to retrieve data from database tables.
Under some circumstances, the data that an application needs to access is stored in an LDAP directory rather than a database table. According to past approaches, if an application is designed to access a database table using SQL instead of an LDAP directory using LDAP, then some intermediary mechanism is needed in order to get the LDAP directory data into a database table. Such a mechanism exists, but its use is accompanied by some significant drawbacks.
Typically, such a mechanism “synchronizes” a database table with an LDAP directory by periodically loading the LDAP directory data into the database table. However, in the interval occurring between synchronization operations, the LDAP directory data is susceptible to alteration. If the database table is queried after the LDAP directory data has been altered but before the next synchronization operation, then the query may return outdated and incorrect data. Decreasing the amount of time that passes between synchronization operations reduces, but does not nullify, the likelihood of this problem occurring. Indeed, scheduling more frequent synchronization operations can actually compound other problems.
One of these other problems results from the fact that because each synchronization operation consumes processing and communication resources, increasing the frequency of the synchronization operations causes more processing and communication resources to be consumed. As the LDAP directory data grows in size, the synchronization operations consume a greater portion of the resources.
LDAP directories are often located remotely from the applications that access those LDAP directories, and are often accessed via networks. For the duration of each synchronization operation, some of the network's limited bandwidth becomes unavailable for other purposes. In many networks, this kind of bandwidth monopolization is unacceptable.
Because they are performed at regular intervals without regard to whether LDAP directory data has been altered since the last synchronization operation, some synchronization operations might not accomplish anything beyond wasting processing and communication resources. The synchronization mechanisms used under past approaches are not sophisticated enough to determine when LDAP directory data has been altered, so those synchronization mechanisms continue to employ periodic synchronization schemes.
Although only a small portion of the LDAP directory data might have changed since the last synchronization operation, synchronization mechanisms used under past approaches are not sophisticated enough to detect which portions of the LDAP directory data have changed. Consequently, under past approaches, all of the LDAP directory data is loaded into a database during every synchronization operation. This exacerbates the resource consumption problem.
A less error-prone and less resource-consuming way of allowing a database-accessing application to access LDAP directory data is needed. Furthermore, since interfacing directly with an LDAP directory can be complex and cumbersome, a simpler and easier way of accessing LDAP directory data is needed.