Björn Gehlsen, Ralf Kriebisch¹, Hansjörg Krasemann,
Winfried Lamersdorf¹, Bernd Page¹

1. Einleitung

In den letzten Jahren etablierte sich das World Wide Web (WWW) als ein Dienst des weltumspannenden Internet, der einen besonders benutzerfreundlichen Zugriff auf entfernte Dokumente, die durch WWW-Server vorgehalten werden, ermöglicht. Die Aufbereitung dieser Dokumente, die in der Seitenbeschreibungssprache HTML (Hypertext Markup Language) erstellt werden, übernimmt ein WWW-Browser, ein Programm auf dem Rechner des Benutzers. WWW-Browser gibt es für nahezu jede gängige Hardware; viele Hersteller bieten für nichtkommerzielle Nutzung kostenfreie Lizenzen an. Neben dem Zugriff auf einzelne Dokumente ist es auch möglich, aus HTML-Seiten heraus auf Programme eines WWW-Servers zu verweisen und sie zu starten. Indem diese Programme nun wiederum Datenbankabfragen ausführen, existiert eine Möglichkeit, Datenbanken in das WWW einzubetten. Nachteilig wirkt sich jedoch aus, daß der betroffenene WWW-Server schnell zum Engpaß werden kann.

Auch im Projekt TIDE bestand die Aufgabe, eine Datenbank und weitere Datenbestände über das WWW erreichbar zu machen. Dieser Beitrag schildert kurz, wie dieses mit konventionellen Methoden realisiert wurde, um anschließend auf ein flexibleres Konzept zum Zugriff auf Datenbanken über das Internet einzugehen. In Kapitel 2 wird der Projektkontext und eine prototypisch mit konventioneller WWW-Technologie realisierte Nutzerführungskomponente skizziert. Im Kapitel 3 werden weitergehende Anforderungen für einen flexibleren Zugriff auf verschiedene Datensammlungen diskutiert. Kapitel 4 gibt einen Überblick über derzeit verfügbare Technologien zum Zugriff auf entfernte Datenbanken. Im Kapitel 5 wird die im weiteren Verlauf des Projekts zu realisierende Systemarchitektur beschrieben, und es werden einige schon vorhandene Komponenten und Schnittstellen gezeigt. Kapitel 6 schließt mit einer Übersicht weiterer zu leistender Arbeiten. Einen etwas früheren und knapperen Bericht zum Stand des Projekts findet man in (Gehlsen et al. 1998a).

2. Derzeitiger Zugriff auf Daten zur Wattenmeerforschung

Im GKSS Forschungszentrum Geesthacht wurden im Laufe der vergangenen Jahre umfangreiche Umweltdaten zusammengetragen, die aus Forschungsprojekten verschiedenster Fachgebiete resultieren. Gemeinsam ist diesen Daten der Bezug zur Wattenmeerforschung, die in der GKSS als ein Schwerpunkt betrieben wird. Beispielsweise wurden im Rahmen biologischer Forschungen Monitoringdaten verschiedener Tierarten erhoben, Chemiker erstellten eine Schadstoffkartierung des Wattenmeeres, Meteorologen protokollierten Impuls-, Energie- und Feuchteflüsse. Fischereiwissenschaftler trugen Langzeitmonitoringdaten von Fischen und Krebsen bei, und Sozioökonomen lieferten Daten zum Verhalten von Touristen.

Die Daten wurden zwar zentral in einer relationalen Datenbank, der sog. Wattenmeerdatenbank WADABA, abgelegt, ihr Inhalt und ihre Struktur sind jedoch völlig heterogen. Ohne zusätzliche Information oder Anleitung sind sie so für Interessenten, die nicht an der Datenerhebung beteiligt waren, nicht oder nur schwer nutzbar.

