DE10131192A1 - Schnittstelle zu Verzeichnisunterstützungssystemen unter Verwendung des Lightweight Directory Access Protocol - Google Patents

Abstract

Ein Verfahren zum Abbilden einer LDAP-Schnittstelle (Lightweight Directory Access Protocol, einfaches Verzeichniszugriffsprotokoll) auf ein DA-System (Directory Assistance, Verzeichnisunterstützung) kann die folgenden Schritte umfassen. Erstens können LDAP-kompatible Suchargumente zum Durchsuchen einer LDAP-Datenbank aus einer LDAP-Anforderung extrahiert werden. Zweitens können die LDAP-kompatiblen Suchargumente in Suchargumente, die mit einer Datenbank eines DA-Systems kompatibel sind, umgewandelt werden. Drittels kann die Datenbank des DA-Systems unter Verwendung der umgewandelten Suchargumente abgefragt werden. Viertens kann von der Datenbank des DA-Systems als Antwort auf die Abfrage eine Ergebnismenge von Einträgen erhalten werden. Schließlich kann die Ergebnismenge in eine LDAP-kompatible Ergebnismenge umgewandelt werden. Vorzugsweise kann jeder der fünf Schritte in einem Plug-In zum LDAP-Server ausgeführt werden. Das Verfahren kann außerdem den Schritt des Empfangens der LDAP-Anforderung von einem LDAP-Client enthalten. Überdies kann das Verfahren den Schritt des Empfangens der LDAP-Anforderung in einem LDAP-Server enthalten.

Description

HINTERGRUND DER ERFINDUNG Technisches Gebiet

Diese Erfindung betrifft das Gebiet der Netzverzeichnisdienste und insbesondere ein System und ein Verfahren zum Verbinden eines Verzeichnisunterstützungssystems (Directory Assistance System) mit einer LDAP-Schnittstelle (Lightweight Directory Access Protocol, einfaches Verzeichniszugriffsprotokoll) mit Baumstruktur.

Beschreibung der zugrunde liegenden Technik

Ein Verzeichnis ist ein Mechanismus, den Clients verwenden können, um Einträge und Attribute dieser Einträge zu lokalisieren. Clients sind oftmals Personen (z. B. jemand, der "das Verzeichnis abfragt"), sie können jedoch auch Programme sein (z. B. eine Anwendung, die ein Attribut zu einem Benutzer nachschlägt). Einträge können Netzressourcen wie einen Drucker oder Webseiten oder Personen beinhalten (ein Verzeichnis in der Art eines Telefonbuchs). Außer Clients und Einträgen ist ebenfalls der Typ der Abfrage wichtig, der für den Zugriff auf die Informationen verwendet wird. Die Abfragestruktur definiert die Semantik zum Abrufen von Informationen aus dem Verzeichnis. Verschiedene Kombinationen aus Clienttyp, Eintragstyp und Abfragetyp ergeben unterschiedliche Arten von Verzeichnis- Anwendungen. Zusammenfassend kann man sich Verzeichnisse als Datenbanken mit dem wichtigen Merkmal vorstellen, dass die Anzahl der Datenbank-Leseoperationen im Allgemeinen die Anzahl der Schreiboperationen um wenigstens eine Größenordnung übersteigt. Außerdem können Verzeichnis-Server als Repositories von Attribut/Wert-Paaren definiert werden, die Clients verwenden können, um Einträge und Attribute unter Verwendung von strukturierten Abfragen zu lokalisieren.

DA-Lösungen (Directory Assistance, Verzeichnisunterstützung) enthalten Verzeichnisse und Verzeichnis-Server, die Telefonnummern, welche in den Verzeichnissen gespeichert sind, über ein Vermittlungszentrum dem Anrufer bereitstellen können. Ein Anrufer wählt üblicherweise die "Auskunft" (z. B. "411" in den USA), um die Telefonnummer einer Person oder einer Firma zu bekommen. Anschließend verwendet das System einen Mechanismus der indizierten Bezugnahme, um die benötigte Information zu erhalten. Heutige DA-Systeme besitzen eine proprietäre Schnittstelle zum Zugreifen auf darin enthaltene Informationen.

Üblicherweise organisiert jedes DA-System darin enthaltene Daten anders als andere Daten, die in anderen DA-Systemen gespeichert sind. Es gibt jedoch trotzdem ein geschäftliches Interesse für Kunden von DA-Systemen, z. B. Telekommunikationsfirmen, einen Zugriff auf ungleichartig organisierte Informationen, die in jedem DA-System gespeichert sind, gemeinsam zu nutzen oder diesen sogar zu verkaufen. Nichtsdestoweniger ist jedoch bisher das Problem der gemeinsamen Nutzung oder des Verkaufs des Zugriffs auf Kundendaten in DA-Systemen sowohl in einer Standardumgebung als auch in der Umgebung offener Systeme nicht gelöst worden.

Gegenwärtige Kommunikationsmechanismen zwischen unterschiedlichen DA-Systemen und unterschiedlichen Installationen des gleichen DA- Systems sind in geschlossenen kontrollierten Umgebungen implementiert worden. Beispielsweise ist ein angepasstes Internet-Programm in Kombination mit HMTL-Seiten (Hypertext Markup Language) Benutzern bereitgestellt worden, um einen Intranet-Zugang zu einem proprietären DA-System, das sich hinter einer Firewall befindet, zu gewähren. Es ist jedoch keine Lösung vorgeschlagen worden, die einen offenen Standard schafft, um den Datenaustausch zwischen ungleichen DA-Systemen zu vereinfachen, der zum Implementieren keine speziell geschriebenen Anwendungen oder eine Programmiererunterstützung benötigt.

Überdies verwenden gegenwärtige DA-Systeme proprietäre Schnittstellen, die nicht in einfacher Weise direkt mit extern laufenden Anwendungen verwendet werden können. Insbesondere beinhaltet das Schaffen eines externen Zugriffs auf ein DA-System Sicherheitsbedenken sowie Trainingsprobleme an der Schnittstelle selbst. Beispielsweise kann die Freigabe der proprietären Schnittstelle eines DA-Systems die Schaffung eines Sicherheitsmechanismus erfordern, um den Zugriff auf das System zu kontrollieren. Überdies kann die Freigabe der proprietären Schnittstelle eines DA-Systems das Training der Benutzer für die Verwendung des DA-Systems erfordern. Bemerkenswerterweise kann das Training außerdem die Erstellung von Dokumentation und den Aufbau eines Unterstützungsteams beinhalten. Das Training kann erforderlich sein, da die proprietäre Schnittstelle zum DA-System nicht immer intuitiv ist. Folglich müssen Benutzer des Systems die proprietäre Natur der im DA-System gespeicherten zugrunde liegenden Informationen kennen, um diese zu verwenden.

Schließlich kann das Schaffen eines externen Zugriffs auf ein DA- System für Benutzer, die von einem proprietären DA-System migrieren, ein Migrationsproblem erzeugen. Insbesondere können Anwendungen, die dafür vorgesehen sind, mit der proprietären Schnittstelle zum DA-System zusammenzuwirken, beeinträchtigt werden, wenn zu einem anderen DA-System oder zu einer anderen Schnittstelle zum DA-System übergegangen wird.

