Von: Dr. Jörg Schröper
Verzeichnisdienste sind plötzlich zum Top-Thema geworden. Zu den Ursachen gehört in jedem Fall das Erscheinen der Active Directories in Windows 2000 und die begleitenden Werbemaßnahmen von Microsoft. Gerade in größeren Unternehmen reift jedoch schon seit längerer Zeit die Einsicht, dass eine verzeichnisbasierende Informationshaltung dem realen Geschäftsleben weitaus näher steht als die bislang verwendeten Systeme, die Personen- und Geräte-orientierte Informationen an verschiedenen Stellen getrennt voneinander ablegten.
Dass sich Verzeichnisdienst-Anbieter die Schlagworte Internet und E-Commerce auf die Fahnen schreiben, hat selbstverständlich auch Marketinggründe. Andererseits gewinnt das Thema Integration von Applikationen und Anbindung von Kunden und Partnern an die eigenen IT-Systeme besonders durch die Internet-Technik an Bedeutung. Netzspezialist Novell will sich im Marktsegment mit dem "E-"-Tüpfelchen mit Hilfe des "NDS E-Directories" behaupten, einem Verzeichnisdienst, von dem besonders Web-basierende Anwendungen aus den Bereichen E-Business, Customer-Relationship-Management (CRM) und Supply-Chain-Management profitieren sollen. Wie sehr die Novell-Strategen in dieser Frage jedoch die Microsoft-Konkurrenz fürchten, lässt sich unter anderem daran ablesen, dass auf den entsprechenden Web-Seiten häufiger als üblich auch vom Thema Active Directory die Rede ist.
Die Entwicklung von Netzsystemen lässt sich nach Novell-Lesart in drei Phasen einteilen. Zum ersten Schritt, der "Verbindung", gehören einfache Browser-Dienste, Chat oder Portale. In Phase zwei kommen Profile von Anwendern, Quality-of-Service-Aspekte oder die Verwaltung von Richtlinien hinzu. Die dritte Phase enthält schließlich sichere Geschäftsabläufe, Zuliefererketten, individuelle "Community"-Informationen und die Verwaltung und Definition von Anwenderdaten. "Der Wert eines Verzeichnisdienstes hängt dabei davon ab, wie viele unterschiedliche Beziehungen verwaltet werden können und welche neuen Anwendungen daraus entstehen.", erläutert Hans Krogull, Business-Stratege von Novell, das Vorgehen seines Hauses. Die Forderungen, die unbedingt erfüllt werden müssen, lauten nach seiner Meinung: Skalierbarkeit, Multi-Plattform-Unterstützung und Offenheit.
Die Schwierigkeit, die der traditionelle NDS-Ansatz mit sich bringt, liegt in seiner internen Struktur, die in erster Linie darauf abzielt, Netware-Server miteinander zu verbinden. Dem zugrunde liegenden "Schema" fehlt es auch nach Ansicht der Novell-Experten an der nötigen Universalität, um mit möglichst vielen Anwendungen arbeiten zu können. Außerdem mussten die Entwickler bei NDS bislang auf Filter verzichten, die es Applikationen erlauben, relevante Information aus einem riesigen Datenberg zu extrahieren. Die entsprechenden APIs und Werkzeuge bewerten auch die hauseigenen Experten als kompliziert und räumen ein, dass nur erfahrene Entwickler mit der Umgebung zurechtkommen.
Die Lösung, einen Riesen-Server als übergeordnete Instanz für die Datenhaltung des Verzeichnisdienstes zu installieren, wurde von den Novell-Fachleuten verworfen. Das wichtigste Problem beim zentralistischen Zugang stellen die einzelnen Applikationen dar, die ihre Datenstrukturen nach eigenen Regeln verarbeiten. Um den Austausch mit dem Verzeichnis effektiv zu gestalten, müssten die Anwendungen kontinuierlich mit der Directory-Basis kommunizieren und gleichzeitig eine zeitraubenden "Übersetzung" vornehmen. Mit einer einheitlichen Anbindung, zum Beispiel über LDAP (Lightweight Directory Access Protocol), könnte man dieses Manko zwar überwinden, bis zu einer wirklichen Standardisierung könnten aber nach Ansicht der Techniker noch mehrere Jahre vergehen. Selbst dann bleibt jedoch eine potenzielle Barriere bestehen: Entwickler werden sich gerade im geschäftskritischen Umfeld hüten, Performance-entscheidende Datenbankzugriffe an ein verteiltes Directory-System auszulagern, über dessen Auslastung keine verlässlichen Informationen vorliegen.
Das Ziel ist es nun, die Verzeichnisdienste für die Verbindung mit den Anwendungen zu optimieren. Die Novell-Experten setzen dazu auf zwei Techniken: So genannte "Filtered Replicas" - dies sind Teilabbilder des Gesamtverzeichnisses mit ausgewähltem Inhalt - bilden den Informationsstatus dezentral ab. Der zweite Punkt heißt DirXML: Mit Hilfe dieses Transformationskonzepts lassen sich verzeichnisorientierte Informationen über so genannte Style-Sheets so umwandeln, dass Anwendungen über einfache APIs auf die benötigten Daten zugreifen können.
Bei den "Filtered Replicas" oder "Virtual Replicas" (VRs) handelt es sich um einen neuen Typ von NDS-Repliken, der mit den Fachausdrücken "sparse" (dünn besetzt) und "fractional" (heruntergebrochen) beschrieben wird. Die VRs erlauben die Sicht von einem einzelnen Server auf ein umfassendes Verzeichnis, das mit den üblichen NDS-Mitteln auf einem aktuellen Stand gehalten und repliziert wird. Der Datenzugriff auf dem Server erfolgt über LDAP, wobei vordefinierte Indizes für die Applikation zum Einsatz kommen.
Intelligente Repliken des Verzeichnisses
Fachleute bezeichnen die Virtual Replicas der Verzeichnisse als "dünn besetzt", da sie nur einen ausgewählten Teil der insgesamt zur Verfügung stehenden Information enthalten. Der Inhalt besteht aus Objekten oder Klassen von Objekten. Die gefilterte Version könnte also zum Beispiel Anwenderobjekte enthalten, jedoch auf Server-, Drucker- und Applikationsobjekte verzichten. Selbst die Information im Anwenderobjekt muss nicht zwangsläufig vollständig sein, sondern darf auf die gewünschten Teile heruntergebrochen werden. So können etwa Telefonnummer und E-Mail-Adresse auftauchen, weitere im NDS enthaltene Daten aber ausgelassen werden.
Um dies zu realisieren, muss ein Abbild ("View") der NDS-Daten für einen einzelnen Server erzeugt werden (siehe nebenstehendes Bild). Das Resultat bildet ein NDS-Server, auf dem eine wohldefinierte Datenmenge liegt, die ihren Ursprung in verschiedenen Verzeichnisbäumen hat. Die Verwaltung dieses Schemas kann über die zentrale Steuerkonsole ("Console One") als Snap-in für das NDS-Server-Objekt erledigt werden.
Der zweite wichtige Teil des erweiterten Verzeichnisdienstes ist die Anbindung der Anwendungen, für die die Techniker so genannte "Application Integration Driver" einsetzen. Ein solcher Treiber nimmt Ereignisse aus dem Verzeichnis entgegen, wendet die passenden Filterdefinitionen und Datenumwandlungen an, außerdem ein Objekt- und Event-Mapping. Die Informationen stehen der Anwendung dann in deren nativem Format über ein API zur Verfügung. Über einen vergleichbaren Weg läuft der Datenfluss auch in die entgegengesetzte Richtung von der Anwendung zum Verzeichnis. Dieser Ansatz bietet Entwicklern eine wesentlich einfachere Schnittstelle, um die Datensynchronisation mit dem NDS sicherzustellen. Das Interface besteht aus nur vier simplen API-Aufrufen in Java oder C, außerdem lassen sich die nötigen Definitionen in einem oder mehreren XSLT-Style-Sheets ablegen XSLT dient als "Übersetzer" zwischen verschiedenen Dokumenten im Format der Extensible Stylesheet Language (XSL).
Die Style Sheets fungieren als Formatvorlagen und enthalten Tags, die denen eines HTML-Dokuments ähneln. Designer können die Vorlagen mit einem beliebigen Editor bearbeiten, da die Dateien als reiner Text abgespeichert werden. Die Tags innerhalb eines Style Sheets legen die Regeln fest, nach denen die Datentransformation abläuft. Dies gilt sowohl für den Weg aus dem Verzeichnis zur Anwendung wie auch für die entgegengesetzte Richtung. Sobald ein Ereignis auftritt, das einen Replikationsvorgang auslöst, übernimmt ein so genannter XSLT-Prozessor die XML-Daten aus dem NDS, wendet die vordefinierten Regeln aus dem XSLT Style Sheet an und wandelt die Information in das applikationseigene Format um. Der Treiber verwendet dazu das Event-System des NDS-Servers, sodass das Server-Pendant, welches den Treiber lädt, keine eigenen Replicas vorhalten muss.
Das Beispiel im Bild oben links zeigt, wie ein derartiger Integrationsprozess mit dem "Netscape Directory Server" aussieht. Der NDS-Server gibt die Daten aus dem Verzeichnis durch das Event-System an den XML-Datenstrom weiter. Der XSL-Prozessor wendet die passenden Regeln aus dem XSL Style Sheet auf die Daten an und erzeugt da-raus eine LDIF-(LDAP Data Interchange Format-) Datei. Außerdem löst er einen Aufruf beim anwendungseigenen API aus (im Beispiel: LDAPModify), der für das Auslesen der LDIF-Datei und das anschließende Schreiben der in das Netscape-Verzeichnis sorgt.
Eine weitere Variante des Transfers tritt dann auf, wenn anstelle der Transformationsdatei (LDIF) auf direktem Weg ein DOM-Objekt erzeugt wird. Auf dieses kann ohne Umwege von Java-Programmen aus zugegriffen werden. Im XSL Style Sheet lassen sich mehrere Typen von Formatregeln festlegen. Dazu gehört die Abbildung von Attributfeldern beim Übergang von einem Verzeichnis zum nächsten (zum Beispiel: "TelNumber" geht über in "Telefon"). Das mächtigste Werkzeug ist die Anwendung so genannter Policies und logischer Verknüpfungen für die Umformung. Damit lassen sich intelligente Regeln definieren. Ein Beispiel: "Sobald ein neues Objekt erzeugt wird, soll es den Namen X erhalten und im Container ABC abgelegt werden."
Die XSL Style Sheets selbst werden ebenfalls als Objekte im NDS abgelegt. Novell plant, Werkzeuge auf den Markt zu bringen, mit denen sich die entsprechenden Objekte direkt visuell bearbeiten lassen. Diese Tools sollen entweder als Snap-in für die Console One oder als separates Produkt arbeiten. Zum Angebot gehören Integrationstreiber für NDS nach NDS, Active Directory, MS Exchange, Netscape/LDAP, Lotus Notes und JDBC. Verschiedene Drittanbieter arbeiten nach Angaben der Netzwerker daran, Treiber für PBX-(Private Branch Exchange-) und ERP-Systeme und Datenbanken zu entwickeln.
Ein mögliches Einsatzgebiet für die beschriebene Technik ist laut Novell der Bau von Meta-Verzeichnissen. Anwendungen und Verzeichnisdienste, die mit Hilfe von DirXML mit dem NDS verbunden sind, bleiben durch den Replikationsmechanismus automatisch im aktuellen Verzeichnisstatus. Abhängig von den Zugriffsrechten können Anwendungen auch selbst in das Verzeichnis schreiben.
Komponente für das E-Business
Unter der Bezeichung "I-Chain" hat Novell im Februar eine Ergänzung zum E-Directory-System vorgestellt, das Unternehmen die Schritte zum Aufbau einer E-Business-Architektur erleichtern soll. Als Basis fungiert ein E-Directory-System, auf dem eine weitere Schicht als Vermittlungsstation eingezogen wird. Diese verbindet das Verzeichnis mit Internet-Anwendern, Extranet-Applikationen und zusätzlichen Zugriffs- und Management-Funktionen.
Kernelement von I-Chain ist ein Proxy-Server, der seinen Dienst hinter einer Firewall verrichtet und als zentraler Zugangspunkt inklusive Authentifizierung für alle Anwender fungiert. Anhängig von den individuellen Zugriffsrechten stellt der Proxy-Server ein Nutzer-Interface zur Verfügung, wobei als Grundlage zum Beispiel die Gruppenzugehörigkeit der Anwender berücksichtigt wird. Novell bezeichnet diesen Programmbestandteil als "Reverse Proxy", da er den Web-Server vom gesamten Anmeldevorgang entlastet und diesem so zu zusätzlichen Kapazitäten für Applikationen verhilft.
Das I-Chain-Paket lässt sich zusammen mit diversen Web-Servern einsetzen. In Frage kommen außer dem hauseigenen "Enterprise Web Server" der "Information Server" von Microsoft, der "Web Server" von Netscape und der "Apache"-Server. Als wesentlichen Vorteil der I-Chain-Architektur sehen die Techniker die Fähigkeit, sowohl kleinere Gruppen als auch Umgebungen mit Millionen von Anwendern bedienen zu können. Ab einer gewissen Größe kann die zentrale Verwaltung von Gruppen-Policies schnell unübersichtlich werden, daher lassen sich unter I-Chain verschiedene Teilbereiche bilden, die für exakt definierte Anwendergruppen zuständig sind.
In größeren Gesamtumgebungen gewinnt der Authentifizierungsvorgang eine wichtige Bedeutung, da eine "manuelle" Überprüfung einzelner Anwenderrechte versagt. Neben dem Standard, der auf der NDS-User-ID und dem zugehörigen Kennwort aufsetzt, lassen sich auch Token- und SSL-basierende Verfahren einsetzen. Der Proxy-Server unterstützt außerdem ein Single-Sign-on-Verfahren, sodass einem Endnutzer nach der ersten Anmeldung sämtliche Web-Server ohne zusätzliche Maßnahmen zur Verfügung stehen. Für die Übertragung sicherheitskritischer Information kann ein VPN (Virtual Private Network) mit der entsprechenden Datenverschlüsselung integriert werden. Weitere Security-Aspekte lassen sich durch PKI-(Public Key Infra-structure-) Dienste oder durch X.509-konforme Zertifikate abdecken.
Communities - Kundengruppen als Element
Der Administrator ist in der Lage, die Zugriffsrechte und -richtlinien auf die I-Chain-Infrastruktur für bestimmte Kundengruppe¸ die "Communities", übergreifend festzulegen. Ein wichtiger Punkt ist dabei die selbständige Registrierung von neu hinzukommenden Kunden und die automatische Zuordnung zur passenden Gruppe. Die Anmeldung kann etwa durch ein Web-Formular erfolgen, nach dessen Ausfüllen der für die entsprechende Community zuständige Mitarbeiter eine E-Mail-Nachricht erhält. Auch an dieser Stelle lassen sich Zertifikate verwenden, um die Identität des neuen Gruppenmitglieds zu bestimmen.
Erste Installationen von I-Chain sollen nach den Planungen von Novell derzeit bei ausgewählten Kunden durchgeführt werden.