Deshalb wurden seit Anfang der neunziger Jahre mehrere Varianten der Nutzerführungskomponente LOTSE (Land Ocean Thematic Search Engine) für jeweils verschiedene Rechnerplattformen entwickelt (Krasemann et al. 1993). Mit Hilfe des LOTSEn konnten im wesentlichen die in der WADABA abgelegten Daten recherchiert werden. Anfang 1997 wurde das Projekt TIDE initiiert, in dessen Rahmen prototypisch eine Folge von Nutzerführungskomponenten entsteht. Diese sollen es insbesondere Wissenschaftlern aller Fachrichtungen, aber auch Entscheidungsträgern aus Wirtschaft, Politik und Verwaltung sowie interessierten Privatpersonen ermöglichen, plattformunabhängig und ohne spezielle EDV-Kenntnisse auf Umweltdaten verschiedenen Ursprungs zuzugreifen. Im Laufe des Jahres 1997 enstand so ein voll funktionsfähiger Prototyp einer Nutzerführungskomponente, die einen plattformunabhängigen Zugriff auf die in der WADABA abgelegten Projektdaten ermöglicht: der LOTSE/Web. Hierbei handelt es sich um eine auf WWW-Technologie basierende Version des Lotsen, bei dem durch die Verwendung von WWW-Browsern als Benutzungsschnittstelle eine Plattformunabhängigkeit auf der Client-Seite erreicht wird. Zudem ist der Browser für viele Nutzer eine gewohnte Arbeitsumgebung, was dem System eine hohe Akzeptanz sicherte. Details finden sich in (Gehlsen et al. 1998b) und (Wolff 1998).

3. Anforderungen an ein flexibleres Zugriffsystem

Der Wunsch nach Integration weiterer Datenbestände sowie nach Plattformunabhängigkeit auf Seiten der Clients und der Server stellt an ein Zugriffsystem höhere Anforderungen, als der LOTSE/Web erfüllen kann. Sie werden in den folgenden Abschnitten präzisiert.

1. Einbindung weiterer Datenbestände

Ist einmal die Möglichkeit geschaffen, einen Datenbestand bequem vom Arbeitsplatz aus zu erreichen, so ist auch der Ruf nach der Erreichbarkeit weiterer Datenbestände vorhersehbar. Deren Integrierbarkeit fordern wir für ein flexibles Zugriffsystem. Dabei ist an die Integration sowohl bereits vorhandener als auch erst in Zukunft erhobener Datenbestände gedacht. Unter Integration ist zunächst der automatisierbare Zugriff über eine definierte Schnittstelle zu verstehen. Zum Erreichen von Metadaten bzw. Daten verschiedener Bestände muß zunächst noch getrennt gesucht werden. In einem weiteren Schritt ist die bestandsübergreifende Suche nach relevanter Information wünschenswert. Vermutlich können einheitliche, bestandsübergreifende Suchkriterien jedoch nicht vorausgesetzt werden.

Im Rahmen des Projekts TIDE sollen diese Datenbestände integrierbar gemacht werden. Das heißt, es sind Schnittstellen zu definieren, die von Betreibern fremder Datenbestände implementiert werden können. Indem die Implementation von den Institutionen vorgenommen wird, in denen die Daten erhoben worden sind, fließt das dort vorhandene Hintergrundwissen über die zu veröffentlichenden Daten in das System mit ein.

2. Plattformunabhängigkeit

Eine weitgehend zufriedenstellende Plattformunabhängigkeit auf der Client-Seite läßt sich durch den Einsatz von WWW-Techniken realisieren. Für die Betriebssysteme MS Windows, MacOS und verschiedene Unix-Varianten existieren Internet-Browser mit untereinander vergleichbarer Funktionalität. Nutzer können das Zugriffsystem also nahezu unabhängig von der ihnen verfügbaren Hardwareplattform verwenden. Für die Erhebung zukünftiger Datenbestände und die Bewilligung von Forschungsprojekten sollte die Möglichkeit und die Bereitschaft, Resultate einem breiten Interessentenkreis zugänglich zu machen, ein wichtiges Argument und Entscheidungskriterium sein. Auf diesem Weg kann auch die kostenintensive Mehrfacherhebung gleicher bzw. sehr ähnlicher Daten vermieden werden.