Im Unterschied zu den proprietären Schnittstellen gegenwärtiger DA-Systeme ist das Lightweight Directory Access Protocol (LDAP) ein Verzeichnisdienst-Protokoll mit offenem Industriestandard, der ein konsistentes und kontrolliertes System zum Zugreifen auf Daten gewährleisten kann. Das LDAP stellt einen einfachen, jedoch leistungsstarken Verzeichnisdienst dar, der in der Lage ist, Abfragen des leistungsstarken Verzeichnisdienstes ausführen zu können, und auch ermöglichen kann, dass Clients Befehle ausgeben können, die Verzeichnisdiensteinträge hinzufügen, löschen oder modifizieren können. Obwohl die zugrunde liegende Speicherung der Informationen zwischen LDAP-Servern ungleichartig sein kann, ist durch das LDAP diese Unterschiedlichkeit für den Benutzer einer LDAP-Schnittstelle nicht erkennbar. Beim LDAP ist die Grundeinheit der Information ein Eintrag. Einträge werden in Verzeichnissen gespeichert. Verzeichniseinträge werden in einer hierarchischen baumartigen Struktur, die die Grenzen der reellen Welt, z. B. einen Ort oder eine Organisation, widerspiegeln kann, angeordnet. Die hierarchische baumähnliche LDAP-Struktur ermöglicht es den Benutzern eines Verzeichnisdienstes, in bekannter Weise durch die darin gespeicherten Informationen zu navigieren. Überdies ist das Schema oder die Organisation der Attribute in einem LDAP-Verzeichnis über Standard-Schnittstellen verfügbar. Demzufolge können LDAP-Anwendungen, z. B. LDAP-fähige Web-Browser wie der Netscape Communicator oder der Microsoft Internet Explorer, eine LDAP-Verzeichnisschnittstelle verwenden, ohne dass seine Benutzer ein spezielles Training oder Kenntnis des zugrunde liegenden Informationssystems benötigen.

Das LDAP, eine Vereinfachung des X.500 Directory Access Protocol (DAP), ist in der Aufforderung zur Stellungnahme RFC-1777, "Lightweight Directory Access Protocol" definiert, die vom Internic HTTP-Server mit der vollständigen URL:
ds.internic.net/rfc/rfc1777.txt verfügbar ist und durch die Bezugnahme Bestandteil dieses Patents ist. Das LDAP definiert insbesondere einen in vernünftiger Weise einfachen Mechanismus für Internet-Clients, um eine beliebige Datenbank mit hierarchischen Attribut/Wert-Paaren über eine TCP/IP-Verbindung unter Verwendung des Ports 389 abzufragen und zu verwalten.

Das LDAP-Verzeichnisdienstmodell basiert auf Einträgen. Ein Eintrag ist eine Sammlung von Filterattributen, die einen Namen besitzt, der als ein registrierter Name oder DN (distinguished name) bezeichnet wird. Der DN kann verwendet werden, um den Eintrag eindeutig zu bezeichnen. Jedes der Attribute eines Eintrags kann einen Typ und einen oder mehrere Werte besitzen. Die Typen sind üblicherweise mnemonische Zeichenfolgen, z. B. "cn" für allgemeiner Name (common name) oder "mail" für e-Mail- Adresse (e-mail address). Die Werte können vom Typ des entsprechenden Attributs abhängen. Zum Beispiel kann ein Mail- Attribut den Wert "johnd@xyz.com" enthalten. In ähnlicher Weise kann ein jpeg photo-Attribut ein Photo im binären JPEG-Format enthalten. Ein DN eines Eintrags kann in der Weise aufgebaut sein, dass der Name des Eintrags selbst genommen wird, als der relative registrierte Name bzw. RDN (relative distinguished name) bezeichnet wird und die Namen der übergeordneten Einträge des RDN verknüpft werden. Zum Beispiel kann der Eintrag für John Doe einen RDN von "cn=John Doe" und einen DN von "cn=John Doe, o=xyz, c=US" aufweisen.

Beim LDAP sind Verzeichniseinträge in einer hierarchischen baumähnlichen Struktur angeordnet, die politische, geografische und/oder organisatorische Grenzen widerspiegelt. Einträge, die Länder darstellen, können an der Spitze des Baumes erscheinen. Unter den Ländereinträgen sind Einträge, die Bundesstaaten oder nationale Organisationen repräsentieren. Unter den Bundesstaaten oder nationalen Organisationen können Einträge vorhanden sein, die Menschen, Organisationseinheiten, Drucker, Dokumente oder weitere kategorisierbare Untereinheiten repräsentieren. Bemerkenswerterweise ist die Hierarchie beim LDAP eine Hierarchie der Einträge in einer Datenbank, keine Hierarchie der Serververbindungen oder weiterer Informationen der Netzkonfiguration.

LDAP-Einträge werden im Allgemeinen durch ein Attribut der Objektklasse typisiert. Um beispielsweise die Suche eines Verzeichnisses auf Einträge zu beschränken, die ausschließlich Zugriffskontrolllisten (access control lists) enthalten, kann die Suchangabe "objectclass=acl" so spezifiziert werden, dass lediglich Einträge lokalisiert werden, die vorgeben, Zugriffskontrolllisten zu sein. Das LDAP ermöglicht einem Benutzer zu steuern, welche Attribute für eine bestimmte Objektklasse erforderlich und zugelassen sind, wodurch die schematischen Regeln bestimmt werden, denen der Eintrag entsprechen muss. Die Wahl der Attributnamen und der hierarchischen Struktur des LDAP werden von den X.500-Wurzeln des LDAP abgeleitet. Es ist jedoch wichtig anzumerken, dass das LDAP kein X.500-Verzeichnis ist. Es ist statt dessen das Protokoll zwischen geschäftlich verbundenen Teilnehmern in Bezug auf ein beliebiges hierarchisches attributgestütztes Verzeichnis. Im vereinfachten Fall kann die Hierarchie eine Einebenen-Hierarchie sein und die Attribute könnten willkürlich proprietär sein.

Das LDAP definiert Operationen zum Abfragen und Aktualisieren des Verzeichnisses. Außerdem gewährleistet das LDAP Operationen zum Hinzufügen und zum Löschen eines Eintrags aus dem Verzeichnis, zum Ändern eines vorhandenen Eintrags und zum Ändern des Namens eines Eintrags. Trotzdem ist die Hauptoperation des LDAP die Suche nach Informationen, die in dem Verzeichnis gespeichert sind. Demzufolge ermöglicht die LDAP-Suchoperation, dass ein gewisser Teil des Verzeichnisses nach Einträgen durchsucht wird, die mit einem Kriterium übereinstimmen, das durch ein Suchfilter spezifiziert wurde. Ein Client kann von jedem Eintrag Informationen anfordern, der mit dem Kriterium übereinstimmt. Zum Beispiel kann ein Benutzer den gesamten Verzeichnis-Unterbaum der Firma XYZ nach Personen durchsuchen, die den Namen John Doe besitzen, und die e-Mail-Adressen von jedem gefundenen Eintrag abrufen. Alternativ ermöglicht das LDAP einem Benutzer, die Einträge direkt unter dem Eintrag für die Vereinigten Staaten (c=US) nach Organisationen zu durchsuchen, die im Organisationsnamen die Zeichenfolge "Acme" enthalten und außerdem eine Fax-Nummer besitzen. RFC-1558, "A String Representation of LDAP Search Filters", die vom Internic HTTP-Server mit der vollständigen URL: ds.internic.net/rfc/rfc1558.txt verfügbar ist und durch die Bezugnahme Bestandteil dieses Patents ist, spezifiziert die Syntax für die Filter, die eine Suche definieren können. Unter Verwendung der Sucheinrichtung können Client- Entwickler in einfacher Weise leistungsstarke Suchmöglichkeiten schaffen.

