Nachdem die globale Struktur des Internet mehr und mehr von normalen Anwendern genutzt wird, nimmt das leichte Auffinden von Informationen einen immer höheren Stellenwert ein. Sogenannte Verzeichnisdienste sollen Informationen verschiedenster Natur auch ohne Kenntnis von URLs benutzerfreundlich auffinden. Mit dem "Lightweight Directory Access Protocol" (LDAP) als am weitesten verbreitetem Protokoll und dem "Internet Locator Service" (ILS) stehen interessante Techiken für diese Aufgabe zur Verfügung.
Ordnung durch Protokolle
Das W3 ist letztlich nichts anderes als eine große Menge von Servern mit einer extrem großen Anzahl von Dateien. Diese sind zum Großteil vom Benutzer als Informationsseiten via Browser anzuzeigen. In den Dateien können wiederum Verweise (Hyperlinks) auf andere Dateien untergebracht sein, die unter Umständen auf anderen Servern liegen.
Zu identifizieren sind Daten nur über den URL, der im Grunde nichts anderes als eine Kombination aus Servername und einem modifizierten Dateinamen ist. Weitere Ordnungsinformationen sind erst einmal nicht verfügbar.
Solange es nur eine vergleichsweise kleine Anzahl an thematisch organisierten Servern im universitären Bereich gab und man wußte, wo man einsteigen muß, um an Informationen zu gelangen, war der systematische Aufbau von Recherchen recht überschaubar und einfach.
Unüberschaubare Informationsvielfalt im Internet
Heute beweist der praktische Einsatz, daß Daten nicht zwangsläufig Information und Informationen nicht unbedingt Wissen bedeuten. Der mehr oder weniger unbedarfte Versuch, zu einem Thema Informationen zu finden, führt recht schnell in die Datenwüste. Wer nicht zufällig oder durch "Mundpropaganda" einen Server mit verwertbaren Informationen und Verweisen findet, bemüht meist einen der diversen Internet-Suchdienste, die mit dem explosiven Wachstum des Internet Verbreitung gefunden haben. Als Beispiel führt dann die Suche des Studenten der griechischen Geschichte nach dem Stichwort "Orakel" zu 1100 Einträgen. Viel Zeit geht ins Land, bis er dort die gesuchten Informationen findet, aber er stößt immerhin auf "motivationsfördernde" Informationsseiten der Art "Nicht die Antwort ist das Ziel, sondern die Suche nach der Frage."
Natürlich ist es möglich, durch geeignete Anwendung dieser Suchmaschinen auch selektive Informationen aus dem Internet zu gewinnen, aber letztlich bleibt das Kernproblem des klassischen "Spider"-Ansatz dieser Dienste, daß quasi blind und ohne Kenntnis der Semantik Stichworte von allen weltweit erreichbaren Web-Seiten indiziert werden.
Suchdienste im Kampf gegen den Datendschungel
Ein anderes Problem bei der Daten-Recherche ist es, der Schwemme an neuen Informationen zeitnah folgen zu können. Informationen sind oftmals veraltet und belasten die Index- und Datenbasis.
Neben diesem ganz allgemeinen Problem der Schaffung von höheren Organisationsebenen für die Informationen im W3 entstand in der jüngeren Vergangenheit auch Bedarf nach einem Protokoll- und Dienstsystem für Anwendungen im Bereich des Workgroup-Computing. Beispielsweise wird für Konferenzsysteme ein Verfahren benötigt, welches mehreren Anwender ermöglicht, gleichzeitig miteinander zu kommunizieren, um etwa zusammen an einen Dokument zu arbeiten.
Dies ist nicht einfach mit mehreren Peer-to-Peer-artigen Verbindungen der Benutzer zu lösen, da diese dafür die IP-Nummern ihrer Partner wissen müßten. Der normale Anwender kennt jedoch seine IP-Nummer überhaupt nicht, und zudem ist es bei dynamischer Adreßvergabe auch üblich, daß diese Nummern im Laufe der Zeit variieren. Dieses ist beispielsweise in Netzwerken mit DHCP-Servern der Fall sowie bei Kunden, die sich bei Internet-Providern einwählen, die Adressen via IP-Sharing verteilen.
Ein zentraler Verzeichnis-Server tut also not, der, von statischen Benutzerinformationen wie Namen oder E-Mailadressen abgeleitet, die IP-Verbindungen vermitteln kann.
Zusätzlich zu dieser Zentralisierung von Informationen ist im Zeitalter von Multimedia aber auch gefragt, daß die Informationen, die hinter den Einträgen eines Verzeichnisservers abgelegt werden können, möglichst flexibel strukturiert sind. Es geht also nicht nur darum, adreßbuchartige Systeme verwalten zu können, sondern schon der Verzeichnisdienst soll Ablagemöglichkeiten für die verschiedensten Daten bieten. Es ist ja nicht ausgeschlossen, daß solche Systeme auch verwendet werden, um Autorisierungsverfahren mit Sprachproben und -erkennung oder Marketingverzeichnisse mit Real-Video-Clips von Künstlern zu verwalten.
Aber auch die Nutzung als reine Multimedia-Datenbank soll offenstehen, unabhängig von irgendwelchen Personendaten.
Die Thematik Verzeichnisdienste ist so alt wie große Netzwerke. Entsprechend gab es in der Vergangenheit verschiedene Ansätze der Hersteller. Zu nennen sind beispielsweise der "Network Information Service" oder (NIS) beziehungsweise "NIS+" von Sun und "NDS" von Novell. Es gab auch 1996 Kooperationsüberlegungen dieser beiden Hersteller für eine wechselseitige Integration beider Protokolle, was aber bis heute keine praktischen Konsequenzen gebracht hat. NDS hätte diverse Probleme von NIS/NIS+ lösen können, beispielsweise im Bereich Administration und Integration. Novells "Novell Delivers Enhanced Directory Solution" oder kurz NDS ist von den Entwicklern aber nicht angenommen worden, so daß Sun immer noch mit dem proprietären NIS/NIS+ arbeitet.
LDAP als gemeinsames Protokoll
Das Internet mit seiner eigenen Dynamik hat glücklicherweise wenig Rücksicht auf herstellerspezifische Durchsetzungswünsche genommen. Schon seit längerem kristallisiert sich LDAP als der gemeinsame Nenner heraus. Dieses Protokoll ist mittlerweile auch von Sun angenommen worden und wird von Microsoft sogar recht aggressiv forciert. Auch Netscape war an der Definition dieses Protokolls maßgeblich beteiligt.
Entworfen wurde LDAP von der University of Michigan und der Internet Engineering Task Force (IETF). Die IETF ist eine Gruppe, die sich aus den verschiedensten unabhängigen Software-Entwicklern, Netzwerkingenieuren und Mitgliedern verwandter Berufssparten, aber auch Vertretern der Unternehmen in der Branche zusammensetzt. Das LDAP-Protokoll wird bei der IETF von der Arbeitsgruppe für "Access, Searching and Indexing of Directories" (Asid) betreut. Unter den in der Info-Box genannten URLs sind Informationen zu LDAP inklusive Protokollerweiterungen und zu verschiedenen Programmierschnittstellen abrufbar. Ohne an dieser Stelle allzu tief auf die Details dieses Protokolls eingehen zu können, sei der allgemeine Aufbau von LDAP beziehungsweise der verfügbaren C-API kurz beschrieben.
LDAP-Wurzeln und -Wege
Mit LDAP können Front-ends für X.500-Directory-Server oder für spezielle LDAP-Server realisiert werden. Dabei hat man es mit einem typischen Client/Server-Protokoll zu tun, bei dem der Client eine TCP-Verbindung über Port 389 zum Server herstellt und mit diesem per Anfrage/Antwort-Sequenzen kommuniziert.
Die größte Dateneinheit bei LDAP ist der "Eintrag" (Entry), welcher Informationen über ein Objekt enthält. Typisches Beispiel eines Objektes für die klassische Anwendung von Verzeichnisdiensten ist eine Person. Solch ein Eintrag hat "Eigenschaften" (Attributes), die einen Tip und einen oder mehrere Werte haben. Für jedes dieser Attribute ist eine Syntax definiert, die zum einen beschreibt, welche Wertetypen für dieses Attribut erlaubt sind (Ascii, numerisch, Bilddateien, Videos, Sound, et cetera). Zum anderen beschreibt die "Syntax", wie sich ein solches Attribut bei Verzeichnisoperationen wie zum Beispiel Suchen verhält. Dabei kann es um vergleichsweise einfache Dinge wie landesspezifische Vergleichsoperationen bei der Textsuche gehen, aber auch um komplexe Aufgaben wie die Interpretation von multimedialen Daten. Theoretisch wäre es möglich, ein Verzeichnis zu organisieren, das auch eine Suche in grafischen Daten ermöglicht.
Einträge können baumartig organisiert werden. Für das klassische Beispiel des Personenverzeichnisses basieren solche Bäume häufig auf geografischen, politischen oder organisationszentrierten Abgrenzungen, was aber willkürlich ist. Innerhalb jeder Ebene ist jeder Eintrag durch seinen sogenannten "Relative Distinguished Name" (RDN) eindeutig namentlich gekennzeichnet. Für die Erzeugung dieses RDN werden ein oder mehrere Attribute verwendet. Von jedem Attribut kann höchstens ein Wert verwendet werden. Beispielsweise würde für den Eintrag "Karl Heinz Müller" eines Personen-Verzeichnis das Attribut "Rufname" mit dem Wert "Karl Müller" verwendet.
Ein global einheitlicher Name für einen Eintrag wird durch die Verknüpfung der RDN, ausgehend von der Wurzel des Verzeichnisses, konstruiert. Falls Karl Müller für die Technische Universität Dresden arbeiten würde, könnte sein "Distinguished Name" (DN) etwa "cn=Karl Müller, o=Technische Universität Dresden, c=Deutschland" lauten. Eine ausführliche Spezifikation des DN-Formats findet sich gleichfalls auf den Servern der IETF unter den in der Infobox genannten URLs.
Basierend auf dieser Struktur ist eine C-API für Clientanwendungen verfügbar. Diese API ist einfach, gleichzeitig aber auch flexibel und leistungsfähig. Für die allgemeinen Fälle arbeiten die Funktionsaufrufe mit Default-Einstellungen, können über zusätzliche Parameter aber auch beliebig spezielle Fälle bedienen. Das schematische Vorgehen von LDAP-Anwendungen sieht folgendermaßen aus:
- Über die Funktion ldap_init() wird eine Session mit einem LDAP-Server gestartet und ein Handle zurückgegeben.
- Durch ldap_bind() oder eine der verwandten Funktionen authentifiziert sich der Benutzer gegenüber dem Server.
- Mit ldap_search() oder einer verwandten Funktion können LDAP-Operationen ausgeführt werden. Sowohl Ergebnisse als auch Fehlercodes werden mittels einer universellen Datenstruktur zurückgegeben. Diese kann dann - ähnlich Operationen in Dateiverzeichnissen - mit ldap_first_entry(), ldap_next_ entry() traversiert werden. Für Fehlerüberprüfungen steht unter anderem ldap_result2error() zur Verfügung.
- Last, but not least wird mit ldap_unbind() eine Session geschlossen.
An sich also eine einfache API, wobei aber die Komplexität diverser Protokolldetails nicht unterschätzt werden sollte. Die "höheren Weihen" wie Syntax für Attribute und ähnliches fordern doch längere Einarbeitung, und die Handhabung ist gelegentlich etwas garstig, da man es häufig mit Verweisen der Form "Zeiger auf Strukturen mit Zeigern auf Strukturen mit ..." zu tun hat.
ILS kontra LDAP-Server
Nachdem Microsoft erheblichen Aufwand für die Entwicklung von Software- und Systemstrukturen für den Internet-Bereich getrieben hat, spielt das Unternehmen auch im Bereich der Internet-Verzeichnisdienste eine nicht zu unterschätzende Rolle. Passend zur Workgroup-Computing-Software "Netmeeting" existiert auch ein Server namens "Internet Locator Service" (ILS), der kostenlos kopiert und auf NT-Servern installiert werden kann.
Natürlich erst einmal spezialisiert auf die Anwendung, sprich die Bevorratung von Benutzerdaten, ist der ILS ein offenes System, das von beliebigen LDAP-fähigen Clients benutzt werden kann. Dabei hat man es auch nicht mit einer kleinen Lösung nur für Intranets zu tun, sondern mit einer im hohen Maße skalierbaren Serverarchitektur. Als Anwender sollte man sich auch nicht davon täuschen lassen, daß die angezeigten Informationen denen des Windows-Adreßbuches sehr ähnlich sind. Es verwaltet statische Daten, die auf den Festplatten von Clientcomputern liegen. Die Daten in einem ILS-Server sind dagegen dynamisch.
Wenn man sich mit einem ILS-Server verbindet, werden als erstes die eigenen Informationen aktualisiert, unter anderem natürlich die IP-Nummer, die der Server für die Verbindungsvermittlung benötigt. Großen Wert legt Microsoft auf die Integration des ILS mit NT-Server als Betriebssystem. Insbesondere die Vorteile im Bereich Administration und Sicherheit werden stark hervorgehoben. In Zusammenarbeit mit Microsofts Netmeeting als Client hat der ILS dabei diverse weitere Fähigkeiten. Beispielsweise ist direkt sichtbar, ob der gewünschte Ansprechpartner online ist.
Integration und NetmeetingFunktionen
Protokolle und Standards sind natürlich wenig wert, wenn sie nicht von Programmierern und Anwendern unterstützt werden. Deshalb hat Microsoft einige Anstrengungen unternommen, um die Integration von Netmeeting-Funktionen in selbstentwickelten Anwendungen zu vereinfachen.
Microsoft bietet kostenlos das Netmeeting SDK an, das alle Programmierschnittstellen des Neetmeeting-Systems zur Verfügung stellt und dokumentiert. Dort ist auch das Netmeeting-ActiveX-Control enthalten, das in bewährter - und von Microsoft propagierter - Manier mit COM-Schnittstellen die diversen Routinen des Netmeeting-Systems kapselt.
Die Funktionsskizze des Netmeeting-Systems (Bild 2) zeigt dabei, daß der Part ILS innerhalb des Gesamtsystems natürlich nur eine kleine Rolle spielt. Die eigentliche Arbeit von Netmeeting fängt erst dann an, wenn die Anwender-Anwender-Verbindung schon ermittelt wurde. Aber auch die ILS-Schnittstelle ist schon recht umfangreich, so daß sie vom Netmeeting-ActiveX-Control in sechs COM-Objekten abgebildet wird, beziehungsweise, um exakt im Microsoft-Terminus zu bleiben, in sechs COM-Interfaces.
Im Vergleich zur LDAP-C-API findet man eine stärkere Kapselung der Interna von LDAP vor, was die Arbeit etwas sicherer und komfortabler macht. Voraussetzung ist allerdings, daß man sich mit der COM/ActiveX-Architektur schon einmal auseinandergesetzt hat. Deshalb werden Entwickler, die auf Microsoft-Plattformen zuhause sind, wohl die ActiveX-Schnittstelle zum ILS verwenden, während Entwickler, die auf anderen Plattformen arbeiten, eher die C-API - nicht zu verwechseln mit CAPI - anwenden werden.
Es macht aber einen gewissen Sinn, sich jetzt schon mit der ActiveX-Schnittstelle auseinanderzusetzen. Verzeichnis-Dienste werden in der nächsten Version von Windows NT eine große Rolle spielen. Dort werden diese Schnittstellen mit im Active-Directory-System von NT 5.0 integriert werden.
So oder so wird die Zukunft des Internet noch stärker von Kommunikation und Information geprägt werden, als es heute schon der Fall ist. LDAP-Server, ob sie nun ILS oder anders heißen, stellen eine hervorragende Möglichkeit dar, um zum einen die Möglichkeiten von "Teamwork"-Anwendungen deutlich zu verbessern. Zum anderen ist es auf jeden Fall eine Überlegung wert, ob für die Ablage von strukturierten Informationen ein vorhandener LDAP-Server nicht eine bessere Wahl darstellen kann als die proprietäre Eigenentwicklung einer Serverdatenbank. (us)
Web-Links
Informationen der "Internet Engineering Task Force":
http://www.ietf.org
Informationen zu "Access, Searching and Indexing of Directories" (Asid):
http://www.ietf.org/html.charters/asid-charter.html
LDAP-Versionsunterschiede:
http://msdn.microsoft.com/library/sdkdoc/ldap/ld-intro_1rzn.htm
Infos zum "Microsoft Internet Locator Server":
http://www.microsoft.com/netmee ting/ils/?/netmeeting/ils/main.htm
Daten zum "Microsoft Netmeeting SDK":
http://msdn.microsoft.com/developer/sdk/netmeeting/default.htm