Die Forderung nach Plattformunabhängigkeit auf der Serverseite erhält in dem Moment eine besondere Bedeutung, in dem die Daten nicht mehr ausschließlich von einer Institution bereitgestellt werden sollen. Hier ist es nützlich, wenn weder einheitliche Hardware noch einheitliche Programmiersprachen vorausgesetzt werden müssen. Bei der geplanten Integration weiterer Datenbestände aus verschiedenen Forschungsinstitutionen ermöglicht diese Flexibilität, daß sowohl die Erstellung als auch die Wartung des datenliefernden Softwarebausteins in der Regie der Institution liegen kann, in der die Daten erhoben wurden.

3. Möglichkeiten des Auffindens von Information

Potentielle Nutzer des geplanten Zugriffsystems sind Fachleute aus Wissenschaft, Wirtschaft, Politik und Verwaltung sowie interessierte Privatpersonen. Detailliertes IT-Wissen kann bei diesem Personenkreis nicht vorausgesetzt werden, weshalb Benutzerfreundlichkeit notwendiges Kriterium für die Akzeptanz des Systems ist.

Zusätzlich kann nicht davon ausgegangen werden, daß die Nutzer Kenntnisse über den Inhalt und die Struktur eines Datenbestandes haben. Um diesen zu erschließen, sind Mechanismen zur Suche und zur Navigation vorzusehen. Bei der Suche werden die Metadaten mit den spezifizierten Kriterien einer Anfrage abgeglichen. Diese Suchanfragen können Datenobjekte recht genau eingrenzen, sie setzen jedoch auch Kenntnis über den Inhalt des Datenbestandes voraus.

Demgegenüber bietet die Navigation einem unerfahrenen Nutzer die Möglichkeit, sich den Datenbestand Schritt für Schritt zu erschließen. Unter Navigation versteht man die geleitete Bewegung von einem Knoten in einem Navigationsgraphen zu einem benachbarten Knoten, wobei jeder Knoten die Beschreibung eines Datenobjekts oder Metadatums repräsentiert. Eine Schlagwortsammlung kann zu Navigationszwecken herangezogen werden.

Hat ein Nutzer sich einen Datenbestand bereits erschlossen, kann er sich durch aktive Informationsversorgung im Sinne von (Koschel/Kramer 1998) über für ihn relevante Änderungen in einem Datenbestand automatisiert unterrichten lassen. Natürlich muß genau spezifiziert werden, was unter relevanten Änderungen verstanden werden soll. Eine gute Kenntnis des Datenbestandes ist also nötig. Ein solcher Ansatz wird bei TIDE nicht verfolgt.

4. Benutzergerechte Form von Anfragen und gefundenen Inhalten

Sowohl für die Anfragen des Benutzers als auch für die Rückmeldungen des Systems sind verschiedene Formen denkbar. Zur Steigerung der Akzeptanz des Systems sind Überlegungen nach besonders geeigneten Darstellungsformen für die Umweltinformation gefordert. Dieses gilt sowohl für die eigentlichen Originaldaten als auch für beschreibende Information (Metadaten). Beispielsweise sollten Information über die räumliche Ausdehnung eines Datenbestandes in Karten, eine Aufstellung verschiedener Meßmethoden eher in Tabellenform mit kurzen Erklärungen geliefert werden. Für langfristige Meßreihen eignet sich besonders eine Grafik, die die Veränderung der vermessenen Größe über den Zeitverlauf visualisiert.

Zur Nach- bzw. Weiterverarbeitung werden die Daten auf dem Rechner des Benutzers abgelegt. Vor dem Transfer umfangreicher Datenmengen auf Anforderung eines Benutzers soll diesem Information zur Verfügung stehen, die ihn über Umfang und Relevanz der Daten aufklärt und so eine unnötige Belastung des Netzes vermeidet. In diesem Zusammenhang ist die Möglichkeit der ausschnittsweisen Übertragung von Originaldaten wünschenswert. Zusätzlich ist eine Ausgabe in Standardformaten unbedingt vorzusehen, da ein Benutzer für ihn relevante Originaldaten im allgemeinen auf seinem lokalen System weiterverarbeiten wird.