Bei der Ausführung einer Verzeichnisabfrage können LDAP-Clients Filterattribute im Verzeichnisbaum wählen, z. B. einen Suchort, und die Suche von dort filtern. "Basis"-Werte können beispielsweise enthalten "st=FL. . .c=us" oder "I=Boca Raton, I=Highland Beach Directory, st=FL, . . ., c=us". Außerdem kann eine LDAP-Suche an nahezu jedem Knoten im LDAP- Verzeichnisbaum beginnen. Der LDAP-Client kann lediglich die Suchbasis einstellen, um den Punkt im Baum zu bestimmen, an dem die Suche beginnen soll. Eine LDAP-Suche kann vorteilhafterweise eine Ergebnismenge unter Bezugnahme auf die Lokation im LDAP- Verzeichnisbaum eines jeden zutreffenden Eintrags liefern. Die Ergebnismenge kann unter Verwendung eines registrierten LDAP- Namens (DN), der dem LDAP-Client den Pfad zum LDAP- Verzeichniseintrag anzeigt, an den LDAP-Client übertragen werden, z. B. "dn: cn=John Doe, I=Boca Raton, I=Highland Beach Directory, st=FL, . . ., c=us". In diesem Beispiel befindet sich "John Doe" in der Stadt "Boca Raton", im Verzeichnis "Highland Beach", im Bundesstaat "FL" und im Land "US".

Der LDAP-Verzeichnisdienst basiert auf einem Client-Server- Modell. Genauer enthalten ein oder mehrere LDAP-Server die Daten, die den LDAP-Verzeichnisbaum umfassen. Ein LDAP-Client kann eine Verbindung zu einem LDAP-Server herstellen und eine Datenanforderung übertragen. Der Server kann entweder mittels der Daten antworten oder, wenn die Daten nicht zur Verfügung stehen, versuchen, mit einem weiteren Server zu verbinden, der üblicherweise ein weiterer LDAP-Server ist, der dann die Anforderung erfüllen kann. Das LDAP verwendet diese Bezugsmöglichkeit, um zusammenwirkende Gemeinschaften von nicht miteinander verbundenen LDAP-Servern zu implementieren und um zu erzwingen, dass alle Datenbankänderungen auf bestimmte Master- LDAP-Server bezogen werden. Bemerkenswerterweise hat der angeschlossene Client dieselbe Sicht auf das Verzeichnis, wenn die LDAP-Server dieselbe Bezeichnungskonvention verwenden, unabhängig davon, zu welchem LDAP-Server ein Client eine Verbindung herstellt. Das heißt, ein Name, der einem LDAP-Server angeboten wird, bezieht sich auf den gleichen Eintrag, auf den er sich auch in einem anderen LDAP-Server beziehen würde.

Auf der untersten Ebene stellt ein Client, der Zugang zu Verzeichnisinformationen anfordert, über eine TCP/IP-Verbindung einen Anschluss zu einem LDAP-Server her. Anschließend kann der Client über die TCP/IP-Verbindung LDAP-Befehle zum LDAP-Server übertragen. Bemerkenswerterweise werden zum Übertragen eines LDAP-Befehls lediglich ein Name des Domainnamensystems (DNS, Domain Name System) oder eine explizite Internet-Protokolladresse für den LDAP-Server und eine Portnummer, z. B. Port 389, benötigt. Beim Empfangen des übertragenen LDAP-Befehls kann der LDAP-Server den LDAP-Befehl verarbeiten und, wenn dies möglich ist, mit den Verzeichnisinformationen antworten. Somit könnte ein Client zum Befehligen eines LDAP-Servers mit der URL directory.xyz.com in einem LDAP-Client "Idap:/ / directory.xyz.com/<LDAP command<" angeben, wobei Idap: den Port 389 aufruft, directory.xyz.com ein gültiger DNS-Name und <LDAP command< ein Befehl des LDAP-Protokolls ist, der vom LDAP- Client an den LDAP-Server ausgegeben wird.

Der folgende Quellencode, der in der Programmiersprache "C" geschrieben ist, erläutert ein beispielhaftes Verfahren zum Ausgeben eines LDAP-Befehls von einem Client an einen LDAP-Server und zum Empfangen der Verzeichnisinformationen als Antwort vom LDAP-Server:

LDAPv3.1 stellt eine "Plug-In"-Architektur dar, die es einem dritten Leistungsanbieter (Provider) ermöglicht, Dienste in einen LDAP-Server zu integrieren und nachfolgend die Verarbeitungssteuerung zu erlangen, wenn ein Benutzer des Host- LDAP-Servers den Knoten des Plug-In in der LDAP-Baumstruktur spezifiziert. Ein Plug-In des LDAP-Servers ist ein gemeinsam genutztes Objekt oder eine gemeinsam genutzte Bibliothek, die Funktionen enthält, die außerhalb der Funktionen liegen, die mit dem LDAP-Server bereitgestellt werden. Plug-In-Funktionen können geschrieben werden, um die folgenden Tasks auszuführen: Prüfen von Daten, bevor der Server eine LDAP-Operation an den Daten ausführt; Ausführen einer benutzerdefinierten Aktion, nachdem der Server eine LDAP-Operation beendet hat; und Ausführen erweiterter Operationen; Bereitstellen von alternativen Abgleichsregeln beim Vergleichen bestimmter Attributwerte. In der vorliegenden Erfindung wird das LDAP-Plug-In verwendet, um eine vorhandene Back-End-Datenbank durch die Datenbank eines proprietären DA- Systems zu ersetzen.

Wenn ein Plug-In eines LDAP-Servers verwendet wird, kann der LDAP-Server beim Einschalten das spezifizierte gemeinsam genutzte Objekt oder die gemeinsam genutzte Bibliothek laden und während der Verarbeitung verschiedener LDAP-Anforderungen die darin gespeicherten Plug-In-Funktionen aufrufen. Bemerkenswerterweise kann der LDAP-Server eine Plug-In-Funktion an mehreren Punkten im Verarbeitungsprozess einer LDAP-Anforderung aufrufen. Der LDAP- Server kann beispielsweise die Plug-In-Funktionen des LDAP- Servers aufrufen, bevor er die LDAP-Operation ausführt; wenn der LDAP-Server Einträge in der Datenbank hinzufügen, modifizieren, löschen oder finden soll; vor dem Schreiben eines Eintrags in die Datenbank; nach dem Lesen eines Eintrags aus der Datenbank; nach dem Ausführen einer LDAP-Operation; wenn eine LDAP-Anforderung eine erweiterte Operation enthält; wenn der LDAP-Server ein Attribut indiziert; und wenn ein LDAP-Server Kandidaten für Suchergebnisse auf der Grundlage eines Attributs filtert. In der vorliegenden Erfindung kann die Plug-In-Funktion während der Ausführung einer LDAP-Operation aufgerufen werden.

In den meisten Fällen leitet der LDAP-Server dann, wenn der LDAP- Server eine Plug-In-Funktion des LDAP-Servers aufruft, einen Parameterblock zur Plug-In-Funktion. Der Parameterblock kann Daten enthalten, die für die Operation, die durch die Plug-In- Funktion ausgeführt wird, relevant sind. Zum Beispiel kann der Parameterblock bei einer LDAP-Hinzufügungsoperation den Eintrag, der dem Verzeichnis hinzugefügt werden soll, und den registrierten Namen (DN) dieses Eintrags enthalten. Folglich kann die Plug-In-Funktion des Servers auf Daten im Parameterblock zugreifen und diese modifizieren. Ferner kann die Plug-In- Funktion dann, wenn die Plug-In-Funktion des LDAP-Servers aufgerufen wird, bevor eine LDAP-Operation ausgeführt wird, die Ausführung der LDAP-Operation verhindern. Eine Plug-In-Funktion kann beispielsweise Daten auf Gültigkeit prüfen, bevor dem Verzeichnis ein neuer Eintrag hinzugefügt wird. Wenn die Daten ungültig sind, kann die Plug-In-Funktion die LDAP- Hinzufügungsoperation abbrechen und eine Fehlermeldung an den LDAP-Client zurücksenden.

