1) Grundsätzliches

Bei dem Wasabi-Framework handelt es sich um eine service-orientierte Architektur. Sie bildet die Basis für die grundlegende Funktionalität des Wasabi Systems und enthält damit alle Dienste, die dieses mindestens benötigt. Bestandteile der Funktionalität sind insbesondere die Organisation des zur Verfügung stehenden Wissens, die Verwaltung der Benutzer, die mit dem System arbeiten sowie die Speicherung der Daten.

An das Framework lassen sich nun bestimmte Anwendungsmöglichkeiten anbinden. Dabei handelt es sich um flexible Module, welche zwar die Grundfunktionalität des Frameworks verwenden, dabei aber eine eigene Ausprägung erlauben. Als Beispiel für ein solches Modul wäre eine Laborumgebung zu nennen, in der die Speicherung und Auswertung von Versuchsergebnissen ermöglicht ist. Darauf wird später im Text noch genauer eingegangen.

Die Architektur erlaubt es einem Dienst, die Funktionalität anderer Dienste ausfindig zu machen. Zu diesem Zweck besitzt jedes Modul eine Registry, in der alle angebotetenen Funktionen samt ihrer Standorte verzeichnet sind. Diese hat die Form einer sogenannten service-description Datei. Neben den entsprechenden Funktionen sind in ihr auch zusätzliche Informationen, etwa über die Parameter und die Rückgabewerte, enthalten. Dies erleichtert die Verwendung durch einen anderen Dienst. Es ist auch ohne Weiteres möglich, den Ablauf einer bestehenden Funktion zu ändern, ohne das ein aufrufender Dienst diese Änderung bemerkt.

2) Der Aufbau des Frameworks

Das Wasabi Framework verwendet den JBoss Server. Dieser erlaubt es, beliebige Objekte welche zum Beispiel Informationen über Wissensräume oder Benutzer enthalten, dynamisch in einer Datenbank abzulegen. Erfolgen im weiteren Verlauf irgendwelche Änderungen an diesen Objekten, so werden diese automatisch in der Datenbank festgehalten, ohne das dies von einem Programmierer explizit vorgegeben werden muss. Dieser Umstand kommt auch dem service-orientierten Konzept von Wasabi zu Gute, denn jede Änderung ist mit einer bestimmten Transaktion verbunden, die ggf. auch rückgängig gemacht werden kann. Weiterhin erlaubt er es, die Verwaltung der Daten unabhängig von einzelnen Anwendungen zu gestalten. Anstelle von umständlichen, stark situationsabhängigen SQL-Befehlen gibt es nun lediglich einige Regeln und Grundfunktionen, die von unterschiedlichen Anwendungen wiederverwendet werden können.

Die Wasabi Architektur besteht aus vier Komponenten. Zunächst einmal gibt es den Kern, welcher durch ein Datenmodell vorgegeben wird. Dieses beschreibt das Grundgerüst, in dem die Datenobjekte angeordnet sind und zueinander in Bezug gestellt werden. Ihre Abhängigkeit voneinander ist durch ein Vererbungsmodell sowie die Möglichkeit einer Zuordnung einzelner Objekte zu einem speziellen Objekt gegeben. Auf diese Datenobjekte wird im folgenden Abschnitt genauer eingegangen. Das Grundgerüst ist direkt mit den drei anderen Komponenten verbunden.

Als zweite Komponente wäre die Persistenzschicht des JBoss-Servers zu nennen. Sie sorgt nun dafür, dass die einzelnen Datenobjekte in einer für ihre Speicherung vorgesehenen Datenbank abgelegt werden. Eine solche Speicherung erfolgt im Idealfall immer sofort dann, wenn ein neues Objekt angelegt, ein altes gelöscht oder ein bestehendes verändert wird. Es findet also zu bestimmten Gelegenheiten ein Update der Datenbank statt. Als Framework, welches diese Persistenz unterstützt, kommt beispielsweise Hibernate, bzw. die Java Persistence Api (JPA) in Frage. Das bevorzugte Datenbanksystem heißt bisher MySQL. Für den Aspekt der Authentifizierung kann allerdings auch das LDAP-Verzeichnissystem verwendet werden.