5. Beschränkung von Zugriffsrechten

Sicherheitsaspekte und juristische Gründe (Datenschutz, Urheberrechte) können dafür sprechen, nicht alle verfügbaren Daten kostenlos oder öffentlich zur Verfügung zu stellen, sondern eine Kontrolle der Zugriffe einzurichten. Grundsätzlich sollen im Kontext des Projekts TIDE Metadaten frei verfügbar sein, d.h. Informationen darüber, ob und wo relevante Daten vorliegen, unterliegen keinerlei Zugriffsbeschränkungen.

Für den sicheren Zugang zu Originaldaten ist ein Authentisierungsverfahren vorgesehen. Ein Endbenutzer erhält einen elektronischen Zugangsschlüssel und weist sich zu Beginn der Systemnutzung damit aus. Im weiteren Verlauf der Nutzung sind dann keine weiteren Berechtigungsnachweise vom Endbenutzer einzugeben. Es ist ein Rollenkonzept vorgesehen, das einen Benutzer verschiedenen Nutzergruppen zuordnet. Die Verwaltung konkreter Nutzungsrechte für einzelne Nutzergruppen obliegt dann den einzelnen Datenservern im Gesamtsystem. Falls eine verschlüsselte Übertragung von Daten notwendig ist, so kann dies auf Basis einer sicheren Transportschicht (SSL) geschehen. Für jeden Datenbestand ist die Möglichkeit vorgesehen, Zugriffe durch nicht autorisierte Personen zu unterbinden. Weiterhin können die Zugriffe protokolliert werden, um Versuche mißbräuchlicher Nutzung zu erkennen und entsprechend reagieren zu können.

4. Zugriff auf entfernte Datenbanken über das Internet

Die Einbettung von Datenbanken in das Internet ist nicht nur im Bereich Umweltdaten eine zur Zeit häufig gestellte Aufgabe. Dieser Abschnitt gibt einen kurzen Überblick über vier verfügbare Technologien, die einen Anschluß von Datenbanken an WWW-Anwendungen ermöglichen. Sie unterscheiden sich insbesondere in ihrer Flexibilität bezüglich eingesetzter Programmiersprachen, unterschiedlicher Hardwareplattformen, verschiedener Ausprägungen von Transparenz, aber auch nicht unerheblich in dem Aufwand, der zu ihrer Implementierung erforderlich wird. Einen knappen Überblick gibt Tabelle 1; eine ausführliche Beschreibung findet sich beispielsweise in (Orfali/Harkey 1997). Wegen der zügigen Weiterentwicklung von CORBA lohnt auch ein Blick in die Literatur im Internet.

HTML/CGI: Eine sehr weit verbreitete Methode ist die Nutzung des Common Gateway Interface (CGI), das es über HTTP erlaubt, Serverprogramme als URL in HTML-Dokumenten zu adressieren. Vom Browser aus, der die HTML-Seite aufbereitet, kann so das entsprechende Programm gestartet werden, Parameter kann die HTML-Seite über eine Formulareingabe abfragen und dem Serverprogramm übergeben. Ausgaben des Programms werden über den HTTP-Server an den Client zurückgeliefert; wenn die Ausgaben im HTML-Format gehalten sind, können sie also gleich aufbereitet dargestellt werden.

Das Serverprogramm kann in einer beliebigen Programmiersprache erstellt werden, da lediglich von der Standardeingabe gelesen und auf die Standardausgabe geschrieben werden muß. Da das HTTP zustandslos ist, muß für jede Anfrage über HTTP/CGI eine neue Netzverbindung etabliert werden, was der Performanz abträglich ist. Bei Bedarf ist der Zustand des Client speziell zu kodieren und evtl. serverseitig zu speichern. Auch werden keine speziellen Datentypen, sondern lediglich Zeichenketten übertragen. Die nötigen Konvertierungen der Daten beim Client und beim Server sind vom Programmierer zu leisten.

 

	HTTP/CGI	JDBC	RMI	CORBA