Trotzdem ist das LDAP in gegenwärtige DA-Systeme nicht integriert worden. Die Integration des LDAP in vorhandene DA-Systeme könnte sich tatsächlich als problematisch erweisen, insbesondere dort, wo die Daten im DA-System in einer solchen Weise strukturiert sind, die mit der hierarchischen baumähnlichen Struktur herkömmlicher Systeme, die dem LDAP entsprechen, inkompatibel ist. Somit besteht ein Bedarf nicht nur an einem Verfahren und einem System zum Anwenden des LDAP auf vorhandene DA-Systeme, sondern auch an einem Verfahren zum Umwandeln des zugrunde liegenden DA-Systems, sodass die darin enthaltenen Daten so erscheinen, dass sie strukturell in einer typischen hierarchischen baumähnlichen Verzeichnisstruktur organisiert sind.

ZUSAMMENFASSUNG DER ERFINDUNG

Große DA-Systeme (Directory Assistance, Verzeichnisunterstützung) verwenden proprietäre Datenbankstrukturen mit proprietärem Zugriff, um Zugriffszeiten und das gesamte Skalieren von Millionen von Verzeichniseinträgen zu minimieren. Der moderne Trend zu einem offenen, auf Standards basierenden Zugriff auf Verzeichnisinformationen, der am Lightweight Directory Access Protocol (LDAP) veranschaulicht wird, zwingt die Operatoren von proprietären DA-Systemen, Parallelsysteme zu verwenden, wobei deren Implementierung und Unterhaltung teuer sein kann.

Ein System und ein Verfahren gemäß der erfindungsgemäßen Anordnung ermöglicht Operatoren von proprietären DA-Systemen, ein einzelnes DA-System zu implementieren und zu unterhalten, das infolge der vorliegenden Erfindung mehrere Zugriffstypen unterstützen kann.

Ein Verfahren zum Abbilden einer LDAP-Schnittstelle auf ein DA- System kann die folgenden Schritte enthalten. Erstens können LDAP-kompatible Suchargumente zum Durchsuchen einer LDAP- Datenbank aus einer LDAP-Anforderung extrahiert werden. Zweitens können die LDAP-kompatiblen Suchargumente in Suchargumente umgewandelt werden, die mit einer Datenbank des DA-Systems kompatibel sind. Drittens kann die Datenbank des DA-Systems unter Verwendung der umgewandelten Suchargumente abgefragt werden. Viertens kann als Antwort auf die Abfrage eine Ergebnismenge von Einträgen aus der Datenbank des DA-Systems empfangen werden. Schließlich kann die Ergebnismenge in eine LDAP-kompatible Ergebnismenge umgewandelt werden.

Vorzugsweise kann jeder der fünf Schritte in einem Plug-In zum LDAP-Server ausgeführt werden. Außerdem kann das Verfahren den Schritt des Empfangens der LDAP-Anforderung in einem LDAP-Client enthalten. Des Weiteren kann das Verfahren den Schritt des Empfangens einer LDAP-Anforderung in einem LDAP-Server umfassen.

In der bevorzugten Ausführungsart ist die LDAP-Anforderung ein LDAP-gefiltertes Attribut. Demzufolge kann in der bevorzugten Ausführungsart der Schritt des Umwandelns den Schritt des Abbildens von Suchargumenten in den gefilterten Attributen auf Suchargumente enthalten, die mit der Datenbank des DA-Systems kompatibel sind. Bemerkenswerterweise kann der Abbildungsschritt das Konsultieren einer Datenbank zur Standortauflösung umfassen, wobei jeder Eintrag in der Datenbank zur Standortauflösung einen Standort auf eine Menge von Standortkennungen abbildet, und wobei bei der Standortauflösung ein Datensatz in der Datenbank den Suchargumenten entsprechend identifiziert wird, sowie das Bilden einer Abfrageaussage für die Datenbank des DA-Systems anhand einer im identifizierten Datensatz angegebenen Menge von Standortkennungen enthalten. Außerdem kann die Menge von Standortkennungen wenigstens einen Bereichscode, ein Adressbuch oder einen Standort enthalten.

Ein System zum Abbilden einer LDAP-Schnittstelle auf ein DA- System kann die folgenden Komponenten enthalten: einen LDAP- Client zum Übertragen von LDAP-Anforderungen nach Verzeichnisinformationen; einen LDAP-Server zum Empfangen und Verarbeiten der LDAP-Anforderungen; ein DA-System zum Bereitstellen der Verzeichnisinformationen als Antwort auf mit dem DA-System kompatiblen Anforderungen nach Verzeichnisinformationen des DA-Systems, wobei die Verzeichnisinformationen des DA-Systems in einer Datenbank des DA-Systems gespeichert sind; und ein Plug-In, das mit dem LDAP- Server verbunden ist. Es ist kennzeichnend, dass das Plug-In die LDAP-Anforderungen empfangen kann, daraus die LDAP-kompatiblen Suchargumente zum Durchsuchen einer LDAP-Datenbank extrahieren kann und die LDAP-kompatiblen Suchargumente in Suchargumente umwandeln kann, die mit der Datenbank des DA-Systems kompatibel sind. Außerdem kann das Plug-In das DA-System mit den umgewandelten Suchargumenten abfragen, von diesem als Antwort auf die Abfrage eine Ergebnismenge von Einträgen empfangen, die Ergebnismenge in eine LDAP-kompatible Ergebnismenge umwandeln und die LDAP-kompatible Ergebnismenge zum LDAP-Server leiten. Schließlich kann der LDAP-Server die LDAP-kompatible Ergebnismenge dem LDAP-Client zur Verfügung stellen.

In der bevorzugten Ausführungsart ist die LDAP-Anforderung eine LDAP-kompatible Suche. Das Plug-In kann vorzugsweise die LDAP- kompatiblen Suchargumente in Suchargumente umwandeln, die mit der Datenbank des DA-Systems kompatibel sind, indem Suchargumente im gefilterten Attribut auf Suchargumente abgebildet werden, die mit der Datenbank des DA-Systems kompatibel sind. Wenn dies erfolgt, kann das System weiter eine Datenbank zur Standortauflösung enthalten, wobei die Abbildung durch die Datenbank zur Standortauflösung bestimmt ist und jeder Eintrag in der Datenbank zur Standortauflösung einen Standort auf eine Menge von Standortkennungen abbildet. Außerdem enthält die Menge von Standortkennungen wenigstens einen Bereichscode, ein Adressbuch oder einen Standort.

Das System kann ferner ein Datei-Aktualisierungsprogramm zum Laden der Standort- und Verzeichnisinformationen in die Datenbank des DA-Systems und einen Standortprozessor zum Erzeugen einer Ladedatei auf Grundlage der Standortinformationen enthalten. Bemerkenswerterweise kann die Ladedatei die Datenbank zur Standortauflösung mit dem Plug-In verbinden. Des Weiteren kann die Ladedatei auch eine LDAP-Datenbank mit dem Plug-In verbinden.

KURZBESCHREIBUNG DER ZEICHNUNGEN

Es werden in den Zeichnungen Ausführungsarten gezeigt, die gegenwärtig bevorzugt sind, wobei jedoch verständlich ist, dass die Erfindung nicht auf die genauen dargestellten Anordnungen und Ausrüstungen beschränkt ist.

Fig. 1 ist eine schematische Darstellung eines Computer- Kommunikationsnetzes, das ein DA-System, einen LDAP-Server und einen LDAP-Client verbindet.

Fig. 2 ist eine bildliche Darstellung eines Client-Computers, der geeignet ist, um einen LDAP-Client aufzunehmen.

Fig. 3 ist eine bildliche Darstellung eines zur Aufnahme eines LDAP-Servers geeigneten Serverrechners, der über das Computer- Kommunikationsnetz von Fig. 1 mit einem zur Aufnahme eines DA- Systems geeigneten Serverrechner verbunden ist.