Bei der dritten Komponente handelt es sich verschiedene Services, die wiederum mit bestimmten Modulen, wie zum Beispiel einem Maildienst kommunizieren können. Jeder Service ist wiederum für eine bestimmte Art von Datenobjekten, wie zum Beispiel der Klasse der Documents zuständig. So erlaubt der Document Service es etwa, neue Dokumente zu erzeugen oder bereits bestehende Dokumente ausfindig zu machen. Damit wird ebenfalls der service-orientierte Aspekt von Wasabi unterstützt, denn es ist nun eine eindeutige Trennung von Daten (Komponente 1) und Diensten (Komponente 3, aber auch 2 und 4) gegeben. Mehr zu diesen Datenobjekten folgt in Abschnitt 3. Die angebotenen Dienste werden ebenfalls von dem JBoss-Server überwacht. Die vierte Komponente, auch Remote API genannt, ist dagegen für die Kommunikation zwischen Server und Client zuständig, dass heißt sie arbeitet mit entfernten Services zusammen. Für den Nachrichtenaustausch kann z.B. das Simple Object Access Protocol (SOAP) zum Einsatz kommen.

Darüber hinaus existiert noch eine fünfte und eine sechste Komponente, die allerdings nicht Teil des Frameworks sind. Die fünfte Komponente stellt eine Zusammenfassung all jener Module dar, die von Wasabi verwendet werden können. Bei jedem Modul handelt es sich um eine spezielle Ausprägung Wasabis, in der es sich dem Benutzer präsentiert und maßgeschneidert verwenden lässt. So unterscheidet sich beispielsweise ein Mail-Module grundsätzlich von einer Laborumgebung, sowohl in seiner Darstellung als auch in der Funktionalität. Bei der sechsten Komponente handelt es sich nun um die Benutzer, welcher auch Service-Consumer genannt wird. Dieser Benutzer kann eine eigene Anwendung, wie beispielsweise einen Chat-Client verwenden, um mit und über Wasabi zu kommunizieren.

Der Aufbau der Wasabi Architektur

3) Die Organisation der Daten

Wie bereits erwähnt wurde, gibt es verschiedene Arten von Datenobjekten, die allesamt ihre Grundstruktur von der Oberklasse WasabiObject erben. Da wären zunächst einmal die Benutzer zu nennen, welche mit dem System arbeiten sowie die Dokumente, auf die diese zugreifen können. Um solche Zugriffe zu regeln und gegebenenfalls auch zu unterbinden, existiert die Klasse der Benutzerrechte (auch ACLEntry genannt). Grundsätzlich kann ein Benutzerrecht jedem beliebigen anderen Datenobjekt zugeordnet werden, um einen oder eine Gruppe von Benutzern für bestimmte Zugriffe zu autorisieren. Mehr dazu folgt unter Abschnitt 4. Bei Links handelt es sich hingegen um Verweise, die auf beliebige Datenobjekte (normalerweise auf Dokumente) zeigen können. Weiterhin existieren noch sogenannte Container, die eine Zusammenfassung von Dokumenten und Links erlauben. Darüber hinaus können die einzelnen Container auch ineinander verschachtelt sein, ähnlich der Ordnerstruktur eines Dateisystems.

Ein besonderes Datenobjekt sind die sogenannten Wissensräume. Bei ihnen handelt es sich um eine Erweiterung der Container-Klasse, welche die Möglichkeit einer Ablage von Dokumenten, Links und anderen Containern auf Benutzer ausehnt. In einem Wissensraum können sich nämlich die einzelnen Benutzer treffen, miteinander kommunizieren, Dokumente ablegen und Daten austauschen. Es ist auch möglich, die Wissensräume über Ausgänge miteinander zu verbinden, so das ein Benutzer von seinem momentanen Standort aus in einen benachbarten Raum wechseln kann. Bei einem solchen Ausgang handelt es sich um eine spezielle Ausprägung eines Links. Zu guter Letzt gibt es noch das Datenobjekt der Gruppen. Einer Gruppe können sowohl verschiedene Benutzer, als auch weitere Untergruppen angehören. Wie im folgenden Abschnitt noch erläutert wird, ist es möglich, dass mit der Zugehörigkeit zu einer Gruppe spezielle Benutzerrechte verbunden sind.