Sprachunab-hängigkeit	+	-	-	+
Datenbank-transparenz	-	-	+	+
Netzwerk-transparenz	-	-	-	+
Sicherheit	Paßwörter unverschlüsselt --> SSL	Paßwörter unverschlüsselt; Logik im Applet (fat client)	eigene Implementation	Security Service, wenn implementiert

Tabelle 1: Netzzugriff auf Datenbanken mit verschiedenen Technologien

JDBC: Java Database Connectivity (JDBC) ist eine Schnittstelle von der Programmiersprache Java zu relationalen Datenbanken. Entsprechende JDBC-Treiber werden von vielen Datenbankherstellern angeboten, um eine Verbindung zwischen ihren Systemen und der Java-Welt herzustellen. Im Java Development Kit (JDK) sind Klassen enthalten, die SQL-Abfragen an Datenbanken aus der Anwendung heraus ermöglichen. Um Datenbankanfragen. fest in die Client-Anwendungen einprogrammieren zu können, muß die angefragte Datenbank und ihre Struktur bei der Entwicklung der Anwendung bekannt sein. Aus Sicherheitsgründen wird es jedoch nicht selten abgelehnt, die Anwendungslogik vollständig im Client bekannt zu machen oder Mechanismen im Client bereitzustellen, die die Datenbankstruktur zur Laufzeit ermitteln können. Mit der Struktur ist zudem auch noch nicht zwingend ihre Bedeutung bekannt. Die Performanz von JDBC-Aufrufen ist in der Regel deutlich besser als über HTTP/CGI, man ist jedoch auf Java fixiert, hat mit den Java Applets 'fat clients', die direkt mit der Datenbank kommunizieren und muß auf Datenbanktransparenz verzichten.

Java RMI: In reinen Java-Umgebungen ist Remote Method Invocation (RMI) eine geeignete Variante, mit hoher Transparenz auf entfernte Objekte zuzugreifen. Methoden eines RMI-Objekts können von Java Virtual Machines netzwerkweit so aufgerufen werden, als ob sie Methoden lokaler Java-Objekte wären. Datenbankobjekte ließen sich also in RMI-Objekten kapseln. RMI ist im JDK seit der Version 1.1. enthalten. Man ist jedoch auf Java als Programmiersprache festgelegt. Java RMI ist nicht geeignet, mit Objekten oder Anwendungen, die in anderen Programmiersprachen geschrieben wurden, zusammenzuarbeiten.

CORBA: Die Common Object Request Broker Architecture (CORBA) ist eine Spezifikation der Object Management Group (OMG), die eine verteilte Objektkommunikation vorsieht. Objekte können danach mit anderen Objekten kommunizieren, auch wenn sie in verschiedenen Programmiersprachen geschrieben wurden oder auf unterschiedlichen Plattformen existieren, denn bestehende Anwendungen oder auch Datenbanken lassen sich als CORBA-Objekte kapseln. Zwischen den verschiedenen CORBA-Objekten vermittelt der Object Request Broker (ORB), eine auf allen Rechnern des verteilten Systems laufende Komponente. Über ihn sind die verteilten CORBA-Objekte systemweit quasi wie lokale Objekte erreichbar, unabhängig von Programmiersprache und Rechnerplattform.

Der Einsatz von CORBA bietet zwar eine hohe Flexibilität, ist jedoch auch mit nicht unbeträchtlichem Mehraufwand beim Systemdesign verbunden. Insbesondere die Definition der Komponentenschnittstellen muß hier sehr sorgfältig geschehen, um nicht Flexibilität für zukünftige Erweiterungen vorzeitig zu verbauen. Steht die Erweiterbarkeit nicht im Mittelpunkt eines Projekts, dann kann sich die Festlegung auf eine Datenbank lohnen, um wesentlich mehr serverseitige Basisfunktionalität anbieten zu können (Hosenfeld 1998).