Fig. 4 ist eine schematische Darstellung eines Systems zum Hinzufügen von Standorten zu einem DA-System mit Unterstützung der LDAP-Schnittstelle der erfindungsgemäßen Anordnung.

DETAILLIERTE BESCHREIBUNG DER ERFINDUNG

Eine LDAP-Schnittstelle zu einem DA-System kann eine in einem LDAP-Server integrierte Softwareschicht zur Verfügung stellen, die das LDAP-Schema an das proprietäre DA-System anpassen kann und umgekehrt. Genauer kann die LDAP-Schnittstelle die Daten, die im DA-System enthalten sind, in ein LDAP-Schema abbilden, sogar wenn das DA-System selbst nicht in einer baumähnlichen LDAP- Struktur organisiert ist. Folglich können Clients unter Verwendung einer Standard-LDAP-Schnittstelle auf das DA-System zugreifen, ohne die proprietäre Natur der Informationen preiszugeben oder die Sicherheit der DA-Daten zu verletzen.

Fig. 1 erläutert eine typische Netzumgebung 1, in der eine LDAP- Schnittstelle zu einem DA-System 18 betrieben werden kann. Diese Netzumgebung 1 enthält ein Computer-Kommunikationsnetz 10, das mehrere Clientrechner 12 und mehrere Server 14 verbindet, wobei der Server wenigstens eine LDAP-Serveranwendung 16 und wenigstens eine DA-Systemanwendung 18 enthält, obwohl in der Figur zur Einfachheit der Erläuterung lediglich ein einziger Client 12, ein einziger LDAP-Server 16 und ein einziges DA-System 18 gezeigt werden. Üblicherweise könnte die Netzumgebung 1 jedoch potentiell Millionen von Clients 12 und Tausende LDAP-Server 16 und DA- Systeme 18 enthalten.

Das Computer-Kommunikationsnetz 10 kann ein nicht öffentlich zugängliches Netz, wie ein LAN (local area network, Lokalnetz) oder ein WAN (wide area network, Fernnetz), oder vorzugsweise das Internet sein. Die Verbindungen zwischen den LDAP-Servern 16, den DA-Systemen 18 und den Clients 12 kann man sich als virtuelle Schaltungen vorstellen, die zum Zwecke der schnellen Kommunikation zwischen den LDAP-Servern 16, den DA-Systemen 18 und den Clients 12 aufgebaut werden. Im Betrieb können die Clients 12 über das Computer-Kommunikationsnetz 10 eine Verbindung mit einem LDAP-Server 16 herstellen, um eine Anforderung nach Daten, die im DA-System 18 gespeichert sind, zu übertragen. Die Daten können üblicherweise Daten sein, die die Telekommunikation betreffen, z. B. ein Verzeichniseintrag.

Wie in Fig. 1 dargestellt, enthält jeder Server 14 vorzugsweise einen Computer, der eine zentrale Verarbeitungseinheit (central processing unit, CPU) 26, eine interne Speichervorrichtung 24 wie einen Arbeitsspeicher (random access memory, RAM), einen Festspeicher 22 wie ein Festplattenlaufwerk (hard disk drive, HDD) enthält. Der Server 14 enthält außerdem eine Netzschnittstellenschaltung (network interface circuitry, NIC) 28 zur Kommunikationsverbindung des Servers 14 mit dem Computer- Kommunikationsnetz 10. Wahlweise kann der Server 14 ferner eine (nicht abgebildete) Tastatur und wenigstens eine (nicht abgebildete) Benutzerschnittstellen-Anzeigeeinheit wie ein Video- Anzeigeterminal (video display terminal, VDT) enthalten, die für den Zweck des Zusammenwirkens mit dem Server 14 mit diesem betriebsfähig verbunden sind. Die Erfindung ist jedoch in dieser Hinsicht nicht beschränkt. Vielmehr benötigt der Server 14 weder eine Tastatur noch ein VDT, um gemäß der erfindungsgemäßen Anordnungen zu arbeiten.

Wie dem Fachmann wohlbekannt ist, kann die CPU 26 jeden geeigneten Mikroprozessor oder eine andere elektronische Verarbeitungseinheit enthalten. Beispiele einer geeigneten CPU können einen Intel Pentium®-Prozessor, einen IBM PowerPC®- Prozessor oder einen AMD Athlon®-Prozessor enthalten. Der Festspeicher 22 kann ein Betriebssystem, z. B. IBM AIX® (nicht abgebildet), speichern. Außerdem kann dort, wo der Server 14 eine LDAP-Serveranwendung beinhaltet, der Festspeicher 22 eine LDAP- Serveranwendung 16 speichern, die LDAP-Anforderungen nach Verzeichnisinformationen verarbeiten kann. Dort, wo der Server 14 im Gegensatz ein DA-System beinhaltet, kann sich die DA- Systemanwendung 18 in ähnlicher Weise im Festspeicher 22 befinden. Überdies kann in der bevorzugten Ausführungsart die Datenbank 30 der Verzeichnisinformationen in einer Datenbank im Festspeicher 22 gespeichert sein, die Erfindung ist jedoch in dieser Hinsicht nicht beschränkt. Statt dessen kann die Datenbank eine verteilte Datenbank sein, die in einem Festspeicher irgendwo im Computer-Kommunikationsnetz 10 gespeichert ist. Außerdem ist die Erfindung nicht im Hinblick auf die Trennung der LDAP- Serveranwendung 16 von der DA-Systemanwendung 18 beschränkt. Statt dessen können sich beide in demselben Festspeicher 22 befinden und in demselben Server 14 ausgeführt werden.

In einem Serverrechner 14, der einen LDAP-Server 16 beinhaltet, kann der Festspeicher 22 ferner ein LDAP-Plug-In 20 zum LDAP- Server 16 speichern. Das LDAP-Plug-In 20 kann eine Funktion enthalten, um eine LDAP-Schnittstelle mit einem DA-System kommunikationstechnisch zu verbinden. In der bevorzugten Ausführungsart kann die Plug-In-Funktion durch einen Programmierer mit branchenüblichen Kenntnissen implementiert werden, indem wohlbekannte LDAP-Programmierungsverfahren unter Verwendung der Technologie einer Sprache der dritten Generation, wie z. B. ANSI C, verwendet werden. Diese Verfahren können in die Plug-In-Funktion unter Verwendung kommerziell verfügbarer Entwicklungswerkzeuge für die oben beschriebenen Betriebssysteme implementiert und eingeschlossen werden. Die Erfindung ist jedoch nicht durch die für das Implementieren des Plug-In verwendete Programmiersprachentechnologie beschränkt.

In Fig. 2 enthalten die Clients 12 in ähnlicher Weise wie der Server 14 vorzugsweise einen Computer mit einer CPU 32, einer internen Speichervorrichtung 34, einem Festspeicher 36 und einer Netzschnittstellen-Schaltungsanordnung 38, wie im Wesentlichen oben beschrieben wurde. In der bevorzugten Ausführungsart ist der Client 12 ein Personal Computer. Somit kann der Client 12 ferner eine Tastatur 40 und wenigstens eine Anzeigeeinheit 42 mit Benutzerschnittstelle, wie ein Video-Anzeigeterminal (VDT) enthalten, die für den Zweck des Zusammenwirkens mit dem Client 12 mit diesem betriebsfähig verbunden sind. Außerdem kann der Client 12 ferner eine Zeigereinheit 44 enthalten. Wie dem Fachmann wohlbekannt ist, kann die CPU 32 wie im Fall des Servers 14 einen geeigneten Mikroprozessor oder eine andere elektronische Verarbeitungseinheit enthalten. Beispiele einer geeigneten CPU können einen Intel Pentium-Prozessor, einen IBM PowerPC-Prozessor oder einen AMD Athlon-Prozessor enthalten.