Eine beispielhafte Struktur zur Organisation der Räume

4) Das Benutzerkonzept

Wie bereits erwähnt wurde, existieren im Wasabi System spezielle Benutzerobjekte, wobei jedem neu erzeugten Benutzer ein eigenes Objekt zugeordnet wird. Mit dem Benutzerobjekt ist ein Login-Name, ein Passwort für die Authentifikation sowie einige weitere Informationen verbunden. Dazu gehört etwa eine Angabe darüber, in welchem Wissenraum der Benutzer nach erfolgtem Login startet.

Die Benutzerobjekte dienen aber nicht nur zur Authentifikation, sondern unterstützen zusätzlich die Zugriffskontrolle auf einzelne Ressourcen (Dokumente). Das von Wasabi verwendete Autorisierungskonzept besitzt vier verschiedene Klassen von Instanzen. Zusätzlich zu den Benutzern und den Ressourcen als Basisklassen gibt es noch sogenannte Rollen. So kann jeder Benutzer eine oder mehrere Rollen wahrnehmen und jede Rolle erlaubt bestimmte Zugriffe auf eine oder mehrere Ressourcen. Weiterhin ist es möglich, Benutzer mit ähnlichen Rechten in der Klasse der Gruppen zusammenzufassen. Diesen Gruppen sind ebenfalls eigene Rollen zugeordnet, die wiederum an die Mitglieder der jeweiligen Gruppe übertragen werden.

Die Beziehungen zwischen Benutzern und Ressourcen

Grundsätzlich wird zwischen 7 verschiedenen Arten von Benutzerrechten unterschieden: Es gibt ein Leserecht, ein Schreibrecht, das Recht Dateien auszuführen, zu verschieben und etwas in Dokumente einzufügen. Weiterhin kann auch das Recht eingeräumt werden, Kommentare zu setzen und die Erlaubnis, Rechte an andere Benutzer zu übertragen. Die Verwaltung der erteilten Benutzerrechte erfolgt mit Hilfe von ACLs (Acces Control Lists). Dabei werden die Rechte immer objektspezifisch gespeichert, d.h. jedes Objekt enthält eine Liste von ACL-Entries. Jeder einzelne ACL-Entry speichert dann weitere, notwendige Informationen, etwa eine Liste der erteilten Rechte und den Benutzer, dem diese Rechte auf der entsprechende Ressource zugeordnet wurden. Es ist geplant, diese Informationen noch um zusätzliche Einträge zu erweitern, etwa um ein Zeitintervall, für das der ACL-Entry zur Anwendung kommen darf.

Grundsätzlich ist es möglich, Benutzerrechte zu vererben. In diesem Fall werden alle Benutzerrechte, die auf einem bestimmten Raum oder Container bestehen, an untergeordnete Objekte des Teilbaumes hindurchgereicht. Bereits geerbte Benutzerrechte können gleichfalls weitervererbt werden. Dabei ist jedoch zu beachten, daß die Art eines ACL-Entries entscheidet, wann er zur Abwendung kommt. So kann etwa ein geerbter ACL-Entry verdeckt werden, wenn für denselben Fall bereits ein spezieller ACL-Entry besteht. Leere ACL-Entries (enthalten keine erteilten Rechte) sind in diesem Zusammenhang ebenfalls möglich. Auf diese Weise schafft das System die Vorraussetzung, einem Benutzer ein spezielles Verbot zu erteilen, dass auch durch das Vererbungsprinzip nicht ausgehebelt werden kann. Eine weitere Hierarchie besteht in dem Verhältnis von Benutzerrechten und Gruppenrechten. Existiert für einen Benutzer ein spezieller ACL-Entry, so werden die diesbezüglichen ACL-Entries, die er durch die Zugehörigkeit zu einer oder mehrerer Gruppen gewinnt, von ihm verdeckt. Mit dieser Maßnahme wird ebenfalls das Konzept der expliziten Verbote unterstützt.