5. Architektur eines flexiblen Zugriffsystems

Für das Projektziel sind die ersten drei im vorangehenden Abschnitt genannten Technologien nicht geeignet. Der Zugriff über HTTP/CGI ist zustandslos; in der Regel nutzt man eigene Skripten zur Generierung statischer HTML-Seiten für jede zu integrierende Datenbank. Dafür ist, wie auch bei JDBC, a priori Wissen über die Datenbankstrukturen nötig. Weiterhin ist man sowohl bei JDBC als auch bei RMI auf Java als Programmiersprache festgelegt.

Die Forderung nach der Integrierbarkeit weiterer Datenbestände (s. Abschnitt 3.1) ist praktisch nur zu erfüllen, wenn Unabhängigkeit von Plattform und Programmiersprache des Datenservers besteht. Somit ist eine CORBA-basierte Client-Server-Architektur besonders geeignet, um flexibel auf verteilte Datenbanken zuzugreifen (vgl. auch Tabelle 1). Die Datenbanken werden als CORBA-Objekte (Datenserver) gekapselt. Die definierten Schnittstellen können von jedem Datenanbieter implementiert werden, so daß eine Integration später verfügbarer Datenbanken problemlos möglich ist.

Der CORBA-Standard sieht darüber hinaus weitere Dienste vor, die im Entwurf eines Nutzerführungssystems bereits berücksichtigt werden können, um dann in das System integriert zu werden, sobald eine Implementierung vorliegt.

Im weiteren Projektverlauf wird eine derartige Architektur exemplarisch für den WADABA-Bestand implementiert. Sie wird in diesem Abschnitt kurz vorgestellt.

1. Überblick über die Gesamtarchitektur

Die Gesamtarchitektur läßt sich in drei Schichten einteilen. Als Benutzungsschnittstelle fungiert auf der Client-Seite (1. Schicht) ein WWW-Browser, mit der der Benutzer verschiedene Applets von einem WWW-Server lädt. Sie enthalten grafische Benutzungselemente, die die nutzerfreundliche Formulierung von Anfragen erlauben und die Kommunikation mit den anderen Komponenten des TIDE-Systems anstoßen.



Abb. 1: Architektur des Gesamtsystems

Dazu stellen sie Methoden zur Kommunikation mit den Middlewarekomponenten (2. Schicht) bereit, über die die einzelnen TIDE-Dienste erreichbar sind (s. Abschnitt 5.3). Die dritte Schicht beinhaltet die proprietären Datenhaltungssysteme wie z.B. Datenbanken oder Dateisysteme.

Die Kommunikation wird über CORBA-konforme Komponenten abgewickelt. CORBA ist ein Standard für Architektur und Schnittstellen in verteilten Systemen. Wir stützen uns auf die Version 2.0, für die uns die Implementation eines Object Request Brokers (ORB) zur Verfügung steht. Als ORB wird der Visibroker der Fa. Inprise eingesetzt. Der ORB gewährleistet das Verschicken von Nachrichten und das Umsetzen von Typinformationen. Er kann auch Dienste wie Naming, Trading, Event, Security u.a. übernehmen (Abb. 1).

Indem der proprietäre Zugang zum Datenbestand einer datenhaltenden Stelle in eine spezielle CORBA-Kapsel eingeschlossen wird, steht der Datenbestand als Menge von Objekten eines Datenservers zur Verfügung. Diese Objekte können mit dem übrigen TIDE-System über die vorgesehenen Schnittstellen kommunizieren. Ein Datenserver beantwortet eingehende Anfragen bzgl. seines Datenbestandes. Er ermöglicht damit sowohl die Suche nach vorgegebenen Kriterien als auch ein Navigieren durch den Datenbestand und liefert gefundene Metadaten oder Originaldaten.