Der Festspeicher 36 kann jeweils ein Betriebssystem 46 und eine Browseranwendung 48 für Hypermediadokumente zum Anzeigen von Hypermediadokumenten 50, z. B. Web-Seiten, speichern.

Vorzugsweise können sowohl das Betriebssystem 46 als auch die Browseranwendung 48 für Hypermediadokumente bei der Initialisierung in die interne Speichervorrichtung 34 geladen werden. Vorzugsweise ermöglicht die Browseranwendung 48 für Hypermediadokumente dem Client 12, Anforderungen für Hypermediadokumente 50 an Web-Server, die mit dem Computer- Kommunikationsnetz 10 kommunikationstechnisch verbunden sind, zu senden und von diesen zu empfangen. Außerdem kann der Browser für Hypermediadokumente das LDAP-Protokoll als ein LDAP-Client unterstützen. Deswegen kann der Browser 48 für Hypermediadokumente LDAP-Anforderungen nach Verzeichnisinformationen über das Computer-Kommunikationsnetz 10 zu den Servern 14 übertragen. In der bevorzugten Ausführungsart kann die Browseranwendung 48 für Hypermediadokumente ein LDAP- fähiger Web-Browser sein, z. B. der Netscape Communicator® oder der Microsoft Internet Explorer®.

Obwohl das Voranstehende eine bevorzugte Implementierung der Erfindung für ein von der International Business Machines Corporation hergestelltes DA-System beschreibt, das eine proprietäre Datenbank aufweist und als "Listing Services Inquiry Program for AIX" (LSIP) bezeichnet wird, ist die Erfindung nicht auf das IBM DA-System oder auf die LSIP-Abfrage-Datenbank beschränkt. Vielmehr wird das IBM DA-System nur als ein Beispiel eines proprietären DA-Systems zur Verwendung in der vorliegenden Erfindung dargestellt.

Im IBM DA-System ist die Datenbank 30 des DA-Systems eine LSIP- Abfrage-Datenbank, die unter Verwendung der Menge von LSIP- Standortkennungen eine hierarchische Sicht auf die Kundenstandorte enthält. Bemerkenswerterweise ist die LSIP- Abfrage-Datenbank eine unstrukturierte Datenbank. Als Folge der Verwendung der unstrukturierten LSIP-Abfrage-Datenbank liefert das Plug-In 20 bei der Umwandlung der LDAP-Anforderung in eine LSIP-kompatible Anforderung eine Umwandlung eines vollkommen verschiedenartigen Datenschemas in ein anderes. Insbesondere wird in der bevorzugten Ausführungsart das telefonbuchartige LDAP- Schema, das eine standortgestützte Baumstruktur enthält, in die proprietäre unstrukturierte LSIP-Abfrage-Datenbank umgewandelt und entsteht aus dieser. Die Umwandlungsebene des Plug-In 20 kann jedoch für den LDAP-Server das Aussehen einer virtuellen LDAP- Baumstruktur bei Abfrageergebnissen sowohl in Eingaberichtung als auch in Ausgaberichtung aufweisen.

Um diese Umwandlung auszuführen, kann das Plug-In 20 ein ankommendes LDAP-kompatibles Suchargument, das in einer LDAP- Anforderung enthalten ist, in das proprietäre LSIP-Format abbilden. In der bevorzugten Ausführungsart kann das LDAP- kompatible Suchargument beispielsweise ein standortgestützter registrierter Name (DN) sein. Zum Vergleich, eine LSIP- Anforderung kombiniert ein NPA (Bereichscode), Book (Buch, bezeichnet ein Hardcopy-Telefonbuch) und die Standortkennung Loc ID (spezieller Standort für die LSIP-Suche). Somit kann in einem Beispiel, das durch eine Eingabesuchbasis von "I=Boca Raton, I=Highland Beach Directory, st=FL, . . ., c=us" gegeben ist, das Plug-In 20 basierend auf NPA, Book und Loc ID diesen standortgestützten registrierten Namen (DN) in eine LSIP- Anforderung umwandeln, um eine Suche nach Einträgen auszuführen. Das Plug-In 20 kann die Werte NPA, Book und Loc ID ableiten, indem sie aus dem Eingabe-DN Suchargumente für die Abfrage einer LSIP-Datenbank zur Standortauflösung zusammensetzt. Eine LSIP- Datenbank zur Standortauflösung kann ein Feld "Caption Set Level (Tabellenkopf, Ebene)", ein Feld "Search/Display Name (Name suchen/anzeigen)", ein Feld "Alternate Finding Name (Alternativer Suchbegriff)" und ein Feld "Locality ID Set (Standortkennung) enthalten. Die Suchabfrage der LSIP-Datenbank zur Standortauflösung kann Werte für NPA, Book und Loc ID ergeben, die verwendet werden, um eine normale LSIP-Abfrage von Einträgen auszuführen.

In Fig. 3 kann die LDAP-Serveranwendung 16 im Betrieb LDAP- Anforderungen von Clients 12 akzeptieren, um übertragene Anforderungen nach Daten, die in der Datenbank 30 des DA-Systems gespeichert sind, auszuführen. Genauer können LDAP-Anforderungen über das Computer-Kommunikationsnetz 10 in der Netzschnittstellen-Schaltungsanordnung 28A empfangen werden. Die Netzschnittstellen-Schaltungsanordnung 28A kann die LDAP- Anforderungen zum (nicht abgebildeten) Betriebssystem leiten, das wiederum die LDAP-Anforderungen zu der LDAP-Serveranwendung 16 leiten kann, die im Festspeicher 22A gespeichert ist und im Speicher 24A ausgeführt wird. Anschließend kann das LDAP-Plug-In 20 die Anforderung empfangen und diese in eine Abfrage umwandeln, die von der DA-Systemanwendung 18 erkannt werden kann.

Das Plug-In 20 kann die zum DA-System kompatible Anforderung zur DA-Systemanwendung 18 übertragen. Genauer kann das Plug-In 20 die Anforderung unter Verwendung des TCP/IP-Kommunikationsprotokolls zum (nicht abgebildeten) Betriebssystem leiten, das wiederum die Anforderung über die Netzschnittstellen-Schaltungsanordnung 28A zum Computer-Kommunikationsnetz 10 leiten kann. Die zum DA-System kompatiblen Anforderungen können über das Computer- Kommunikationsnetz 10 in der Netzschnittstellen- Schaltungsanordnung 28B empfangen werden. Die Netzschnittstellen- Schaltungsanordnung 28B kann die LDAP-Anforderungen zum (nicht abgebildeten) Betriebssystem leiten, das wiederum die LDAP- Anforderungen zur DA-Systemanwendung 18, die im Festspeicher 22B gespeichert ist und im Speicher 24B ausgeführt wird, leiten kann.

Anschließend kann die DA-Systemanwendung 18 eine Suche in der Datenbank 30 gemäß der Abfrage ausführen und die Ergebnismenge über das Plug-In 20 an die LDAP-Serveranwendung 16 zurückgeben. Genauer kann die DA-Systemanwendung 18 die Ergebnismenge unter Verwendung des TCP/IP-Kommunikationsprotokolls zum (nicht abgebildeten) Betriebssystem leiten, das wiederum die Anforderung über die Netzschnittstellen-Schaltungsanordnung 28B an das Computer-Kommunikationsnetz 10 übertragen kann. Die Ergebnismenge kann über das Computer-Kommunikationsnetz 10 in der Netzschnittstellen-Schaltungsanordnung 28A empfangen werden. Die Netzschnittstellen-Schaltungsanordnung 28A kann die Ergebnismenge zum (nicht abgebildeten) Betriebssystem leiten, das wiederum die Ergebnismenge zum Plug-In 20 leiten kann. Das Plug-In 20 kann wiederum die zum DA-System kompatible Ergebnismenge in ein LDAP- kompatibles Format umwandeln und dieses zur LDAP-Serveranwendung 16 leiten. Die LDAP-Serveranwendung 16 kann daraufhin die Ergebnismenge zum anfordernden LDAP-Client übertragen, der sich im Client 12 befindet und dort ausgeführt wird.