5) Die Anbindung spezieller Dienste am Beispiel von High Tech Laboren

Eine Benutzerumgebung, wie sie die Arbeit mit einem High Tech Labor erfordert, kann als dynamisches Service-Modul an das Wasabi Framework angebunden werden.

Die Integration von Service-Modulen

Der Hauptgrund, warum es bisher immer schwierig war, derartige Labore in eine Softwareumgebung zu integrieren, bestand in der Abwesenheit von standardisierten Schnittstellen. Ohne solche Schnittstellen ist es nur schwer möglich, zwischen den einzelnen Instanzen innerhalb einer Universität oder zwischen verschiedenen Universitäten zu kommunizieren. Das liegt daran, dass die Daten auf unterschiedlichen Systemen oft in verschiedenen Formaten vorlagen und daher vor oder nach einer Übertragung konvertiert werden müssen. Ein weiterer Grund war durch die Tatsache gegeben, dass die bisherigen Architekturen oft zu unflexibel waren, wenn es darum ging, sich an neue Anforderungen anzupassen.

Die Wasabi Architektur soll nun Möglichkeiten bieten, um die oben genannten Nachteile auszuräumen. Wie bereits erwähnt wurde, besitzt das Wasabi Framework eine einheitliche Art der Datenverwaltung. Im Zusammenspiel mit einem Service, der auf die Anforderungen eines High Tech Labors zugeschnitten ist, ist es nun möglich, Test- und Versuchsergebnisse innerhalb der angebotenen Struktur zu speichern. Diese Daten können nun einfach zwischen den verschiedenen Benutzern des Systems ausgetauscht und von ihnen weiterverarbeitet werden, ohne das dabei Probleme mit verschiedenen Spezifikationen und Standards zutage treten.

Unterschiedliche Aspekte der digitalen Wissensorganisation

Ein weiterer Vorteil des Wasabi Frameworks besteht darin, dass die High Tech Laborumgebung mit anderen Services kommunizieren kann, die an die Architektur angebunden sind. Es können sowohl lokale, als auch entfernte Dienste, die eventuell einer anderen Architektur angehören, genutzt werden. Darüber hinaus erlaubt der service-orientierte Ansatz es auch, ein einzelne Laborumgebung in zwei oder mehrere kleinere aufzusplitten, die dann unabhängig voneinander arbeiten können. Im Zusammenhang damit stellt die einheitliche Art der Datenverwaltung wiederum sicher, dass die vorhandenen Daten jedem angebundenen Service ohne Probleme zur Verfügung gestellt werden können.

6) Die Anbindung von Digitalen Bibliotheken

Die Wasabi Architektur soll die Möglichkeit bieten, mit digitalen Bibliotheken zu kommunizieren und sie damit für die angebundenen Services nutzbar machen. Um dies zu realisieren, werden Web-Interfaces eingesetzt. Diese stellen die gewünschte digitale Bibliothek in Form einer Wissensdatenbank zur Verfügung. Auf diese Weise ist es möglich, die von einem Service-Modul erzeugten Daten sofort in einer digitalen Bibliothek zu veröffentlichen und damit einer breiten Schicht von Interessenten anzubieten. Im Zusammenhang mit dem bereits angesprochenen Beispiel der High-Tech-Labore könnte dies bedeuten, dass bestimmte Versuchsergebnisse sofort und ohne große Umwege ihren Weg in eine solche Bibliothek finden. Ein Vorteil besteht darin, dass diese Daten nun auch von Personen oder Instanzen abgerufen werden können, die nicht direkt mit Wasabi arbeiten. Allgemein läßt sich also sagen, dass die Anbindung von digitalen Bibliotheken eine flexiblere Form des Arbeitens ermöglicht.

Als eine wichtige Digitale Bibliothek, die bereits unterstützt wird, ist DuEPublico von der Universität Duisburg-Essen zu nennen.