2. Benutzungsschnittstelle

Um sich einen Datenbestand zu erschließen, hat der Benutzer die in Abschnitt 1.3.3 genannten Möglichkeiten der Suche und der Navigation. Beide Zugriffsformen sollen durch grafische Benutzungsschnittstellen unterstützt werden. Realisiert werden sie als Java-Applet, die vom TIDE-WWW-Server abgerufen werden können und im Browser des Nutzers ablaufen.

Erwartungsgemäß wird am häufigsten nach Daten mit Bezug zu einem bestimmten Gebiet oder Zeitraum gesucht werden, aber auch zu bestimmten Themen oder Schlagworten sollte eine gezielte Suche möglich sein. Zu diesen Suchkriterien wird jeweils ein eigener Dialog entwickelt. Abb. 2 zeigt einen Dialog zur Eingabe geografischer Koordinaten.

Aus derartigen Einzelabfragen lassen sich durch logische Verknüpfungen komplexe Anfragen zusammensetzen. Dieses wird in einem weiteren Frame desselben Applets unterstützt (Abb. 3). Ergebnisse der Abfragen werden zunächst im Überblick (Abb. 4) und dann auf Anforderung im Detail (Abb. 5) präsentiert. Zur Unterstützung einer Navigation wird noch ein Graph-Browser entwickelt.



Abb. 2: Applet zur Eingabe geographischer Koordinaten



Abb. 3: Applet für die Eingabe von Anfragen



Abb. 4: Anfrageergebnisse im Überblick



Abb. 5: Anfrageergebnisse im Detail

3. Dienste

Das TIDE-System ist als eine Menge von Diensten konzipiert, die als Server in Form von CORBA-Objekten implementiert werden. Durch die CORBA-Konformität wird sowohl die Verteilung der einzelnen Dienste möglich als auch Plattform- und Sprachunabhängigkeit erreicht. Das Zusammenwirken der verschiedenen Dienste basiert auf Schnittstellendefinitionen, die die Kommunikation zwischen den CORBA-Objekten regeln.

Der zentrale Dienst des TIDE-Systems ist der Zugriff auf Metainformation und Daten. Diese Funktionalität wird für jeden Datenbestand in einem Datenserver gekapselt. Neben Originaldaten und ihren Beschreibungen liefert der Datenserver auch Navigationsinformation zu seinem Datenbestand.

Ein Anfrageserver nimmt die Anfragen eines Client entgegen und leitet sie an Datenserver weiter. Dazu sind die in den Browser-Applets zusammengestellten Anfragen an entsprechende Objekte passender Datenserver weiterzuleiten, die von datenhaltenden Stellen implementiert wurden. Als Ergebnisse liefert der Anfrageserver zunächst eine Übersicht aller passenden Datenobjekte zurück. Sie wird als Liste mit kurzen beschreibenden Informationen (Objektidentifikation, Abstract, mögliche Formate, Verweise auf weitere Informationsquellen) im Browser dargestellt.

Der Raumbezug der Umweltdaten macht es häufig erforderlich, geographische Koordinaten als Parameter von Anfragen einzugeben. Um dies komfortabel zu unterstützen, halten Kartenserver Satellitenbilder und Karten einschließlich ihrer beschreibenden Information vor. Sie erleichtern dann als Hintergrundbild die Eingabe raumbezogener Information als Anfrageparameter. Geplant ist die Realisierung eines externen Kartenservers, der CORBA-Schnittstellen implementiert und ebenfalls für andere Clients zur Verfügung steht. Existierende Dienste wie das Retrieval-Interface für heterogene raumbezogene Daten von Wrobel (Wrobel 1998) könnten dank der CORBA-Architektur ebenfalls mit wenig Aufwand in das Gesamtsystem integriert werden und die Formulierung von Anfragen und die Präsentation von Ergebnissen übernehmen.

Rohdaten sollen in der Regel in Standardformaten an die Benutzer übertragen werden, damit ihnen die Weiterverarbeitung erleichtert wird. Für die Konvertierung zwischen verschiedenen Formaten werden Formatserver in das System aufgenommen.