Nach dem Umwandeln der LDAP-Anforderung kann das Plug-In 20 die umgewandelte zum DA-System kompatible Anforderung, z. B. eine LSIP-Anforderung, zum DA-System 18 übertragen. Genauer kann das Plug-In 20 die Anforderung unter Verwendung des TCP/IP- Kommunikationsprotokolls zum (nicht abgebildeten) Betriebssystem leiten, das wiederum die Anforderung über die Netzschnittstellen­ Schaltungsanordnung 28A an das Computer-Kommunikationsnetz 10 übertragen kann. Die zum DA-System kompatiblen Anforderungen können im DA-System 18 über das Computer-Kommunikationsnetz 10 und über die Netzschnittstellen-Schaltungsanordnung 28B empfangen werden. Genauer kann die Netzschnittstellen-Schaltungsanordnung 28B die Datenpakete empfangen, die die zum DA-System kompatiblen Anforderungen enthalten, und kann die zum DA-System kompatiblen Anforderungen zur DA-Systemanwendung 18, die im Festspeicher 22B gespeichert ist und im Speicher 24B ausgeführt wird, leiten.

Anschließend kann das DA-System 18 eine Durchsuche der Datenbank 30 gemäß der zum DA-System kompatiblen Anforderung ausführen. Wenn die Einträge von der Datenbank 30 erhalten werden, kann eine Ergebnismenge erzeugt werden. Zum Beispiel können im Fall des IBM DA-Systems dann, wenn die Einträge von der LSIP-Abfragedatenbank erhalten werden, jeweils die Werte von NPA, Book und Loc, die einem übereinstimmenden Eintrag entsprechen und in jedem übereinstimmenden Datensatz enthalten sind, als eine Ergebnismenge zurückgegeben werden. Das DA-System 18 kann die Ergebnismenge unter Verwendung des TCP/IP- Kommunikationsprotokolls zum (nicht abgebildeten) Betriebssystem übertragen, das wiederum die Anforderung über die Netzschnittstellen-Schaltungsanordnung 28B an das Computer- Kommunikationsnetz 10 übertragen kann. Die Ergebnismenge kann über das Computer-Kommunikationsnetz 10 in der Netzschnittstellen-Schaltungsanordnung 28A empfangen werden. Die Netzschnittstellen-Schaltungsanordnung 28A kann die Ergebnismenge zum (nicht abgebildeten) Betriebssystem übertragen, das wiederum die Ergebnismenge zum Plug-In 20 leiten kann. Es ist bedeutsam, dass das Plug-In 20 wiederum die zum DA-System kompatible Ergebnismenge in ein LDAP-kompatibles Format umwandeln kann und dieses zu einer LDAP-Serveranwendung 16 leiten kann. Das heißt, die Ergebnismenge kann zurück in einen registrierten Namen (DN) für LSIP-gestützte Einträge umgewandelt werden, um einen relativen Standort der Ergebnismenge in der virtuellen LSAP- Baumstruktur anzuzeigen. Die LDAP-Serveranwendung 16 kann daraufhin die Ergebnismenge zum anfragenden LDAP-Client übertragen, der sich im Client 12 befindet und dort ausgeführt wird.

Fig. 4 erläutert ein bevorzugtes Verfahren zum Implementieren einer LDAP-Schnittstelle in einem DA-System. Um die Standorte der Kundendaten in geeigneter Weise darzustellen, kann in gegenwärtigen DA-Systemen eine geografische Darstellung definiert werden, um alle Standorte mit den Einträgen eines Kunden einzuschließen. Dieser Vorgang kann durch einen Vorgang 54 eines Datei-Aktualisierungsprogramms (File Update Program, FUP) ausgeführt werden. In der vorliegenden Erfindung kann dem FUP- Vorgang 54 ein zusätzlicher Schritt zum Laden der Kundendaten angefügt werden. Genauer kann der zusätzliche Schritt sowohl die Erzeugung der auf den LDAP-Standort basierten Organisation der Verzeichnisinformationen als auch der auf den LSIP-Standort basierten Organisation von Verzeichnisinformationen unterstützen. Um das eine auf dem anderen abzubilden, muss ferner die Datenbank 70 zur Standortauflösung erzeugt werden.

Beim Empfang einer Standorteingabe 52 und möglicherweise einer weiteren Eingabe 58 kann der FUP-Prozess 54 die Standorte 60, die Domains 62 und die Einträge 64 jeweils in der LocMenu-Datenbank 68, in der Domain-Datenbank 66 bzw. in der LSIP-Abfrage-Datenbank 30 aktualisieren. Außerdem kann ein Standort-Prozessor 56 die vorhandenen Standort- und Domain-Informationen 60, 62, die in den vorhandenen Datenbanken 66, 68 gespeichert sind, verwenden, um sowohl für LSIP als auch für das LDAP Ladedateien zu bilden. Vorzugsweise werden alle Standorte des Kunden in den Standort- Prozessor 56 eingegeben, der eine Domain/Standort-Ladedatei 72 erzeugen kann, die das Zwischenaufzeichnungsformat (Intermediate Record Format, IRF) 76 und das LDAP-Verzeichnisinformationsformat (LDAP Directory Information Format, LDIF) 74 parallel handhaben kann.

Bemerkenswerterweise wird das LDIF 74 vorzugsweise lediglich dann verwendet, wenn der Kunde erweiterte Einträge aufweist, die sich im Gegensatz zur LSIP-Datenbank 30 in einer aktuellen "wahren" LDAP-Verzeichnisdatenbank 40 befinden. LDIF 74 kann eine von oben nach unten gerichtete standortgestützte Hierarchie der Einträge enthalten. Somit könnte dann, wenn ein Knoten oder ein registrierter Name (DN) im Verzeichnis "cn=John Doe, I=Boca Raton Window, I=Highland Beach Directory, st=FL, . . ., c=us" enthält, eine entsprechende LDIF-Darstellung Folgendes umfassen:

Da die Einträge von dieser Standorthierarchie in deren registrierten Namen abhängen, wird vorzugsweise eine LDIF-Datei der Standorte für den Kunden als Voraussetzung für das Laden der tatsächlichen Datensätze geladen.

In ähnlicher Weise kann das IRF eine Hierarchie von Standorten, die in der LSIP-Datenbank 70 zur Standortauflösung indiziert sind, darstellen. Das IRF kann z. B. die folgende Hierarchie der in der Datenbank 70 zur Standortauflösung gespeicherten Standorte darstellen:

Zusammenfassend sind in der bevorzugten Ausführungsart der vorliegenden Erfindung die Standorte eines Kunden vorzugsweise in zwei Formaten, (1) IRF für das Laden der LSIP-Abfrage-Datenbank 70 und (2) LDIF für das Laden der LDAP-Datenbank 40, dargestellt, wenn der Kunde erweiterte Einträge besitzt, die sich nicht in der LSIP-Abfrage-Datenbank 70 befinden.

Claims (22)

1. Verfahren zum Abbilden einer LDAP-Schnittstelle (Lightweight Directory Access Protocol, einfaches Verzeichniszugriffsprotokoll) auf ein DA-System (Directory Assistance, Verzeichnisunterstützung), das die folgenden Schritte umfasst:

• a) Extrahieren von LDAP-kompatiblen Argumenten aus einer LDAP-Anforderung zum Durchsuchen einer LDAP-Datenbank;
• b) Umwandeln der LDAP-kompatiblen Argumente in Suchargumente, die mit einer Datenbank des DA-Systems kompatibel sind;
• c) Abfragen der Datenbank des DA-Systems mit den umgewandelten Suchargumenten;
• d) Empfangen einer Ergebnismenge von Einträgen aus der Datenbank des DA-Systems als Antwort auf die Abfrage; und
• e) Umwandeln der Ergebnismenge in eine LDAP-kompatible Ergebnismenge.

2. Verfahren gemäß Anspruch 1, das ferner den folgenden Schritt umfasst:
Empfangen der LDAP-Anforderung von einem LDAP-Client.

3. Verfahren gemäß Anspruch 1, das ferner den folgenden Schritt umfasst:
Empfangen der LDAP-Anforderung in einem LDAP-Server.

4. Verfahren gemäß Anspruch 1, bei dem die LDAP-Anforderung ein LDAP-gefilteres Attribut enthält.

5. Verfahren gemäß Anspruch 4, bei dem der Schritt des Umwandelns den folgenden Schritt umfasst:
Abbilden von Suchargumenten in dem gefilterten Attribut auf Suchargumente, die mit der Datenbank des DA-Systems kompatibel sind.

6. Verfahren gemäß Anspruch 5, bei dem der Schritt des Abbildens die folgenden Schritte umfasst:
Konsultieren einer Datenbank zur Standortauflösung, wobei jeder Datensatz in der Datenbank zur Standortauflösung einen Standort auf eine Menge von Standortkennungen abbildet;
Identifizieren eines den Suchargumenten entsprechenden Datensatzes in der Datenbank zur Standortauflösung; und
Bilden einer Abfrageanweisung für die Datenbank des DA- Systems mit einer Menge von Standortkennungen, die in dem identifizierten Datensatz enthalten ist.

7. Verfahren gemäß Anspruch 6, bei dem die Menge von Standortkennungen wenigstens einen Bereichscode, ein Telefonbuch oder einen Ort umfasst.

8. Verfahren gemäß Anspruch 3, bei dem jeder der Schritte a) bis e) in einem Plug-In zum LDAP-Server ausgeführt wird.

9. System zum Abbilden einer LDAP-Schnittstelle auf ein DA- System, das Folgendes umfasst:
einen LDAP-Client zum Übertragen von LDAP-Anforderungen nach Verzeichnisinformationen;
einen LDAP-Server zum Empfangen und Verarbeiten der LDAP- Anforderungen;
ein DA-System zum Bereitstellen von Verzeichnisinformationen als Antwort auf zum DA-System kompatible Anforderungen nach den Verzeichnisinformationen des DA-Systems, wobei die Verzeichnisinformationen des DA-Systems in einer Datenbank des DA-Systems gespeichert sind; und
ein Plug-In, das mit dem LDAP-Server verbunden ist, wobei das Plug-In die LDAP-Anforderungen empfängt, aus den LDAP- Anforderungen LDAP-kompatible Suchargumente zum Durchsuchen einer LDAP-Datenbank extrahiert, die LDAP-kompatiblen Suchargumente in Suchargumente umwandelt, die mit der Datenbank des DA-Systems kompatibel sind, das DA-System mit den umgewandelten Suchargumenten abfragt, eine Ergebnismenge von Einträgen von dem DA-System als Antwort auf die Abfrage erhält, die Ergebnismenge in eine LDAP-kompatible Ergebnismenge umwandelt, und die LDAP-kompatible Ergebnismenge zum LDAP-Server leitet, wobei der LDAP-Server die LDAP-kompatible Ergebnismenge dem LDAP-Client bereitstellt.

10. System gemäß Anspruch 9, bei dem die LDAP-Anforderung ein registrierter Name ist.

11. System gemäß Anspruch 10, bei dem das Plug-In die LDAP- kompatiblen Suchargumente in Suchargumente umwandeln kann, die mit der Datenbank des DA-Systems kompatibel sind, indem Suchargumente in dem registrierte Namen auf Suchargumente abgebildet werden, die mit der Datenbank des DA-Systems kompatibel sind.

12. System gemäß Anspruch 11, das ferner eine Datenbank zur Standortauflösung enthält, bei dem die Abbildung durch die Datenbank zur Standortauflösung bestimmt ist, wobei jeder Datensatz der Datenbank zur Standortauflösung einen Standort auf eine Menge von Standortkennungen abbildet.

13. System gemäß Anspruch 12, bei dem die Menge von Standortkennungen wenigstens einen Bereichscode, ein Telefonbuch oder einen Ort umfasst.

14. System gemäß Anspruch 12, das ferner Folgendes umfasst:
ein Datei-Aktualisierungsprogramm zum Laden von Standort- und Verzeichnisinformationen in die Datenbank des DA-Systems; und
einen Standortprozessor zum Erzeugen einer Ladedatei, die auf den Standortinformationen basiert, wobei die Ladedatei die Datenbank zur Standortauflösung mit dem Plug-In verbindet.

15. System gemäß Anspruch 14, bei dem die Ladedatei ferner eine LDAP-Datenbank mit dem Plug-In verbindet.

16. Maschinenlesbare Speichervorrichtung, in der ein Computerprogramm gespeichert ist, das mehrere Codeabschnitte zum Abbilden einer LDAP-Schnittstelle auf ein DA-System aufweist, wobei die Codeabschnitte durch eine Maschine ausführbar sind, um zu bewirken, dass die Maschine die folgenden Schritte ausführt:

• a) Extrahieren von LDAP-kompatiblen Suchargumenten aus einer LDAP-Anforderung zum Durchsuchen einer LDAP-Datenbank;
• b) Umwandeln der LDAP-kompatiblen Suchargumente in Suchargumente, die mit einer Datenbank des DA-Systems kompatibel sind;
• c) Abfragen der Datenbank des DA-Systems mit den umgewandelten Suchargumenten;
• d) Empfangen einer Ergebnismenge von Einträgen aus der Datenbank des DA-Systems als Antwort auf die Abfrage; und
• e) Umwandeln der Ergebnismenge in eine LDAP-kompatible Ergebnismenge.

17. Maschinenlesbare Speichervorrichtung gemäß Anspruch 16, die ferner bewirkt, dass die Maschine den folgenden Schritt ausführt:
Empfangen der LDAP-Anforderung von einem LDAP-Client.

18. Maschinenlesbare Speichervorrichtung gemäß Anspruch 16, die ferner bewirkt, dass die Maschine den folgenden Schritt ausführt:
Empfangen der LDAP-Anforderung in einem LDAP-Server.

19. Maschinenlesbare Speichervorrichtung gemäß Anspruch 16, wobei die LDAP-Anforderung ein registrierter LDAP-Name ist.

20. Maschinenlesbare Speichervorrichtung gemäß Anspruch 19, wobei der Schritt des Umwandelns den folgenden Schritt umfasst:
Abbilden der Suchargumente in dem registrierten Namen auf Suchargumente, die mit der Datenbank des DA-Systems kompatibel sind.

21. Maschinenlesbare Speichervorrichtung gemäß Anspruch 20, wobei der Schritt des Abbildens die folgenden Schritte umfasst:
Konsultieren einer Datenbank zur Standortauflösung, wobei jeder Datensatz in der Datenbank zur Standortauflösung einen Standort auf eine Menge von Standortkennungen abbildet;
Identifizieren eines den Suchargumenten entsprechenden Datensatzes in der Datenbank zur Standortauflösung; und
Bilden einer Abfrageanweisung für die Datenbank des DA- Systems mit einer Menge von Standortkennungen, die in dem identifizierten Datensatz enthalten ist.

22. Maschinenlesbare Speichervorrichtung gemäß Anspruch 21, wobei die Menge von Standortkennungen wenigstens einen Bereichscode, ein Telefonbuch oder einen Ort umfasst.