Ein Information Broker für wiederverwendbare Lernmodule
Jodok Batlogg, Dirk Feuerhelm, Bodo Pfannenschwarz
Universität Karlsruhe, Institut für Telematik, Forschungsgruppe Cooperation & Management
Geb. 20.20, Zirkel 2, 76128 Karlsruhe, Germany,
© EURODL 1999
Abstract
Motivation
Szenario
- Einsatzmöglichkeiten
-- Universität/Schule
-- Heimbereich
-- Industrie
- Verteilte Plattform
Die Nexus Plattform
- Konzeption / Pädagogische Aspekte
-- Einbettung in eine integrierte Lernumgebung
-- Wiederverwendbarkeit von Lerninhalten
-- Konfigurierbarkeit für unterschiedliche Zielgruppen und/oder Lehrkontexte
- Technik / Architektur
- Das Nexus-Frontend
Nexus-Information Broker
- Anforderungen
- Realisierung
- Implementierungsaspekte
References
Abstract
Ausgehend von einem pädagogisch-didaktischem Modell werden
die Anforderungen an ein verteiltes System zur Speicherung, Verwaltung und Bereitstellung
von Lerneinheiten (Module) erarbeitet. Dabei wird gezeigt, wie mit Hilfe von
standardisierten Metadaten und deren konsequente Verwendung Flexibilität in das
Informationssystem eingebracht wird. Basierend auf diesen einführenden Grundlagen und
Anforderungen wird grob auf die Architektur des Systems eingegangen. Nach einer kurzen
Beschreibung des Frontends wird im zweiten Teil ein wesentlicher Teil des
Informationssystems - der Information Broker - ausführlicher behandelt. Es wird auf
dessen Design sowie auf konkrete Implementierungsaspekte eingegangen.
Key words: Tele-learning, Computer Based Training, Web Based Training, Metadata, Information Systems
Motivation
Die rasante Entwicklung der Informationstechnologie spiegelt
sich in allen Lebenslagen wieder. Ob E-Mailabruf über mobile Kommunikationsgeräte oder
rechnerunterstützte Produktion und Fertigung, alle Bereiche in denen die
Computertechnologie Einzug hält, verlangen nach einfacher und intuitiver Bedienung. Dies
widerspricht allerdings der steigenden Funktionalität und Komplexität solcher Systeme.
Daher ist eine Unterstützung des Benutzers über Hilfe- oder Lernsysteme unerlässlich
geworden.
Nicht nur die Beschreibung und Erklärung solcher Systeme, sondern auch das allgemeine Bestreben, das erlangte Wissen in digitale Form und somit für über den Computer zugreifbar umzuwandeln, lassen die Diskussion über Lehr- und Lernsystem in letzter Zeit aufblühen. Hinzu kommt, dass durch die rasante Entwicklung und Verbreitung des Internets und die immer günstiger werdenden Zugänge zum Internet das Verlangen, Wissen zeit- und ortsunabhängig zur Verfügung zu haben, erheblich begünstigt wird. Deshalb findet man neben den schon länger existierenden CBT (Computer Based Training)-Systemen zunehmend zahlreiche webbasierte, multimediale Lehr- und Lernsysteme, sogenannte WBT (Web Based Training)-Systeme auf dem stetig wachsendem Markt der Bildungssysteme.
Eine Zielsetzung der Universität ist es, Lernmaterialien in einer virtuellen Hochschule zur Verfügung zu stellen und diese mit anderen Hochschulen auszutauschen. Am Institut für Telematik der Universität Karlsruhe wird versucht, dieses Ziel mit einem webbasierten, multimedialen Lehr- und Lernsystem, dem Nexus-System, zu entwickeln und an einen europaweit verteilten Datenbestand von telematikspezifischen Lernmaterialen und -kursen anzugliedern.
Im folgenden sollen Einsatzszenarien eines Lehr- und Lernsystems näher betrachtet und Anforderungen an das System herausgestellt werden.
Universität/Schule
Da die Universitäten schon sehr früh über eine
entsprechende Infrastruktur zur Nutzung des Internets verfügten, wurden hier bereits Ende
der achtziger Jahre auf dem Gebiet der Lehr- und Lernsysteme geforscht. Da die Hochschulen
neben der Forschung auch der Lehre verpflichtet sind, bot sich der Einsatz solcher Lehr-
und Lernsysteme im Lehrbetrieb an.
Erst nach der flächendeckende Einführung von breitbandigen Netzverbindungen und entsprechenden leistungsfähigen multimediatauglichen Computern in den Universitäten ist ein regulärer Betrieb eines solchen Systems in der Lehre denkbar. Den Studenten wird neben Textbüchern und Vorlesungsskripten der klassischen Lehre ein Lehr- und Lernsystem zur Verfügung gestellt. Dieses System muss somit über frei zugängliche Rechner der Universität verfügbar gemacht werden. Der Student kann dann die multimedialen Lehrinhalte unabhängig von der Vorlesungszeiten aufrufen und bearbeiten. Besitzt der Student zusätzlich noch einen breitbandigen Netzanschluß in seiner Wohnung, so kann er die Lehrinhalte auch von zu Hause abrufen.
Die angebotenen Lehrinhalte beziehen sich in erster Linie auf den Studiengang und sind somit als Basis- und Spezialwissen einzuordnen. Trotzdem sollte auch versucht werden, diese Inhalte über Universitätsgrenzen hinaus austauschbar und dadurch wiederverwendbar zu machen. Ein kontinuierlicher Einsatz von Lehr- und Lernsystemen in der Universität wird derzeit noch durch fehlende, multimedial aufbereitete Lehrinhalte verhindert.
Ein ähnliches Einsatzszenario findet sich an den Schulen wieder. Allerdings hinkt hier die Modernisierung der entsprechenden Infrastruktur zur Nutzung des Internets und multimedialen Anwendungen dem neuestem Stand der Technik hinterher. Auch der Mangel an pädagogisch angemessenen, multimedial aufbereiteten Lehrinhalten lässt eine flächendeckende permanente Nutzung dieser Technologien an Schulen erst in ein paar Jahren zu.
Heimbereich
Ähnlich wie die Schulen verfügt der Heimanwender in der
Regel nicht über die neueste Technologie zur Nutzung multimedialer webbasierter Lehr- und
Lernsysteme. Während bei Universitäten und Schulen die öffentliche Hand zur
Finanzierung dieser zukunftsweisenden Technologien beiträgt, ist der Heimanwender in der
Regel auf sich allein gestellt. Die nicht breitbandigen und teuren Netzanschlüsse
erlauben es dem Heimanwender nicht, in einen permanenten Genuß von Multimedia zu kommen.
Von daher beschränkt sich der Einsatz von Lehr- und Lernsystemen derzeit auf den
Vertriebs per CD-Rom oder auf wenig oder gar nicht multimedial aufbereitete Lehrinhalte.
Diese wiederum stehen dem Heimanwender zwischenzeitlich in großer Auswahl zur Verfügung.
Durch den weltweiten Zugang über das Internet hat der Heimanwender auf fast alle
Themengebiete Zugriff.
Industrie
Der Einsatz von webbasierten multimedialen Lehr- und
Lernsystemen in der Industrie stellt durch das Vorhandensein von interner
Netzinfrastruktur und leistungsfähiger Rechner kein Problem mehr dar. Hier ist auch der
Einsatz eines solchen Systems anzusiedeln. Zur Weiter- und Fortbildung der Mitarbeiter
werden über das Intranet der Firmen entsprechende Weiterbildungskurse und Lehrmaterialien
angeboten. Diese Fortbildungsmaßnahmen werden dann während der Arbeitszeit wahrgenommen.
Es liegt also im Verantwortungsbereich des Mitarbeiters, seine Arbeitszeit so zu
organisieren, dass entsprechende Kurse durchgearbeitet oder Lehrinhalte angeschaut werden
können. Die Inhalte beziehen sich zumeist auf die Produkte und Dienstleistungen des
einzelnen Betriebs und sind somit sehr speziell gehalten. Allerdings können diese
Lehrinhalte, sofern sie sich nur auf die Beschreibung von Produkten beziehen, direkt an
den Kunden weitergegeben werden.
Verteilte Plattform
Um den oben beschriebene Einsatzszenarien gerecht zu werden,
wird hierfür eine verteilte Plattform entwickelt. Die verteilte Plattform soll den
Knotenpunkt zwischen den Lernumgebungen und den Autorenumgebungen darstellen (vgl.
Abbildung 1). Die Plattform wird im folgenden "Nexus" genannt. Im Hierdurch wird
die Ortsunabhängigkeit des Lernenden unterstützt, da dieser nun von jedem Rechner mit
Internetanschluss aus über die Plattform auf jegliche im System abgelegte und vom
Lernenden bereits bearbeitete Kurse zugreifen kann. Die Verteilung und Dezentralisierung
einer solchen Plattform erhöht auch die Verfügbarkeit der Lernmaterialien und
unterstützt die Zeitunabhängigkeit des Lernens.
Den Autoren bietet das Nexus-System neben der erhöhten Verfügbarkeit und Ortsunabhängigkeit Zugriff auf sämtliche bestehende Lehrmaterialien. Diese können dann dazu benutzen, eigene Kurse zu ergänzen oder neue damit aufzubauen. Die Wiederverwendbarkeit von Lehrmaterialien wird durch eine verteilte Plattform bestens unterstützt.
Abbildung 1: Zusammenspiel zwischen Lernendem, Autor und verteilter Plattform
Konzeption / Pädagogische
Aspekte
Neben dem technischen Entwurf entscheiden die didaktischen
Konzepte maßgeblich über Erfolg und Misserfolg eines Lernsystems. Bei der Entwicklung
wurden daher auch diese Aspekte gleichberechtigt zu den technischen Herausforderungen
berücksichtigt. Im folgenden sollen die wichtigsten Konzepte kurz vorgestellt werden [1], [2]:
Einbettung in eine integrierte Lernumgebung
Unter einer integrierten Lernumgebung versteht man eine
Sammlung von Unterrichtsmethoden und -techniken sowie von Lehrmaterialien und Medien, die
weitestgehend aufeinander abgestimmt sind. In diesem Zusammenhang spielten bei der
Entwicklung des System-Frontends [3] insbesondere die Aspekte Lernort,
Medienintegration und Interaktionsebene eine entscheidende Rolle.
Das Nexus-Frontend wurde in bezug auf den Lernort so entwickelt, dass das System sowohl im Rahmen einer Präsenzschulung im Schulungsraum als auch in der Telesituation am Lernarbeitsplatz des Lernenden eingesetzt werden kann. Beide Einsatzszenarien stellen dabei unterschiedliche Anforderungen an ein Lernsystem. Im Rahmen einer Präsenzschulung kann der Lehrende selbst entscheiden, in welchem Umfang er das System einsetzen möchte. Sowohl ein gezielter Einsatz von Lernbausteinen als auch vollständige Präsentationen sind möglich. Das Nexus-Frontend ist komplett HTML-basiert und passt die Darstellung der Inhalte automatisch an die verwendete Bildschirmauflösung an. Dies erlaubt die problemlose Verwendung unterschiedlichster Präsentationsmedien.
In der Telesituation bietet das Nexus-Frontend dem Lernenden in der Hauptsache die Möglichkeit des zeit- und ortsunabhängigen Lernens. Zudem bekommt der Lernende mit einem solchen Lernsystem die Möglichkeit, das Lerntempo selbst zu bestimmen und durch die beliebige Wiederholbarkeit das erlangte Wissen zu festigen. Durch interaktive Lernbausteine, wie Animationen und Simulationen, wird das explorative Lernen gefördert und der Lernende bekommt die Möglichkeit, das erworbene Wissen anzuwenden oder zu vertiefen [4], [5].
Wiederverwendbarkeit
von Lerninhalten
Zur Sicherstellung der Wiederverwendbarkeit von Lerninhalten
wurde bei der Entwicklung auf bewährte Konzepte der Softwaretechnik zurückgegriffen.
Eines der wesentlichen Merkmale ist dabei der modulare Aufbau aus wiederverwendbaren Lernmodulen. Ein solches Lernmodul besteht aus einer oder mehreren HTML-Seiten mit Texten, Bildern, Animationen etc. und lässt sich als thematisch abgeschlossene Lerneinheit definieren. Da das System als Hypermediasystem konzipiert ist, sind die einzelnen Seiten eines Lernmoduls über Hyperlinks miteinander verknüpft. Nach dem selben Prinzip können auch feste Querbezüge zwischen Lernmodulen hergestellt werden (siehe Abbildung 2).
Abbildung 2: Lineare
Verkettung von Lernmodulen durch eine Guided Tour
(dunkler Pfeil - Guided Tour, helle und dünne Pfeile - traditionelle Links)
Konfigurierbarkeit für unterschiedliche Zielgruppen und/oder
Lehrkontexte
Legt man bei der Gestaltung des Lernsystems Wert auf die
Wiederverwendbarkeit und die Konfigurierbarkeit für unterschiedliche Zielgruppen und
Lehrkontexte, erweisen sich statische, vom Lernmodulautor fest vorgegebene Querverweise
als problematisch. Aus diesem Grund wurde beim Nexus-System das Guided-Tour-Konzept
eingeführt, das die lehrkontextspezifische Navigation durch die Lernmodule von den
eigentlichen Lerninhalten entkoppelt [6]. Eine Guided Tour läßt sich
als lineare Verkettung von Lernmodulen unter einem ganz bestimmten Blickwinkel definieren.
Sie wird im System unabhängig von den eigentlichen Lernmodulen erstellt und verwaltet.
Eine eigene Guided-Tour-Steuerung gestattet es dem Benutzer, die einzelnen Tourschritte
direkt anzuspringen. Wie man Abbildung 2 entnehmen kann, bleiben dabei die traditionellen
Hyperlinks in Form von Querbezügen zwischen den Lernmodulen weiterhin erhalten. Sie
beschreiben jedoch ausschließlich thematisch begründete Zusammenhänge zwischen den
Lerninhalten. Dem Lernenden bleibt es ungenommen, zu einem beliebigen Zeitpunkt den
Tourpfad zu verlassen und einem eigenen Pfad zu folgen. Da sich beliebige Web-Seiten in
die Guided Tour einbinden lassen, kann der Lernende von hier aus beliebigen Links im
Internet folgen. Über einen Knopf der Guided-Tour-Steuerung kann er zu jedem Zeitpunkt
zur Tour zurückkehren und somit den Lost-in-Hyperspace-Effekt vermeiden [5].
Um die Wiederverwendbarkeit von Modulen sicherzustellen, dürfen diese keine kontextspezifischen Informationen in Form von Einleitungen, Überleitungen, Zusammenfassungen, direkte Bezüge zu einer bestimmten Lehrveranstaltung oder informelle Kommentare des Dozenten enthalten. Aus diesem Grund wurden im Nexus-System für derartige Metainformationen sogenannte Metamodule eingeführt, die diese Informationen aufnehmen können. Metamodule unterscheiden sich von herkömmlichen Lernmodulen darin, dass sie genau einer Guided Tour zugeordnet sind und nur in diesem Zusammenhang einen Sinn ergeben. Abbildung 3 zeigt den schematischen Aufbau einer mit Metamodulen ausgestatteten Guided Tour.
Abbildung 3: Beispiel für eine Guided Tour mit Metamodulen
Technik / Architektur
Eine zentrale Forderung an das System ist die problemlose
Pflege und Erweiterung von Lerninhalten, d.h., Lerninhalte sollen flexibel in das
Lernsystem eingebracht, modifiziert und entnommen werden können. Weiterhin soll das
Basissystem plattformunabhängig eingesetzt werden.
Um eine hohe Wiederverwendbarkeit zu garantieren, müssen sämtliche Module in einem großen Pool von gespeicherten Lerninhalten schnell und einfach lokalisiert werden können. Die Granularität der gesuchten Module ist sehr unterschiedlich: komplette Kurse, verschiedene Abbildungen und Diagramme, Teile von Kursen um einen neuen Kurs zu konstruieren. Um die gespeicherten Daten durchsuchen zu können, wird ein "Content Directory System" (CDS) benötigt. Das CDS greift auf einen vordefinierten Satz von Metadaten zurück. Dadurch ist es möglich, wesentlich genauere und detailliertere Suchanfragen zu stellen, als mit einer konventionellen Stichwort-Anfrage. Die Anforderungen der verschiedenen Benutzer wie Lernende, Lehrende oder Autoren an das CDS sind sehr verschieden, so dass das CDS adaptives Verhalten zeigen muss.
Außerdem wird ein System benötigt, das als Plattform für die verschiedenen Anwendungen wie Arbeitsumgebung der Autoren oder das Frontend der Lernenden dient. Dieses System muss die verteilte Architektur des Gesamtsystems verschatten und abstrahieren. Durch die Hilfe von Middlewarekomponenten werden diese verschiedenen Dienste verbunden und bilden den "Content Management Service" (CMAS).
Schlussendlich muss ein ansprechendes webbasiertes Frontend für die Lernenden bereitgestellt werden. Das Frontend muss nahtlos in das Gesamtsystem eingebunden werden und wird im folgenden nur kurz erwähnt, weitere Informationen finden sich in [3]. Das System bildet somit eine klassische "Three-Tier-Architektur" bestehend aus Frontend-Applikation, Middleware (CMAS), und der Datenhaltung (vgl. Abbildung 4). In den folgenden Abschnitten soll kurz auf das Nexus-Frontend und schließlich ausführlicher auf die serverseitigen Komponenten, im folgenden "Information Broker" genannt, eingegangen werden.
Abbildung 4: Architektur des Nexus-Systems
Das Nexus-Frontend
Die Ablaufumgebung präsentiert sich dem Benutzer des
Lernsystems, wie in Abbildung 5 dargestellt, in einem Webbrowser als in HTML realisierte
Bedienoberfläche. Die WWW-Seite wurde in fünf HTML-Frames aufgeteilt.
Abbildung 5: Oberfläche des Nexus-Frontends
Kopfleiste
Die Kopfleiste enthält Verweise, welche den Lernenden zur Startseite
des Lernsystems, zur Homepage des Lernsystembetreibers oder zu Hilfeseiten führt.
Lernmodulbereich
In diesem Bereich werden bei gestarteter Guided Tour die Lernmodule und Metamodule
angezeigt. Wenn das System startet und noch keine Tour aktiv ist, enthält der
Lernmodulbereich die Startseite des Lernsystems.
Tourtitelbereich
Hier wird der Titel der aktiven Tour angezeigt.
Metainformationsbereich
Hier bietet sich dem Autor die Möglichkeit, den Lernenden gezielt auf
bestimmte Teilbereiche eines Lernmoduls oder einer Lernmodulseite hinzuweisen.
Lernsystemsteuerung
Die im Steuerungsbereich untergebrachte Steuerungsleiste wird zur Navigation
zwischen den Lernmodulen einer Guided Tour sowie zum Aufrufen der Tourübersicht
verwendet.
Anforderungen
Hauptaufgabe des Information Brokers innerhalb des
Nexus-Systems ist die Verwaltung von Informationen über die in das System eingebrachten
Inhalte. Die zwei wichtigsten Aspekte sind dabei einerseits die Erfassung von Metadaten zu
den Inhaltsobjekten, um diese geeignet zu attributieren und charakterisieren, andererseits
ein Mechanismus zur persistenten Ablage der Metadatensätze und zur Unterstützung von
Suchanfragen über diese abgelegten Daten.
Da im Zugriffsprofil auf diese Daten die Anzahl der Suchanfragen deutlich höher liegen dürfte als die Menge der Einbring-Transaktionen, ist darauf zu achten, dass Suchzugriffe möglichst performant verarbeitet werden können, auf Kosten der Performance von Einbringungsoperationen. Dabei kann – auch hinsichtlich des verteilten Charakters des Systems – die Forderung nach Konsistenz und Atomizität abgeschwächt werden.
Diese Eigenschaften entsprechen im Wesentlichen den Anforderungen an einen Verzeichnisdienst, so dass bei der Realisierung des Information Brokers auf bekannte und erprobte Methoden und Mechanismen zurückgegriffen werden kann.
Realisierung
Die Gestaltung der Metadatensatzstruktur ist in mehrerlei
Hinsicht richtungsweisend für die Verwendbarkeit der zugrundeliegenden Inhaltsobjekte.
Zum einen muss die Möglichkeit gegeben sein, Inhaltsobjekte verschiedener
Granularitätsstufen zu unterstützen, damit sowohl große, monolithische Objekte wie
beispielsweise komplette Kurse, als auch kleinere Items wie Schaubilder oder
Videosequenzen gezielt auffindbar und damit wiederverwendbar sind.
Die Wiederverwendbarkeit ist dabei aus der Sicht des Autors, der bei der Neuerstellung eines Kurses einen Überblick über für ihn nutzbare Objekte wünscht, wie auch aus der Sicht eines Lernenden, der sich dafür interessiert, welche Kurse mit welchen Eigenschaften zu einem bestimmten Themengebiet zur Verfügung stehen, zu betrachten. Weiterhin sollte der Metadatensatz so ausführlich wie möglich sein, damit differenzierte Suchanfragen unterstützt werden können, andererseits aber auch klein gehalten werden, damit Autoren nicht durch überlange auszufüllende Metadatenformulare abgeschreckt werden und bestehende Inhalte mit wenig Aufwand attributiert und ins System eingebracht werden können. Der dritte Aspekt ist die Wiederverwendbarkeit über Systemgrenzen hinaus. Bislang existierende Lernsysteme bedienen sich einer proprietäre Metadatenstruktur, somit ist die Nutzung an das System gebunden.
Das IMS-Projekt (Instructional Management System), ein internationales Projekt unter der Leitung von EDUCAUSE [7], einem Konsortium von Colleges, Universitäten und Industriepartnern, hat sich bereits einigen Aspekten dieser Problematik angenommen. Als Teilergebnis wurde Ende August 1999 die Spezifikation eines Satzes von Metadaten für Lernressourcen veröffentlicht [8]. Das Hauptaugenmerk liegt hierbei auf den folgenden Bereichen:
herkömmliche Dokumentenbeschreibungsattribute wie Titel, Autor, Beschreibung etc. Informationen über die Meta-Metadaten, beispielsweise Zeitpunkt und Ersteller des Metadatensatzes Lehrtechnische Informationen wie Lernkontext oder Schwierigkeitslevel technische Eigenschaften wie Software- oder Betriebssystemanforderungen rechtliche Aspekte wie Copyrighteinschränkungen oder Verwertungstarife taxonomische Einordnung in einen Themenbaum
Die führenden Hersteller von Lernsystemen reagierten darauf mit Zusagen, ihre Produkte IMS-konform umsetzen zu wollen [9]. Die Spezifikation wurde der IEEE als Proposal zur internationalen Standardisierung vorgelegt. Sowohl die IMS- als auch die IEEE-Dokumente enthalten jedoch keine Details zur Implementierung der Metadaten wie Architektur, Datenablage oder Programmiersprache. Ebenso ist eine individuelle Erweiterbarkeit der Datenstrukturen vorgesehen, lediglich eine Kernmenge von Attributen muss gegeben sein.
Als Austauschformat für die im Nexus System anfallenden Metadaten wurde XML (eXtensible Markup Language) gewählt. XML erfreut sich weltweit zunehmender Akzeptanz und Verbreitung als allgemeiner, frei definierbarer Strukturdefinitionssprache und bietet sich daher zum Einsatz bei der Festlegung der Datenarchitektur an. Zudem befinden sich zahlreiche Hilfsmittel wie XML-Editoren oder XML-Server auf dem Markt und in Entwicklung, so dass externe Werkzeuge problemlos in das Nexus System eingebunden werden können. Der Ansatz verschiedener Granularitätsstufen kann dabei mittels unterschiedlicher DTDs (Document Type Definition) realisiert werden, wobei gemeinsam auftretende Attribute in externen Entities zentral vereinbart werden können. Die IMS-Spezifikation beinhaltet bereits zwei DTDs, einerseits eine XML-Umsetzung der dem Standard genügenden Attributskernmenge, andererseits eine Umsetzung der gesamten spezifizierten Eigenschaften.
Die Anforderungen des Nexus Information Brokers bezüglich der Metadatenablage und der Suchanfragenmöglichkeit entsprechen wie angesprochen weitgehend denen eines Verzeichnisdienstsystems. Aus diesem Grund bietet sich die Verwendung von LDAP (Lightweight Directory Access Protocol) als Zugriffsprotokoll und eines LDAP-Servers zur Datenablage an. LDAP basiert auf X.500, einer ISO/OSI-Spezifikation für Verzeichnisdienste, die jedoch für viele Zwecke zu komplex ist, um effizient zum Einsatz zu kommen. Daher wurde LDAP als 90/10-Lösung entwickelt, d.h. 90% der Funktionalität von X.500 bei 10% der Komplexität. Zudem bietet LDAP den Vorteil, durch seine weite Verbreitung und Akzeptanz bereits Implementierungen im Open Source-Bereich vorweisen zu können. Die Verwendung solcher Software steht im Sinne des Open Courseware-Gedankens, welcher beim Nexus System verfolgt wird. LDAP ist zum Einsatz in einem verteilten System per se geeignet, da Verzeichnisdienste in der Regel nicht als atomare Systeme vorliegen. Aspekte wie automatische Replikation und Distribution von Daten in einer verteilten Umgebung und hierarchische Strukturierung des gesamten Datenbestandes werden bereits durch die Spezifikation abgedeckt.
Implementierungsaspekte
Als LDAP-Server kommt die Programmsuite des
Open-Source-Projektes OpenLDAP zum Einsatz, welches von der OpenLDAP-Foundation
koordiniert wird [10]. Beim derzeit in der Entwicklung und im
Testbetrieb befindlichen Prototypen wird eine einzelne Instanz der Standalone-Ausführung
des Servers, slapd, verwendet, als Betriebssystem kommt Linux zum Einsatz. Für den
Übergang zum verteilten Betrieb steht im OpenLDAP-Programmpaket das Aktualisierungs- und
Replikationstool slurpd zur Verfügung. Dieses sorgt – ähnlich wie die Mechanismen
beim Domain Name Service im Internet – für eine automatische Verbreitung neu
eintreffender Daten, wobei als Protokoll wiederum LDAP zur Anwendung kommt.
Die Datenhaltung des LDAP-Servers basiert auf der GDBM-Filesystemdatenbankbibliothek (GNU Data Base Manager) die unter Unix weit verbreitet ist. Hierbei erfolgt eine Umsetzung der vereinbarten LDAP-Objektklassenstruktur in multiple indexierte Einzeldateien, um einen performanten Zugriff zu gewährleisten.
Für jede im IMS Metadatenschema auftretende Basisklasse, also für jede vereinbarten XML-DTD, wird beim LDAP-Server eine entsprechende Objektklasse definiert und hinterlegt. Da die Struktur von LDAP-Objektklassen, wie in RFC2251 [11] definiert, keine direkte Schachtelung von Attributen vorsieht, bei XML-DTDs jedoch die Verschachtelung zur Strukturierung des Datensatzes dient, wird eine Abbildungsvorschrift vereinbart, um eine Transformation des DTDs in die flache LDAP-Objektklassenstruktur durchführen zu können.
Das DN (Distinguished Name)-Attribut, welches zur Identifikation der LDAP-Datensätze dient, und im LDAP-Verzeichnisbaum einmalig zu sein hat, wird hierbei aus dem General-Identifier-Attribut der IMS-Metadaten, welches zum Core-Schema gehört und daher stets gegeben ist, übernommen. Das äußerste XML-Schachtelungstag bestimmt den DTD-Typ und damit die Objektklasse. Ein weiteres Merkmal der IMS-XML-Metadatenstruktur ist, dass Werte ausschliesslich als Blattknoten im DOM (Document Object Model)-Baum auftreten. Somit ist ihre Einordnung in die Dokumentenstruktur durch den Pfad von der Baumwurzel zum Blattknoten eindeutig beschreibbar. Der entsprechende Attributsname in der LDAP-Objektklasse wird duch Konkatenierung der XML-Tags entlang des Pfades gebildet.
Ein weiteres Problem ergibt sich bei der Transformation von XML-Attributen. Diese können – im Gegensatz zu den oben behandelten XML-Werten – auch ausserhalb von Blattknoten auftreten und ihr Geltungsbereich erstreckt sich über den gesamten angeknüpften Subtree. Um diesen Sachverhalt in der Objektklassenstruktur nachbilden zu können, werden für jeden gespeicherten Wert sämtliche im Baum oberhalb liegenden und damit relevanten Attribute zusammen mit dem Wert selbst als LDAP-Attributswert abgelegt. Dies bedeutet zwar eine redundante Speicherung, ermöglicht jedoch einen schnellen Suchzugriff auf die abgelegten Informationen.
Die mögliche Komplexität von Suchanfragen geht weit über die derzeit im Internet üblichen Schlüsselwortsuchen hinaus. Ein Suchauftrag wird mittels eines LDAP-Filterausdrucks gemäß RFC2254 [12] formuliert, dies kann entweder direkt oder mit Hilfe des implementierten Java API erfolgen. Dieses unterstützt den Benutzer bei der Zusammenstellung seiner Suchparameter, indem es ihm die möglichen Suchattribute in Baumform zugänglich und selektierbar macht. Problematisch bei der Suche sind Suchzugriffe mit numerischen Vergleichen, da bedingt durch die Ablagestruktur der Inhalte diese nur als Strings gespeichert werden können. Numerische Vergleiche lassen sich daher einerseits durch Nachselektion nach Auswertung des Filterausdrucks realisieren, oder aber durch explizite und damit redundante Ablage des numerischen Wertes unter Ausschluss der zugehörigen XML-Attributswerte.
Der Zugriff auf den Information Broker durch andere Komponenten des Nexus Systems wird durch ein Java API realisiert, das nach aussen die Grundfunktionalität der Verzeichnisdienstkomponente anbietet, also eine insert-Funktion, eine delete-Funktion, eine Suchfunktion und eine retrieval-Möglichkeit. Die Einbringungsfunktion verarbeitet dabei als Eingabeparameter wahlweise den Metadatensatz als rohes XML-Dokument oder als expliziten DOM-Tree. Als XML-Parser kommt das von IBM erstellte Java-Package xml4j zum Einsatz [13], welches als Open Source Software verfügbar ist. Die Abwicklung der Kommunikation mit dem LDAP-Server wird mittels JNDI-Klassen (Java Naming and Directory Interface) realisiert, hierbei handelt es sich um ein offizielles Java Standard Extention Package von Sun.