Aktuelle Überlegungen betreffen weiterhin die Funktionalität eines Servers, der Beziehungen zwischen Metadaten-Objekten zur Verfügung stellt. Hierunter fallen z.B. Synonyme, Übersetzungen und Verwandtschaftsbeziehungen. Ein Spezialfall von Verwandtschaftsbeziehung ist z.B. eine Klassifikation. Ein Synonymserver könnte gleichbedeutende Begriffe zu einem Suchbegriff liefern. So kann die Suche nach einem Begriff entsprechend ausgedehnt werden, was beispielsweise bei der Suche in mehrsprachigen Datenbeständen hilfreich sein kann. (Das Problem der Mehrsprachigkeit ist auf diese Weise allerdings nicht ausreichend zu lösen.) Thesaurusserver könnten Verwandtschaftsbeziehungen zwischen Begriffen verwalten. Allgemeine Navigationsinformationen, die nicht nur für einen Datenserver relevant sind, könnten so der Orientierung von Nutzern dienen, die noch nach für sie passenden Suchbegriffen suchen. Ein Datenserver könnte sich dann auf einen wohlbekannten Thesaurusserver beziehen oder diese Information selbst liefern.

In (Benn et al. 1998) wird beschrieben, wie Beziehungen zwischen Metadaten-Objekten dargestellt und auswertbar gemacht werden können. Informationsagenten, die möglichst autonom nach relevanter Information suchen sollen, kann so Hintergrundinformation zum durchsuchten Datenbestand vermittelt werden. Nikolai/Kramer (1998) entwickeln die Thesaurus-Föderationen, ein Konzept zur autonomieerhaltenden Integration verschiedener Thesauri.

Die beschriebenen Server bzw. Objekte können aus Gründen der Lastverteilung auch verteilt als Prozesse auf unterschiedlichen Rechnern gestartet werden. Einige ORBs bieten die Möglichkeit, mehrere Implementationen desselben Dienstes an nahezu beliebigen physikalischen Orten im Gesamtsystem zu starten und einem Client einen bestimmten Server zuzuweisen, was die Ausfallsicherheit erhöht. Hier ist jedoch zu überprüfen, ob sich die Replikation lohnt (Aufwand durch Konsistenzsicherung).

4. Schnittstellen der Systemkomponenten

Von großer Bedeutung für die Gesamtarchitektur ist ihre Modularisierung und die Kommunikation zwischen den Komponenten. Mit der Schnittstellenbeschreibung wird festgelegt, welche Komponente welche Methoden einer anderen Komponente aufrufen kann. Sie erfolgt formal in IDL (Interface Definition Language), einer standardisierten Definitionssprache, die eine von der Implementierung - insbesondere der verwendeten Programmiersprachen - unabhängige Beschreibung der Schnittstellen eines Server-Objektes erlaubt.

Die Festlegung von Schnittstellen ist nicht trivial. Sie müssen allgemein genug sein, um möglichst jeden denkbaren Anwendungsfall abzudecken; sie sollen aber genügend genaue Spezifikationen zulassen. Sie müssen einfach genug sein, damit Datenlieferanten sie nicht für zu umfangreich halten oder gar vor einer Implementierung zurückschrecken; gleichzeitig muß für die adäquate Abbildung praxisrelevanter Anwendungsgebiete und ihrer Komplexität ein Mindestmaß an Detaillierung möglich sein. Abbildung 6 zeigt exemplarisch die Schnittstellendefinition eines Datenservers.

Mit Hilfe eines speziellen IDL-Compilers können IDL-Schnittstellen maschinell auf Quellcode in verschiedenen Programmiersprachen abgebildet werden. So entstehen schnell Programmgerüste, in die dann die Implementierungen der Schnittstellen eingefügt werden können.

 

Abb. 6: IDL-Schnittstelle für Datenserver

6. Zukünftige Arbeiten