Konzeption und Realisierung einer WWW-basierten Benutzerführung des Wattenmeerinformationssystems WATiS

Norman Wolff

April 1998

  1 Einleitung

Eines der größten Probleme in unserer Zeit ist die stetig steigende Belastung der Umwelt. Diese Problematik eröffnete ein neues Forschungsgebiet innerhalb der Informatik: die Umweltinformatik. Die Umweltinformatik soll einen Beitrag zur Untersuchung, Behebung, Vermeidung oder Minimierung von Umweltbelastungen und Umweltschäden leisten. Ein hieraus resultierendes Problem ist die große Menge der anfallenden Daten und deren Verwaltung. Ein weiteres Problem ist die Interpretierbarkeit von Umweltdaten. Es ist oft sehr schwierig, manchmal sogar unmöglich, Umweltdaten ohne weitere beschreibende Information zu verstehen. Diese zusätzliche beschreibende Information wird im allgemeinen als Metainformation oder Metadatum bezeichnet. Eine einheitliche Terminologie hat sich noch nicht durchgesetzt. Die elektronische Verarbeitung von Metainformation bietet eine Möglichkeit, Umweltdaten nutzbar zu machen. Diese Systeme, die Metainformation über Umweltdaten verarbeiten, werden als Metainformationssysteme bezeichnet.

Am GKSS Forschungszentrum Geesthacht werden umfangreiche Projekte im Wattenmeer an der deutschen Nordseeküste durchgeführt. Die dabei anfallenden Daten sollen vollständig, langfristig und konsistent gespeichert werden und für eine heterogene Benutzergruppe aus Forschungseinrichtungen, Verwaltung und Behörden verfügbar sein. Um diese Aufgabe bewältigen zu können, wurde das Wattenmeerinformationssystem WATiS am GKSS Forschungszentrum aufgebaut. Hier werden die anfallenden Projektdaten entsprechend ihrer heterogenen Struktur in der Wattenmeerdatenbank WADABA unter dem relationalen Datenbanksystem Oracle auf einem zentralen Datenbankserver innerhalb der GKSS gespeichert. Die WADABA ist für neue Projekte erweiterbar. Hier werden auch Daten des nationalen und trilateralen Wattenmeermonitorings, in Zusammenarbeit mit den beiden anderen Wattenmeer-Anrainerstaaten Dänemark und den Niederlanden, verwaltet. Die WADABA enthält auch Daten von den GOAP(Greifswalder-Oder-Aestuar-Austausch-Prozesse)-Projekten, die im Bereich des Greifswalder Boddens an der deutschen Ostseeküste erhoben worden sind.

Um auf die Datenbestände der WADABA zugreifen zu können, wurde das Benutzerführungssystem LOTSE entwickelt. Die Entwicklung dieses Systems wurde innerhalb einer Hochschulkooperation zwischen dem Institut für Gewässerphysik am GKSS Forschungszentrum und der Universität Hamburg am Fachbereich Informatik durchgeführt. Innerhalb der Hochschulkooperation enstanden so mehrere Versionen des Benutzerführungssystems LOTSE. Der Nachteil der bisher entwickelten Systeme bestand hauptsächlich in ihrer beschränkten Verfügbarkeit. Die Systeme wurden als Terminalanwendung und als Prototypen auf Apple-Mactintosh-Rechnern implementiert. Mit dem Internet als Grundlage für ein Rechnernetz kam der Wunsch auf, die Benutzerführung auf diesem Wege weltweit verfügbar zu machen und eine einheitliche Oberfläche auf verschiedenen Rechnerplattformen zu realisieren.

Diese Arbeit ist innerhalb des Projekts TIDE (Tools for an Integrative view of Distributed Enviromental data) enstanden, das sich im Rahmen der Hochschulzusammenarbeit gebildet hat und das die Konzeption einer Architektur für eine einheitliche Sicht auf heterogene, verteilte Umweltdaten als Forschungsschwerpunkt hat.

Die Entwicklung eines neuen Benutzerführungssystems LOTSE/Web ist Gegenstand dieser Arbeit. Der Zugriff auf die Datenbestände soll in Zukunft über das World Wide Web WWW erfolgen. Den Rahmen für die zu erreichende Funktionalität bildeten teilweise die bisher entwickelten Systeme. Mit dem LOTSE/Web wurde eine Benutzerführung entwickelt, die auf verschiedenen Rechnerplattformen eine einheitliche Oberfläche bietet.

Die Arbeit gliedert sich in neun Abschnitte. Nach der Einleitung wird im Kapitel 2 die Aufgabenstellung für diese Arbeitet näher erläutert. In Kapitel 3 wird die Ausgangssituation dargestellt. Kapitel 4 befaßt sich mit dem Internet und seinen Möglichkeiten. In Kapitel 5 werden zwei Metainformationssysteme exemplarisch vorgestellt, die bereits eine Anbindung an das WWW besitzen. Kapitel 6 diskutiert Grundlagen von Graphischen Fenstersystemen, die für die Konzeption des LOTSE/Web einfließen. In Kapitel 7 wird die Konzeption des LOTSE/Web vorgestellt. Insbesondere werden die Anforderungen an das neue System diskutiert und Möglichkeiten für den Datenzugriff vorgestellt. Kapitel 8 beschreibt die Realisierung des neuen Systems. Den Schluß der Arbeit bildet das Kapitel 9 mit dem Ausblick. Im Anhang befinden sich eine Bedienungsanleitung für das neue System, ein Java-Programmtext sowie Verzeichnisse für Literatur, Abkürzungen, Abbildungen und Tabellen.

  2  Aufgabenstellung

Die Neuentwicklung einer Benutzerführungskomponente des Wattenmeerinformations-systems WATiS ist das Ziel dieser Diplomarbeit. Es soll ein unkomplizierter Zugriff von dezentral mit Verbindung zum Internet arbeitenden Benutzern ermöglicht werden. Als grundlegende Funktionalität ist die Navigation durch die enthaltenen Datenbestände und die Wiedergabe von Information zu realisieren, die sich sowohl in verschiedenen Datenbanken als auch in speziellen Dateisystemen befinden können. Die Funktionalität der bisher entwickelten Benutzerführungen soll in die neue Benutzerführungskomponente des WATiS integriert werden.

Folgende Aufgaben sind für die Neuentwicklung der Benutzerführung zu betrachten:

• Die Benutzerführung ist plattformunabhängig zu entwickeln.
• Der Zugriff auf heterogene Daten soll von einer gemeinsamen Oberfläche ermöglicht werden.
• Daten mit Beschreibungen anderer Datenquellen sollen in das WATiS integriert werden können.
• Die Werkzeuge für die graphische Oberfläche sollen frei verfügbar und für die wesentlichen Plattformen einsetzbar sein.

• Die Nutzerführung soll auf WWW-Basis entwickelt werden.

Einschränkungen

Aufgrund der Migration der bisherigen Datenbank der Wattenmeerdaten auf ein System eines anderen Herstellers ergaben sich Probleme mit der Datenlage. Die Funktion Projektionen im 4-dimensionalen Suchraum (vgl. WINT94) wird in der Neuentwicklung nicht angeboten (siehe 8.7).

3 Ausgangssituation

"Umweltinformatik ist eine Teildisziplin der Angewandten Informatik, die mit Methoden und Techniken der Informatik diejenigen Informationsverarbeitungsverfahren analysiert, unterstützt und mitgestaltet, die einen Beitrag zur Untersuchung, Behebung, Vermeidung oder Minimierung von Umweltbelastungen und Umweltschäden leisten können." (PAGE94, S.16). Die Bedeutung der Umweltinformatik resultiert aus den besonderen Eigenschaften der Umweltdaten im Vergleich zu herkömmlichen Daten anderer Teilgebiete der Informatik.Umweltdaten sind besonders komplex, da sie die natürliche Umwelt abbilden. Deren typische Merkmale sind Vielfalt, Heterogenität, Dynamik, Offenheit, Rückkopplung und Nichtlinearität. Diese Komplexität von Umweltdaten läßt sich beispielsweise an drei typischen Merkmalen festmachen:Fachlicher Bezug: Welches Objekt wurde mit welchen Mitteln betrachtet ?

• Räumlicher Bezug: Für welche räumliche Ausdehnung haben Werte Gültigkeit ?

• Zeitlicher Bezug: Für welchen Zeitraum haben die Werte Gültigkeit ?

Die Wichtigkeit dieser Merkmale wird unterschiedlich eingeschätzt, jedoch überwiegt die Auffassung, daß der Raumbezug das wichtigste Merkmal von Umweltdaten ist.
 

3.1 Metadaten und Metainformation
Im Umweltbereich werden Systeme eingesetzt, die mit sehr großen Datenmengen arbeiten. Man denke z.B. an das Umweltmonitoring, wie automatische Schadstoffmessungen, die stündlich, wenn nicht sogar noch öfter, an vielen verschiedenen Orten gleichzeitig erhoben werden. Um dieser ungeheuren Datenflut Herr zu werden, ist formalisiert gespeicherte Information über bereits angelegte Datenbestände nötig.

Daraus ergibt sich die Notwendigkeit der Bereitstellung und Verwaltung von zusätzlicher Information mindestens zu den folgenden Problemen:

• Bereits vorhandene Datenbestände müssen für einen potentiellen neuen Nutzer aufzufinden sein.
• Die Semantik von Datenbeständen muß möglichst genau beschrieben sein, um eine korrekte Interpretation der Daten zu gewährleisten.

• Der Zugriff auf aufgefundene Datenbestände muß unterstützt werden.

Die Bereitstellung von zusätzlichen Daten und Informationen für die genannten Probleme wird erst seit einigen Jahren ausführlich diskutiert. Nachdem anfangs ohne gemeinsame Terminologie versucht wurde, Lösungsmöglichkeiten zu beschreiben, setzen sich mittlerweile vor allem die Begriffe Metadaten und Metainformation durch. Vereinfacht läßt sich dabei sagen, daß Metadaten Daten über Daten sind. Die Begriffe Metadaten und Metainformation werden nicht einheitlich benutzt, so daß es schwierig ist, sie zu unterscheiden. Im allgemeinen Sprachgebrauch hat sich aber der Begriff Metainformation, als Oberbegriff für Daten über Daten oder Information über Daten, herauskristallisiert. Folgende Strukturierung von Metainformation ist möglich (vgl. DENZ94):

• Semantische Metainformation: Semantische Metainformation dient zur inhaltlichen Beschreibung von Informationsbeständen.

• Syntaktische Metainformation: Die syntaktische Metainformation beschreibt alle DV-technischen Mechanismen bis hin zum Zugriff auf einen identifizierten Datenbestand.

• Strukturelle Metainformation: Strukturelle Metainformation beinhaltet, wie die beschriebenen Objekte strukturiert bzw aggregiert sind.

• Navigatorische Metainformation: Die navigatorische Metainformation dient quasi als Meta-Metainformation, da sie primär nicht als Metainformation dient, sondern in der Hauptsache dafür da ist, andere Metainformation aufzufinden.

 Die elektronische Verarbeitung von Metainformation wird als große Hilfe im Kampf gegen die täglich anwachsende Datenflut gesehen. Gerade im Bereich der Umweltinformatik werden derzeit neue Konzepte und Modelle für Metainformationsverarbeitung entwickelt und implementiert. Für die Nutzung solcher Metainformationssysteme sprechen z.B. folgende Aspekte:

• Die Ansprechpersonen für relevante Datenbestände können für Außenstehende nicht identifiziert werden.
• Relevante Datenbestände werden, wenn überhaupt, nur sehr mühsam über ungezielte Abfragen gefunden.
• Relevante Datenbestände werden nicht berücksichtigt, da sie nicht gefunden werden, obwohl sie vorhanden sind.

• Relevante Datenbestände werden noch einmal erhoben, obwohl sie bereits an anderer Stelle vorliegen.

 
3.1.1 Metadatenformate
Metainformationssysteme halten ihre Metadaten oft in einem eigenen Format. Das ist zum Beispiel auch beim WATiS der Fall. Dieses ist zum Teil auch historisch bedingt, da es bei der Konzeption von älteren Metainformationssystemen, die heute noch im Einsatz sind, noch keine standardisierten Metadatenformate gab. Mittlerweile existieren einige Metadatenformat-standards, doch trotzdem ist ihre Verwendung oftmals problematisch. Für einige Anwendungen sind diese Standards einfach zu mächtig, um sich derer zu bedienen. Es haben sich jedoch einige Standards herauskristallisiert, die immer breitere Verwendung finden.Dazu gehören das Directory Interchange Format (DIF), das Hierarchical Data Format (HDF) und das Climate and Enviromental Data Retrieval and Archive (CERA)-Datenmodell.
 

3.1.1.1 Das Directory Interchange Format DIF
Das Directory Interchange Format (DIF) ist ein Metadatenformat, das von dem Global Change Master Directory (GCMD) verwendet wird und von der NASA entwickelt wurde. Das GCMD ist eine umfangreiche Sammlung von Umweltdaten, die z.B. von der Atmosphäre, von der Hydrosphäre, von den Ozeanen etc. erhoben worden sind. Das DIF ist ein Standard, der dazu benutzt wird, um Verzeichniseinträge zu erstellen, die eine Datengruppe beschreiben (s. URL). Ein DIF-Eintrag besteht aus einer Anzahl von Feldern zur Spezifizierung der Daten. Die Minimalanforderung besteht aus sechs Feldern (vgl. DIF98).
 

3.1.1.2  Das Hierarchical Data Format HDF
 Das Hierarchical Data Format (HDF) ist eine Mischform von Metadaten und Rohdaten, ein sogenanntes selbstbeschreibendes Datenformat. Es ist eine Bibliothek und ein Multiobjekt-Datenformat, das den Transfer von graphischen und numerischen Daten zwischen verschiedenen Rechnerplattformen unterstützt (vgl. HDF98). Das HDF Dateiformat hat folgende Eigenschaften:

• Vielseitigkeit: Das HDF unterstützt verschiedenste Datenmodelle. Jedes Datenmodell definiert einen speziellen aggregierten Datentyp und bietet eine API für Lesen, Schreiben und die Organisation der Daten und Metadaten. Die Datenmodelle unterstützen vieldimensionale Arrays, Rasterbilder und Tabellen.
• Das HDF ist selbstbeschreibend, d.h. Applikationen ist es möglich, die Struktur und den Inhalt einer Datei zu interpretieren, ohne daß weitere Information nötig ist.
• Flexibilität: Mit dem HDF ist es möglich, verschiedene in Beziehung stehende Objekte zu verbinden und den Zugang zu diesen als Gruppe oder als individuelle Objekte zu ermöglichen.
• Erweiterbarkeit: Neue Datenmodelle können leicht integriert werden.

• Portabilität: HDF-Dateien können auf den unterschiedlichsten Plattformen eingesetzt werden, wobei es dann keine Rolle spielt, wo die Datei erstellt wurde und auf welcher Plattform die Datei weiterverarbeitet wird.

3.1.1.3 Das Climate and Enviromental Data Retrieval and Archive CERA-Datenmodell
Das CERA Metadatenmodell ist geeignet, um Klima- und Umweltdaten zu beschreiben und wurde vom Deutschen Klimarechenzentrum (DKRZ) und dem Alfred-Wegener-Institut (AWI) entwickelt. Es bildet das Directory Interchange Format (DIF) ab. Die CERA Metadaten enthalten Informationen eines Experiments, z.B. der globalen Erwärmung der Erde, und der dazugehörigen Datensätze. Im CERA-Datenmodell ist ein Experiment definiert als eine Zusammenfassung von Datensätzen. Datensätze sind definiert als Zusammenfassungen von zweidimensionalen Datenfeldern (vgl. LAUT95). Die Experimentinformation wird in drei Untergruppen aufgeteilt:

• Technische Information, die z.B. den Namen des Experiments, die Beschreibung des Experiments etc. enthält.
• Suchinformation, die allgemeine Schlüsselworte, Schlüsselworte für die Fachdisziplin und die Unterdisziplin enthält. Diese Suchinformation soll es fachfremden Nutzern erlauben, die gespeicherten Daten nach interessierten Themen zu durchsuchen.

• Experimentbeschreibung, die z.B. die Angabe der Kampagne, die geographische Lage etc. enthält.

Die Experimentinformation enthält die übergreifende Beschreibung der dazugehörigen Daten. Die genaue Beschreibung der Klimadaten selbst liefert die Datensatzinformation, die in vier Kategorien aufgeteilt ist: Supportinformation, Inhaltsinformation, Technische Information und Interne Speicherung.
 

3.2 Umweltinformationssysteme
Umweltinformationssysteme dienen zur Speicherung und Verarbeitung von Umweltdaten. In PAGE94 wird eine Klassifizierung informationsverarbeitender Systeme im Umweltschutz vorgenommen, nämlich in:

• Überwachungs- und Kontrollsysteme, die entweder dem Umweltmonitoring, z.B. Überwachung der Belastung von Wasser, Luft, Boden oder der Steuerung und Regelung technischer Abläufe im Rahmen der computergestützten Prozeßführung dienen.

• Konventionelle Informationssysteme, die zur Speicherung, Organisation, Integration und Wiedergabe von Daten heterogener Struktur dienen.

• Auswertungs-, Analyse- und Simulationssysteme, die die Verarbeitung von Umweltdaten mittels komplexer mathematisch-statischer Auswertungsmethoden und Modellrechnungen unterstützen.

• Entscheidungsunterstützende Systeme, die einem Entscheidungsträger direkte Unterstützung bei der Entscheidungsfindung bieten, indem sie ihm Hilfen zur Bewertung von Alternativen oder zur Begründung von Entscheidungen anbieten.

• Integrierte Umweltinformationssysteme. In diese Klasse fallen Systeme, die sich nicht den zuvor genannten Klassen eindeutig zuordnen lasssen, weil sie z.B. über mehrere Komponenten unterschiedlicher Klassen verfügen (s. 3.2.2).

3.2.1 Geographische Informationssysteme
In Geographischen Informationssystemen (GIS) werden Informationen verwaltet, analysiert und präsentiert, allerdings immer mit Bezug zum Raum: Die repräsentierten Objekte befinden sich an einem bestimmten Ort, sie haben eine räumliche Ausdehnung, und sie weisen Verteilungsmuster im Raum auf. Informationen geographisch zu organisieren, ist ein charakteristisches Merkmal eines GIS (vgl. GERK95). Der Raumbezug von Daten wird über Koordinaten einer bestimmten Raumbezugsbasis, der sogenannten primären Metrik, repräsentiert. Typischerweise findet ein zweidimensionales Modell Anwendung, welches nach dem kartesischen Koordinatensystem die Punkte einer Ebene erfassen kann. Für auswertende Anwendungen ist es oft sinnvoll, darauf eine sekundäre Metrik zu definieren. Die dritte Raumkoordinate zur Modellierung von Höhenangaben fehlt in vielen GIS ebenso wie eine Zeitachse. Insbesondere die Zeit ist aber als möglicher Primärschlüssel zur Verknüpfung von Daten von großer Bedeutung. Ein Umweltinformationssystem mit einer raumbezogenen Datenbasis kann als ein spezielles GIS aufgefaßt werden (vgl. BILL94).

3.2.2 Komponenten Integrierter Umweltinformationssysteme
Integrierte Umweltinformationssysteme haben keine einheitliche Architektur. In den möglichen Komponenten spiegeln sich viele unterschiedliche Methoden der Informatik wider. Sie bieten eine vielfältige Unterstützung bei der Bewältigung umweltbezogener Aufgaben. Integrierte Umweltinformationssysteme können als Rahmen für das Zusammenspielen unterschiedlicher Bausteine betrachtet werden. Inegrierte Umweltinformationssysteme werden je nach Aufgabenstellung individuell gestaltet. Im folgenden Abschnitt werden mögliche Komponenten vorgestellt (vgl. PAGE94 und OSWA95):

• Datenbanksysteme
• Metainformationssysteme
• Netzwerke
• Benutzungsschnittstellen
• Benutzerführungen
• Hypertextsysteme
• Digitale Karten
• Wissensbasierte Systeme
• Auswertungs-, Analyse- und Simulationssysteme

• Überwachungs- und Kontrollsysteme

 
3.2.2.1 Datenbanksysteme
Zur Speicherung und Wiedergabe von Daten dienen Datenbanksysteme. Für einen großen Teil der Aufgaben im Umweltbereich bilden Datenbasen die Arbeitsgrundlage. Man kann nach dem physischen Ort der Speicherung in zentrale oder verteilte Datenhaltung unterscheiden. Beide Formen sind für Umweltinformationssysteme relevant. Der Einsatz typischer relationaler Datenbanksysteme für die Abbildung aller Teilaspekte von Umweltinformation ist keine adäquate Lösung. Man stößt auf große Schwierigkeiten, wenn man komplexe Umweltobjekte gleichermaßen in Form von normalisierten Relationen darzustellen versucht. Eine Lösung dieses Problems kann in der Verwendung von objektorientierten Datenbanken liegen, die jedoch noch keinen relevanten Verbreitungsgrad haben.
 

3.2.2.2 Metainformationssysteme
Ein Metainformationssystem ist ein Informationssystem, das Informationen über das Vorhandensein und den Zugang zu anderen Informationen verarbeitet. Umweltinformationssysteme und Metainformationssysteme werden als Begriff oft synonym verwendet. Eine Ursache hierfür könnte sein, daß Umweltdaten ohne Metainformation nicht sinnvoll verarbeitet werden können.
 

3.2.2.3 Netzwerke
Insbesondere für verteilte Lösungen, wie Integrierte Umweltinformationssysteme, sind Rechnernetze die notwendige Grundlage. Die Verfügbarkeit von Umweltdaten über ein Netz, z.B. dem Internet, bietet eine große Chance, eine Klassifizierung über die vorhandenen Daten vorzunehmen.
 

3.2.2.4 Benutzungsschnittstellen
Eine komfortable und anwendungsfreundliche Gestaltung von Benutzungsschnittstellen wird durch graphische Oberflächen mit kombinierter Tastatur- und Mausbedienung ermöglicht. Ein wichtiger Grundsatz ist das Abbilden der gesamten Funktionalität einschließlich einer Online-Hilfe auf die Oberfläche. Dadurch wird der Arbeitsablauf sowohl für die ständigen als auch für die gelegentlichen Benutzer vereinfacht. Der Einarbeitungsaufwand kann durch eine günstige Gestaltung niedrig gehalten werden (vgl. HUEB90). Das typische Erscheinungsbild einer graphischen Oberfläche nennt man in diesen Zusammenhang "Look and Feel."

3.2.2.5 Benutzerführungen
Als Navigations- und Wiedergabekomponenten von Informationssystemen dienen Benutzerführungen. Sie geben Anwendern Hilfestellung beim Auffinden relevanter Datenbestände und sollten daher mit einer benutzungsfreundlichen, graphischen Oberfläche ausgestattet sein. Die wichtigsten Ziele des Einsatzes einer Benutzerführung werden im folgenden Absatz dargestellt:

• Unterstützung der Recherche zur Informationsbeschaffung durch geeignete Navigations- und Wiedergabekomponenten

• Enthaltene Informationsangebote dem Benutzer transparent machen

• Durch Verknüpfung von Sachdaten und Metadaten im Kontext die Interpretierbarkeit von Daten sicherstellen und Inhalte verdeutlichen

• Den Nutzungsgrad von Daten erhöhen

• Angemessene Präsentation von Datenbeständen

• Zugriff über Rechnernetze ermöglichen

• Weitere Methoden der Datenverarbeitung integrieren oder Verzweigungen zu anderen Programmkomponenten ermöglichen

Als Navigationsmethoden innerhalb von Benutzerführungen können dienen: Index-Listen, stichwortbezogene Suche über Thesauri oder Schlagworte, ortsbezogener Zugriff über digitale Karten, Hypertext- und Hypermediasysteme, Einschränkungen des Such- und Sichtbarkeitsbereichs, natürlichsprachliche Anfrageschnittstellen. Nach dem erfolgreichen Recherchieren sollen die Suchergebnisse dem Benutzer in einer angemessenen Form präsentiert werden (vgl. ZIEG93).
 

3.2.2.6 Hypertextsysteme
Herkömmliche Texte in Form von Büchern besitzen eine sequentielle Struktur. Die Abschnitte von Hypertexten dagegen sind durch Referenzen in einer netzwerkartigen Struktur verbunden. Faßt man einen Hypertext als Netz auf, dann bilden die einzelnen Textteile die Knoten und die Beziehungen die Kanten dieses Netzes (siehe 4.2.7.2).

3.2.2.7 Digitale Karten
Der Raumbezug von Daten läßt sich in Systemen mit graphischer Oberfläche besonders gut durch digitale Karten oder auch mit Satellitenbildern veranschaulichen. Digitale Karten entstehen beispielsweise durch das Digitalisieren von topographischen Karten. Unterschieden werden hierbei Raster- und Vektorgraphiken.

3.2.2.8 Wissensbasierte Systeme
Grundlage von wissensbasierten Systemen ist symbolisches, formal repräsentiertes Wissen in Form von Wissensbasen. Zu einer Wissensbasis gehören Fakten und Regeln sowie Inferenz-Operationen zum Ziehen von Schlußfolgerungen. Wissensakquisition beschreibt den Begriff der formalisierten Übertragung von Experten in die Wissensbasis. Wissensbasierte Systeme werden daher auch als Expertensystem bezeichnet. Ein wissensbasiertes System ist selbsterklärungfähig, wenn es den Prozeß der Schlußfolgerungen belegen kann. Im Dialog mit dem Benutzer wird ein Lösungsvorschlag aus der Wissensbasis abgeleitet und dadurch Expertenwissen verfügbar gemacht. Die Lösungswege sind im Fall selbsterklärender Systeme dokumentierbar und lassen sich daher nachvollziehen. Das Problem unpräziser Fragestellungen kann für Umweltinformationssysteme mit Hilfe spezieller Expertensysteme gelöst werden, die natürlichsprachliche Anfrageschnittstellen realisieren. Im Vergleich zu wissensbasierten Expertensystemen verfolgen konnektionistische Systeme, sogenannte neuronale Netze, einen anderen Ansatz. Die Struktur des Netzes ist mit dem Zusammenschluß von Nervenzellen vergleichbar. Die Leistungsfähigkeit hängt unter anderem von Netzarchitektur, Lernalgorithmus und Eingabegrößen ab. Das Wissen ist nach Abschluß einer Lernphase innerhalb der Netzstruktur gespeichert. Diese Repräsentation von Wissen wird als "subsymbolisch" bezeichnet, da sie ausschließlich durch die Gewichtungen der Verbindungen innerhalb des Netzes repräsentiert wird. Diese Form verhindert aber die Selbsterklärungsfähigkeit neuronaler Netze. Neuronale Netze können fehlerhafte Daten auswerten und ermöglichen auch bei großer Parameterzahl Analysen komplexer Vorgänge, die mit anderen Methoden nur schwer zu verarbeiten sind (vgl. ULTS94).

3.2.2.9 Auswertungs-, Analyse- und Simulationssysteme
Zu den Auswertungs- und Analysenverfahren, die im Zusammenhang mit Umweltdaten zur Anwendung kommen, zählen statistische Auswertungsmethoden und Modellrechnungen. Dazu gehören insbesondere Ausbreitungs- und Prognoserechnungen, Bildinterpretations-verfahren und die Simulation. Simualtionssysteme realisieren Methoden von Modellbildung und Simulation zum besseren Verständnis komplexer Zusammenhänge. Sie ermöglichen Experimente an rechnergestützten Modellen, die gemäß der Fragestellung durch komplexitätsreduzierende Abbildung realer Systeme entstehen. Man unterscheidet gemäß der Wertebereiche der Variablen zwischen diskreten, kontinuierlichen und kombinierten Simulationsmodellen. Die Methoden der Simulation sind insbesondere auch dann einsetzbar, wenn die realen Objekte nicht für Versuche zur Verfügung stehen, wie z.B. im Fall der Klimaforschung. Hauptzielrichtungen des Einsatzes im Umweltbereich sind dabei die Erforschung komplexer Umweltsysteme bezüglich deren innerer Struktur und die Untersuchung der Auswirkungen menschlichen Handelns auf diese Umweltsysteme. Beispiele sind Modelle für die Untersuchung von Ökosystemen, des Klimas, von Schadstoffausbreitungen oder von Zusammenhängen zwischen Umwelt und Wirtschaft (vgl. GRUE94).

3.2.2.10 Überwachungs- und Kontrollsysteme
Für die automatische Erhebung von Umweltdaten, beispielsweise im Rahmen des Umweltmonitorings, werden Überwachungs- und Kontrollsysteme eingesetzt. Ein wichtiges Verfahren ist die Fernüberwachung, bei der Meßwerte vor Ort durch Sensoren erfaßt und über Meßnetze an Informationssysteme weitergegeben werden. Luft- und Gewässergütemeßnetze sind Beispiele hierfür. Ein weiteres Verfahren ist die Fernerkundung über Flugzeuge oder Satelliten. Es lassen sich zwei verschiedene Arten von Fernerkundungssystemen unterscheiden, aktive und passive. Ein aktives Fernerkundungssystem erzeugt selbständig elektromagnetische Strahlung und mißt deren zurückgestrahlten Anteil. Passive Fernerkundungssysteme sind hingegen auf fremde Strahlungsquellen angewiesen (vgl. GUEN 94). Ein weiteres wichtiges Anwendungsgebiet ist die Steuerung und Regelung technischer Prozesse, beispielsweise zur Minimierung von Schadstoffausstoß und Energieverbrauch.
 

3.3 Das Wattenmeerinformationssystem WATiS
Das Wattenmeer ist ein Naturraum von überregionaler Bedeutung, der sich an der Nordseeküste von den Niederlanden über Deutschland bis nach Dänemark erstreckt. Zu seinem Schutze arbeiten diese drei Anrainerstaaten eng zusammen. Der auf deutschem Gebiet liegende Teil des Wattenmeeres wurde sogar zum Nationalpark erklärt. Nutzung und Schutz stehen in einem Interessenkonflikt, denn das Wattenmeer ist auch Lebensgrundlage für viele Menschen; z.B. die Fischereiwirtschaft oder die Tourismusbranche wirken nicht unerheblich auf das Gesamtsystem Wattenmeer ein. Die Reaktionen des Gesamtsystems Wattenmeer auf natürliche oder direkt vom Menschen hervorgerufenen Störungen, aber auch Schutzmaßnahmen sind von großem Interesse. Die hierzu laufenden Forschungsprojekte sollen eine Wissensgrundlage schaffen, deren Elemente Langzeitbeobachtungen ausgewählter Parameter, flächendeckende Kartierungen sowie eine begleitende Ökosystemforschung sind. In diesem Kontext übernimmt das Wattenmeerinformationssystem WATiS mit der zentralen Wattenmeerdatenbank WADABA die Aufgabe der Informationsvermittlung. Unter Information wird dabei stets der zusammenhängende Satz von Sachdaten, geometrischen Daten und der dazugehörigen Dokumentation verstanden. Hauptnutzer des WATiS sind die für das Wattenmeer zuständigen Behörden, das Umweltbundesamt und wissenschaftliche Einrichtungen. Das Wattenmeerinformationssystem WATiS gliedert sich in zwei Teilbereiche:

• Der eine Teil umfaßt die Speicherung und Verwaltung der Daten,

• der andere beinhaltet die Zugangsmechanismen zu den gespeicherten Daten.

Die anfallenden Daten aus der Wattenmeerforschung werden auf einem zentralen Datenbankserver innerhalb der GKSS gehalten. Diese Datenbank mit den gespeicherten Wattenmeerdaten hat den Namen Wattenmeerdatenbank WADABA bekommen.
Um auf diese Daten benutzergerecht zugreifen zu können, wurden im Laufe der Hochschulkooperation mehrere Nutzerführungen entwickelt. Diese Nutzerführungen sind mit dem Oberbegriff LOTSE (Land Ocean Thematic Search Engine) (siehe 3.4) betitelt worden. Die verschiedenen Versionen des Nutzerführungssystems LOTSE wurden entwickelt, um den Benutzern außerhalb der GKSS, aber auch den Mitarbeitern innerhalb der GKSS eine Möglichkeit zu geben, auf die Daten der WADABA zuzugreifen.
Ein zentraler Aspekt der ständigen Weiterentwicklungen von LOTSE ist die Datenhaltung. Bis zu der jetzigen, neuen LOTSE-Konzeption wurde nur die zentrale Datenbank innerhalb der GKSS betrachtet. Es war bisher nicht möglich, auch auf andere Datenbestände zuzugreifen, die nicht in der zentralen Datenbank gehalten werden, z.B. auf einer Datenbank, die über das Internet erreichbar ist. Von dieser starren Haltung möchte sich die neue LOTSE-Konzeption lösen und sich nicht mehr vorrangig abhängig von zentralen Datenhaltungskonzepten machen. Prinzipiell soll es möglich sein, alle an das Internet angeschlossenen Datenquellen zu erreichen, sofern die dafür erforderliche Metainformation und die technischen Voraussetzungen existieren. Somit kann der LOTSE dann einen sehr hohen Grad an Flexibilität und Universalität erreichen, die WADABA ist dann "nur" noch eine Datenbank, die über das Internet erreicht wird, tatsächlich aber immer noch innerhalb der GKSS steht. Die WADABA wird aber noch lange im Mittelpunkt des WATiS stehen, weil die darin enthaltenen Datenbestände sehr komplex und auch vollständig sind. Die Möglichkeit der Erreichbarkeit von anderen Datenquellen über das Internet ist eine wesentliche Neuerung der Konzeption des LOTSE/Web. Durch die Verwendung von Internet-Technologie ist es möglich, die starren Zugangsmechanismen zu den betreffenden Datenquellen aufzubrechen. Die Konzeption des LOTSE/Web schafft die Möglichkeit, auch auf andere Datenbestände zuzugreifen als auf die Wattenmeerdatenbank WADABA. Wie diese Datenbestände organisiert sind, soll nicht mehr allein im Vordergrund stehen. Wichtig ist der Zugang zu den Datenbeständen, der dann möglichst unabhängig von der Strukturierung dieser Bestände konzipiert sein sollte. Die Konzeption beinhaltet die Diskussion von tradionellen Datenhaltungs- und Zugangskonzepten, aber auch neu enwickelte Konzeptionen, wie z.B. Remote Method Invocation (RMI) und die CORBA-Architektur (Common Object Request Broker Architecture) (siehe Kapitel 7.11).
 

3.3.1 Die Wattenmeerdatenbank WADABA
Die Daten aus der Wattenmeerforschung werden momentan auf zwei Datenbankservern innerhalb der GKSS gehalten. Dies ist bedingt durch die zur Zeit noch laufende Migration der WADABA von einem IBM-DB2-Datenbanksystem auf ein relationales ORACLE-Datenbanksystem. Auf der DB2-Datenbank sind alle Daten, die bis Ende 1996 eingeladen worden sind, enthalten. In der ORACLE-Datenbank sollen in Zukunft alle Altdatenbestände und die neu einzuladenden Forschungsdaten gehalten werden. Ist die Portierung der Daten abgeschlossen, wird die DB2-Datenbank abgeschaltet, so daß nur noch die ORACLE-Datenbank als zentraler Speicherort aller Wattenmeerdaten verwendet wird. Die grundlegende Organisation der Wattenmeerdatenbank wird sich durch die Migration nicht verändern.
 

3.3.2 Projektorientierte Struktur der WADABA
Beim Aufbau der WADABA waren folgende Randbedingungenen zu erfüllen(vgl. KRAS94):

• Die WADABA muß auf neue, noch nicht bekannte Projekte erweiterbar sein.
   

   

• Die einzelnen Projekte müssen gemäß ihrer sehr unterschiedlichen Vorgehensweise abgebildet werden.
   

   

• Die Daten müssen ausreichend dokumentiert sein, um auch nach vielen Jahren interpretiert werden zu können.

• Das Datenmodell muß allen Projekten eine gemeinsame topologisch komplexe und zeitlich variable Geometrie behandeln.

• Daten verschiedener Verarbeitungsstufen (Rohdaten, verarbeitete Daten,
   

  Synthesedaten, etc.) sollen gleichzeitig in der WADABA liegen.

• Teile der Datenbank müssen in mehreren Versionen vorliegen können.

• Der Gesamtdatensatz - Sachdaten, Dokumentation und Geometrien - muß konsistent fortgeführt werden.

Diese Anforderungen werden durch die Projektorientierung der WADABA erfüllt. Aus Sicht der Datenmodellierung ist jedes Projekt die oberste, in sich abgeschlossene Einheit. Nach außen hin stellen sich Projekte in Form einer Kurzbeschreibung, der beteiligten Institutionen und der verwendeten Methoden dar. Ihr inneres Verhalten hängt vom Forschungsgegenstand und den Fragestellungen ab.
 

3.3.3 Sachdaten in der WADABA
Sachdaten in der WADABA sind die eigentlichen im Wattenmeerbereich erhobenen Daten. Allerdings können auch aggregierte Daten aus früher erhobenen Daten in der Datenbank gespeichert sein. Die beschreibenden Daten, die sogenannten Metadaten, die Informationen zu den Sachdaten liefern, gehören nicht in diese Kategorie. Die Speicherung der Sachdaten erfolgt projektorientiert (siehe 3.3.2.). Vor Ort, d.h. dort, wo die Projekte durchgeführt werden, werden die Daten zusammengestellt, z.B. in Programmen wie Excel oder DBase. Daten mit Ortsbezug haben als Namen den Positionsschlüssel, der frei vergeben werden kann. Zusammen mit dem Projektkürzel und dem Versionsdatum bildet er eine eindeutige Identifikation der Position. In der WATiS-Administration werden die Daten später kontrolliert und in die WADABA eingeladen. Das Tripel von Projektkürzel, Positionsschlüssel und Versionsdatum ist innerhalb der WADABA eindeutig, da kein Projektkürzel mehrfach vorkommen kann. Das Versionsdatum dient zur Aufnahme einer sich geographisch ändernden Position in der Zeit. Wenn z.B. an einer Position mehrere Messungen zu verschiedenen Zeiten vorgenommen wurden, die Station aber in dieser Zeit "gewandert" ist, bleibt die Station trotzdem die gleiche für eventuell anfallende Vergleiche, auch wenn sie zwischendurch an einem anderen Ort liegt. Die Insel Trischen ist ein Beispiel für eine sich im Laufe der Zeit ändernde Position. Der Name bleibt immer gleich, aber die geographische Lage ändert sich im Laufe der Zeit.
 

3.3.4 Metadaten in der WADABA
Zu den gespeicherten Sachdaten gibt es immer auch beschreibende Daten, die sogenannten Metadaten. An vorderster Stelle steht bei der Dokumentation der Projekte immer eine Projektbeschreibung. In dieser Beschreibung werden das Ziel und die Arbeit beschrieben, die ein Einzelprojekt durchführt oder durchgeführt hat. Zu den Projektbeschreibungen gibt es Institutsbeschreibungen, d.h. welches wissenschaftliche Institut an dem betreffenden Projekt beteiligt ist. Datenschutzrechtlich wurde mit den Erhebern abgestimmt, daß mindestens eine Institutsadresse angegeben wird. Alle weiteren Angaben erfolgen auf freiwilliger Basis. Neben diesen allgemeinen Informationen zu einem Projekt gibt es spezielle Informationen zu Projekttabellen bzw. zu den Parametern dieser Tabellen. Die Parameterbeschreibung kann z.B. angeben, mit welcher Methode die Daten erhoben wurden, die Einheit, in der der Parameter gemessen wurde, der prozentuale und absolute Meßfehler, der bei der Messung aufgetreten sein kann. Datenbankinterne Angaben zur Speicherung des Parameters, wie z.B. der Spaltentyp (z.B. varchar2, char, integer, long, etc.), werden im datenbankeigenen Data-Dictionary gehalten. Diese Metadaten zu den Projekten werden von einem separaten Datenbank-Benutzer DOKUMENT in der Datenbank verwaltet. Man kann deshalb von einem speziellen Datenbankbereich sprechen, in dem die Metadaten gespeichert sind. Alle beschreibenden Daten von Projekten werden in diesem Bereich gehalten. Hier gibt es verschiedene Tabellen, die z.B. die Projektbeschreibungen aufnehmen oder die Methoden, mit der Daten erhoben wurden, näher beschreiben. Die projektorientierte Struktur der WADABA macht es möglich, z.B. verschiedene Methodenbeschreibungen in einer Tabelle, die nach Projektkürzeln geordnet ist, zu speichern.
 

3.3.5 Koordinaten in der WADABA
Die Speicherung der Ortsbezüge geschieht im WATiS ebenfalls in einem separaten Datenbereich. Wichtigstes Erkennungsmerkmal ist hier die Position, die aus Projektkürzel, Positionsschlüssel und Datum der ersten Gültigkeit besteht. Die Koordinaten werden als zweidimensionale geographische Längen- und Breitenangaben auf dem Ellipsoiden des Europäischen Datums abgelegt. Positionen können Punktstationen (Messpunkte), Linien (Hochwasserlinie) oder Flächen (Inseln) sein. Eine Punktstation besteht aus dem Positionsschlüssel und einer geographischen Koordinate in Längen- und Breitengrad. Eine Linie ist ein Vektor, bestehend aus einem Punkt wie in einer Punktstation, und einer Menge von Folgepunkten. Durch die Verbindung der einzelnen Punkte entsteht eine Linie mit einem Anfangspunkt und einer Menge von Fortsetzungspunkten. Sind der Anfangspunkt und der letzte Punkt identisch, handelt es sich um einen geschlossenen Linienzug, d.h. also um eine Fläche. Die Identifikation der Fläche geschieht durch einen Objektindikator, der innerhalb des Linienzuges liegt. Theoretisch sind damit alle Kombinationen von Positionen möglich. Es kann eine große Fläche mit einer kleineren innerhalb dieser großen Fläche geben, es kann Linien an einer Fläche geben, etc.
In der Datenbank jedoch wird beim Einladen von Koordinaten eine grobe Rasterung in sogenannten Kacheln durchgeführt, um z.B die Suche nach Positionen und deren graphische Darstellung zu vereinfachen. Jede Kachel entspricht dem Sechzehntel einer topographischen Karte im Maßstab 1:25000, so daß sich eine Kantenlänge von etwa 3x3 km für jede Kachel ergibt. Für die Gesamtfläche folgt eine Rasterung in 107 x 108 Kacheln. Die einzelnen Kacheln sind durchnumeriert. In der Metadatentabelle POSKACLIST (Positions-Kachel-Liste) wird jeder Position eine Kachelnummer zugewiesen. Dadurch ist es möglich, über den Positionsschlüssel und die Kachelnummer die Lage einer Position mit eingeschränkter Genauigkeit zu ermitteln, ohne auf die Koordinaten der Position zugreifen zu müssen. Für den umgekehrten Weg von den Positionen zu den Sachdaten gilt die gleiche Einschränkung der Genauigkeit.
 

3.3.6 Der Menübaum
Der Menübaum der WADABA ist das Strukturelement, das die Grundlage für die navigierende Komponente für den Zugriff auf die projektspezifischen Sachdaten bildet. Alle Projekte, zu denen Daten in der WADABA gespeichert sind oder gespeichert werden sollen, werden in den Menübaum eingetragen. Es ist möglich, daß für Projekte beschreibende Daten vorhanden sind, aber noch keine Sachdaten vorliegen, da das Projekt z.B. noch nicht abgeschlossen ist. In diesem Fall kann die beschreibende Information für das Projekt schon vorher aufgenommen werden und die Aufnahme der Sachdaten auf einen späteren Zeitpunkt verschoben werden. Der Menübaum besitzt zwei Einstiegspunkte: Projekt und Thema. Beide Einstiege haben eine voneinander getrennte eigene Baumstruktur. Die Blätter beider Teilbäume sind die Projekte. Der Menübaum ist zyklenfrei. Man kann den Menübaum auch als eine Art Schlagwortverzeichnis betrachten. Jedes Projekt wird durch eine Anzahl von Schlagwörtern klassifiziert. Darum ist es im Menübaum möglich, daß Projekte mehrmals als Blätter vorkommen können, da sie verschiedenen Schlagwortkombinationen zugeordnet werden können. Daher ist der Menübaum im graphentheoretischen Sinne nicht als Baum einzuordnen. Werden jedoch die Blätter (die Projekte) weggelassen, besitzt jeder Knoten genau einen Vorgängerknoten. Alle bisherigen LOTSE-Versionen benutzen den Menübaum als zentrale Navigationskomponente bei der Datenrecherche. Der Menübaum ist von der WATiS-Administration beliebig erweiterbar und ermöglicht so die Eingliederung neuer Projekte in die Baumstruktur. Für die Eingliederung von neuen Projekten sind aber nicht zwangsläufig neue Schlagwörter notwendig. Abbildung 1 zeigt die schematische Darstellung des Menübaums.
 

            Abb. 1: Menübaum
 

3.4 LOTSE
Bislang sind vier Benutzerführungssysteme für das WATiS entwickelt worden. Der LOTSE (MVS) und der LOTSE V2 als Terminalanwendungen, das McWATiS für Apple-Macintosh-Rechner und der LOTSE/p als eine plattformunabhängige Konzeption, deren Realisierung, bedingt durch Schwächen der Entwicklungstools, sich als nicht problemlos portierbar herausstellte. Mit der rasanten Entwicklung der Internet-Technik ergab sich eine neue Alternative zur Erstellung einer neuen Nutzerführung LOTSE/Web. Diese Nutzerführung hat den Vorteil, daß sie prinzipiell nicht plattformabhängig ist und so noch mehr potentiellen Nutzern zur Verfügung gestellt werden kann.
 

3.4.1 LOTSE(MVS) und LOTSE V2
Der LOTSE (MVS) ist ein Benutzerführungssystem, das für die direkt an den Großrechner der GKSS angeschlossenen Datenterminals oder entsprechenden Terminalemulationen entwickelt wurde. Die Benutzungsschnittstelle wurde mit dem Dialogmanager Integrated System Productivity Facility (ISPF) unter dem Betriebssystem MVS/TSO implementiert. Eine menügesteuerte Oberfläche leitet den Benutzer zu den gewünschten Daten. Die Information zur Führung der Benutzer bezieht das System aus dem Menübaum (siehe Abb. 1). Damit wird sowohl die projekt- als auch die themenbezogene Suche der Daten ermöglicht. Nach Auswahl eines Projektes kann dessen Beschreibung angezeigt werden. Die für die Datenzugriffe notwendigen SQL-Statements werden automatisch generiert, so daß der Benutzer keine Kenntnisse über die Struktur der Daten oder über eine Abfragesprache, in diesem Fall SQL, haben muß. Optional ist es möglich, eigene SQL-Statements zu erstellen, um so Zugriff auf die Daten zu bekommen. Der LOTSE (MVS) wurde weiterentwickelt zum LOTSE V2 mit der Möglichkeit, die Datensuche auf benutzerdefinierte Bereiche einzuschränken. Der gesamte Suchbereich kann als ein vierdimensionaler Suchraum aufgefaßt werden. Der LOTSE V2 ermöglicht es, innerhalb dieses Suchraumes durch sogenannte Projektionen den Sichtbarkeitsbereich für die Ausgabe der Daten einzuschränken (vgl. WINT94). Zur Durchführung von Projektionen wird zunächst der Suchraum erstellt, in dem Informationen über Projekte gespeichert werden. Dieser Suchraum besitzt vier Dimensionen: Ort, Zeit, Projekt und Thema. Es wird für alle Projekte bestimmt, an welchen Orten sie zu welcher Zeit gültig sind. Realisiert wurde dieser Raum in Tabellen im Datenbanksystem DB2. Auf diesen Raum wird aus Programmen des LOTSE V2 zugegriffen. Die Portierung des Suchraums von dem Datenbanksystem DB2 auf das Datenbanksystem ORACLE ist noch nicht abgeschlossen, so daß diese Funktionalität noch nicht für den LOTSE/Web zur Verfügung steht.
 

        Abb. 2: LOTSE V2 Hauptmenü
 

3.4.2 McWATiS
 Die Benutzungsführung McWATiS wurde auf einem Apple Macintosh unter der Programmierumgebung Hypercard entwickelt. McWATiS nutzt die Bedienfreundlichkeit des Apple Macintosh und ist mit einer graphischen Benutzungsschnittstelle versehen. Es stellt den Benutzern eines Apple Macintosh die Funktionalität des LOTSEn zur Verfügung. Zusätzlich ist eine ortsbezogene Datensuche im McWATiS möglich. Diese wird durch den Benutzer mit Hilfe der Maus in Graphiken topographischer Karten, mit unterschiedlichen Maßstäben, durchgeführt. Grundlage des McWATiS ist die Einrichtung einer lokalen Datenbank unter dem RDBMS ORACLE. Der Benutzer muß sich die von ihm benötigten Daten aus der WADABA in die lokale Datenbank kopieren, um eine Datensuche durchführen zu können. Eine Verbindung zum Zentralrechner ist nur zum Laden oder Aktualisieren der Daten im lokalen Datenbestand nötig. Dieses Konzept der lokalen Datenhaltung wurde entworfen, um das System auch betreiben zu können, wenn keine Datenbankverbindung besteht. McWATiS erfüllte nur die Funktion einer prototypischen Benutzungschnittstelle und ist über dieses Stadium hinaus nicht weiterentwickelt worden (vgl. WILL93).
 

Abb. 3: McWatis

3.4.3 LOTSE/p
Durch die Wahl der Entwicklungskomponenten des McWATiS sind zu enge Leistungsgrenzen aufgetreten, um dieses System endgültig einführen zu können. Zudem mangelt es der Oberfläche an Flexibilität. Das System ist zudem auf die Rechnerfamilie Apple Macintosh beschränkt. Diese und weitere Gründe (vgl. OSWA95) führten zur Entwicklung eines neuen, portierbaren Benutzerführungssystems LOTSE/p. Den Rahmen für die zu erreichende Funktionalität bildeten teilweise die bisher entwickelten Systeme. Der LOTSE/p wurde auf einem Apple Macintosh entwickelt und sollte auf andere Betriebssysteme, vorzugsweise auf Unix-Workstations, übertragbar sein. Die Portierung ermöglicht eine weite Verbreitung innerhalb der Anwendergruppe, so daß die Benutzer ihre gewohnten Fenstersysteme weiterhin verwenden können. Um einen hohen Grad an Portierbarkeit zu gewährleisten, wurde das Graphical-User-Interface(GUI)-Tool XVT zur Implementation der Oberfläche herangezogen. Im nachhinein erwies sich das Portieren auf andere Betriebssysteme als äußerst zeitaufwendig, so daß nur eine Implementation des LOTSE/p auf der Plattform Apple Macintosh existiert.
 

Abb. 4: LOTSE/p
 

 3.4.4 Vergleich der bisherigen LOTSE-Versionen
Einen Vergleich der bisher entwickelten LOTSE-Nutzerführungen bietet die folgende Tabelle. Sie stellt Eigenschaften von LOTSE V2, McWatis und LOTSE/p gegenüber.

 
 

	LOTSE V2	McWATiS	LOTSE/p
graphische Benutzungsschnitt-stelle	nein	ja	ja
Zugang über das Internet	ja (über Terminalemulation)	nein	nein
lokale Datenhaltung möglich	nein	ja	ja
portabel	nein	nein	ja (mit Einschränkungen)
Einschränkung des Sichtbarkeitsbereiches von Daten	ja	nein	nein
Plattform	MVS	lauffähiger Prototyp auf Apple Macintosh	lauffähiger Prototyp auf Apple Macintosh

Tab.1 : Eigenschaften von LOTSE V2, McWATiS, LOTSE/p

4 Das Internet
 

Das Internet ist das größte Computer-Netzwerk der Welt. Es birgt ein ungeheuer großes Potential an Informationen und Daten, die größtenteils kostenlos zur Verfügung gestellt werden. Ursprünglich nur im Bereich der Hochschulen verbreitet, erkennen immer mehr Firmen den Nutzen eines Anschlusses an das Internet. Besonders in Übersee wird das Internet mehr und mehr für wirtschaftliche Transaktionen benutzt, während in Europa die kommerzielle Nutzung des Internet noch weitgehend in den Kinderschuhen steckt.
 

4.1 Entwicklung und Historie des Internet
In den späten 60er Jahren begann in den USA die staatliche Unterstützung von Experimenten zur Vernetzung von Computern. Die Advanced Research Projects Agency (ARPA, ab 1972 Defense Advanced Research Projects Agency DARPA), die dem amerikanischen Verteidigungsministerium unterstellt ist, forcierte mit erheblichen finanziellen und personellen Mitteln die Entwicklung im Bereich der Rechnervernetzung. Es ist kein Zufall, daß ausgerechnet das US-Verteidigungsministerium die Initiative ergriff: Das Ministerium war stark daran interessiert, über ein Kommunikationsmedium zu verfügen, das auch unter ungünstigen Bedingungen die Übertragung von Daten zuverlässig gewährleistet. Selbst beim Ausfall von Teilen des Netzes sollte das System funktionsfähig bleiben. Neben der militärischen Anwendung eröffnete die Vernetzung von Computern im wissenschaftlichen und auch immer mehr im kommerziellen Bereich völlig neue Anwendungsmöglichkeiten. Um bestimmte wissenschaftliche Probleme mit Hilfe von Rechnern zu lösen, sind oft Maschinen mit sehr großer Rechenleistung erforderlich. Zu der damaligen Zeit begann erst das Zeitalter der Integrierten Schaltungen und der damit einsetzende Miniaturisierungsprozeß, der wachsende Rechenleistung bei kleinerer Bauweise erst ermöglichte. Über ein Rechnernetz ist es möglich, von beliebigen Stellen im Netz Kontakt zum Großrechner aufzunehmen. An welchem Ort sich dieser Rechner befindet, spielt keine Rolle mehr. Allgemein ermöglicht die Vernetzung von Rechnern die Nutzung aller im Netz vorhandenen Ressourcen. Unterschiedliche Hardware, Software, Daten und Peripheriegeräte können von allen Netzteilnehmern gemeinsam und unabhängig vom jeweiligen Standort genutzt werden. Dementsprechend war das erste Entwicklungsziel der ARPA, einige wenige an geographisch unterschiedlichen Punkten verteilte, verschiedenartige Hostrechner miteinander zu verbinden.
Physikalisch wurde das Netz über angemietete Leitungen mit einer Übertragungsrate von 50 Kbit/s realisiert. Um den diversen Rechnersystemen Rechnung zu tragen, wurden eigene kleine Rechner, sogenannte IMP´s (Interface Message Processor), den jeweiligen Rechnern vorgeschaltet. Diese gleichartigen IMP´s bildeten, miteinander vernetzt, das eigentliche Netzwerk. Die Hostrechner kommunizierten miteinander über den ihnen zugeordneten IMP. Die IMP´s ihrerseits waren dabei nur für den Transport der Nachrichten zwischen den Hosts verantwortlich. Die ersten Herausforderungen waren: 1. ein Subnetz aus Telefonleitungen und Vermittlungsknoten aufzubauen, das Resource Sharing erlaubte, 2. die erforderlichen Protokolle zu verstehen, zu gestalten und für die unterschiedlichen Rechnertypen zu implemetieren, um die neuen Subnetze zur Kommunikation nutzbar zu machen.
Ende 1969 war eine erste Implementierung von TELNET, dh. Durchführung von Sitzungen auf entfernten Rechnern, und von FTP, d.h. Transfer von Dateien zwischen entfernten Rechnern, vorhanden. Damit war das sogenannte Arpanet geboren, das sich durch viele Verbesserungen von einem Laborexperiment zu einem funktionsfähigen System entwickelte. Als das Arpanet bereits einsatzfähig war, begann die ISO (International Standards Organisation) mit der Normierung von Netzwerken. Die allgemeinen Erfahrungen bei der Entwicklung des Arpanet gingen zwar mit in die Normierung ein. TCP/IP wurde allerdings kein ISO-Standard. Dennoch behauptet sich TCP/IP bis heute als das Übertragungsprotokoll schlechthin, auch außerhalb der USA. Der Grund hierfür liegt wieder in einem Beschluß der US-Regierung, den Einsatz von offenen Systemen in staatlichen Organisationen und vom Staat geförderten Projekten vorzuschreiben. Als offene Betriebssystemumgebung wurde UNIX gefordert. Die US-Regierung entschied sich für den Einsatz von Berkeley UNIX (BSD, Berkeley Software Distribution) und gegen die AT&T Version, weil sowohl TCP/IP als auch die darauf basierenden Anwendungen, z.B FTP, Telnet, Teil des BSD-Betriebssystems waren. UNIX setzte sich sehr schnell als Betriebssystem in offenen Umgebungen durch. Damit war der Grundstein für die Verbreitung von TCP/IP als Übertragungsprotokoll gelegt.
Mitte der 80er Jahre begann die amerikanische National Science Foundation (NSF), Interesse am Internet zu zeigen. Um allen amerikanischen Universitäten den Zugang zum Internet zu ermöglichen, gründete sie das NSFNET. Um immer mehr Institutionen anzuschließen und einem immer weiter zunehmenden Verkehr gerecht zu werden, wurde ein System auf Backbones realisiert, das die großen Rechenzentren miteinander verband. Damit übernahm die NSF immer mehr die Aufgaben des Arpanet, das schließlich Ende 1989 vom US-Verteidigungsministerium aufgelöst wurde. Auch in Europa bestand die Notwendigkeit, Universitäten und Forschungseinrichtungen eine schnelle und kostengünstige Kommunikationsinfrastruktur bereitzustellen. In Analogie zum NSF-Backbone der USA wurde 1992 Ebone, der Europäische Internetbackbone, in Betrieb genommen. Mittlerweile erfreut sich das Internet immer größerer Beliebtheit und vermeldet täglich eine Steigerung der Benutzerzahlen. Auch immer mehr private Nutzer tauchen in die Welt des Internet ein, um auch auf diese Weise ihr Informationsbedürfnis stillen zu können. Um die steigende Zahl der Internetnutzer verkraften zu können, wird ständig an der Technik des Internet gearbeitet. Das wichtigste Argument ist hier die Geschwindigkeit: Immer schnellere Netze werden gebraucht, um den Datenverkehr im Internet nicht zum Erliegen zu bringen.
 

4.2 Informationsdienste im Internet
In diesem Kapitel werden einige ausgewählte Informationsdienste im Internet vorgestellt. Einige dieser Informationsdienste haben mittlerweile an Bedeutung verloren, wie z.B. Gopher und WAIS. Diese Informationsdienste sind zwar immer noch im Internet vertreten, doch treten sie langsam in den Hintergrund. In einem scheinbar nicht endenden Boom befindet sich das World Wide Web (WWW). Aktuelle Informationen werden fast nur noch über das WWW präsentiert. Dienste wie E-Mail und FTP sind da eher von unspektakulärer Natur. Sie sind aber äußerst effektiv und werden von fast allen Nutzern des Internet angewandt (vgl. LIU96).
 

4.2.1 E-Mail
Electronic Mail, oder kurz E-Mail, erlaubt den Austausch von Nachrichten über das Internet.Voraussetzung für die weltweite Kommunikation über E-Mail ist die Eindeutigkeit von Mailadressen. Im Internet ist durch das Domain Name System (siehe 4.4) die Eindeutigkeit von Rechnernamen gewährleistet. Da auf Rechnern Benutzeraccounts eindeutig sein müssen, liegt es doch sehr nahe, die Kombination Benutzername/Domainname als eindeutige Identifizierung für Mailadressen zu verwenden. Als Schreibweise wurde das Schema user@domain eingeführt. Ein Beispiel einer gültigen Maildresse ist Norman.Wolff@gkss.de. Der größte Vorteil von E-Mail ist die Geschwindigkeit. Braucht ein Brief mit der traditionellen Post in die USA u.U. mehrere Tage, so ist eine E-Mail mitunter schon nach wenigen Minuten am Bestimmungsort. Wenn allerdings unverschlüsselte E-Mails verschickt werden, kann sich der Benutzer nicht sicher sein, wer alles seine Nachrichten mitliest.
 

4.2.2 FTP
Das File Transfer Protocol (FTP) ist das am häufigsten verfügbare Verfahren zur Dateiübertragung im Internet. Es ähnelt dem Anmelden auf einem fernen Rechner, wobei die Benutzer nur eine beschränkte Anzahl von Kommandos ausführen bzw. bei Anonymous-FTP nur auf eine begrenzte Menge von Dateien zugreifen können. Die öffentlich zugänglichen Archive werden Anonymous-FTP-Archive genannt, da sich dort beliebige Benutzer einloggen können (wobei die E-Mail-Adresse als Paßwort eingegeben wird). Die Suche nach bestimmten Dateien gestaltet sich als äußerst unkomfortabel und langwierig, wenn der Platz im Filesystem nicht bekannt ist, so daß dieses als größtes Manko von FTP angesehen werden kann.
 

4.2.3 Telnet und Finger
Telnet ermöglicht es, eine Verbindung zu einem fernen System aufzubauen, als würde man sich von einem angeschlossenen Terminal aus anmelden. Die Internet-Dienste, die im allgemeinen über Telnet angeboten werden, unterscheiden sich nicht von Diensten, die durch direktes Einwählen in ein System, z.B. über Modem, verfügbar sind. Finger wurde dazu entwickelt, Informationen über die Benutzer auf einem fernen Rechner zu liefern, wie z.B. den vollständigen Namen, der zu einer E-Mail-Adresse gehört.
 

4.2.4 Gopher
Im Gegensatz zu FTP erleichtert Gopher die Orientierung in der Welt der Informationsressourcen. Der Gopher-Client präsentiert ein Menü mit Texteinträgen, aus dem der Benutzer einfach einen Menüpunkt anwählt und damit unter Umständen in ein anderes Menü geführt wird, so lange, bis der Benutzer die gewünschte Information erhalten hat. Gophers Einschränkungen zeigen sich an der begrenzten Zahl der unterstützten Dateiformate und Dienste, auf die er verweisen kann. Im Moment ist es Gopher lediglich möglich, ASCII-Texte auszugeben, wenngleich auch binäre Datenübertragung möglich ist, wobei diese Daten von anderer Software angezeigt werden muß. Gopher bietet Querverweise auf FTP-Archive, WAIS-Datenbanken und Telnet-Dienste.
 

4.2.5 WAIS
Das Wide Area Information Service (WAIS) dient in erster Linie zur Datenrecherche als zur Datenrepräsentation. WAIS durchsucht die Dokumente auf einer Reihe von Servern nach einem oder mehreren Stichwörtern und liefert als Ergebnis zu jedem Dokument eine Bewertung, die umso höher ausfällt, je besser ein Dokument den Suchkriterien entspricht. WAIS arbeitet auf Daten, die es vorher indiziert hat, so daß durch Benutzeranfragen angestoßene Suchvorgänge entsprechend ablaufen. Das WAIS ist, wie auch Gopher, kaum noch im Internet vertreten. Lediglich ältere Datenbestände werden über diese Dienste angeboten. Es ist nur eine Frage der Zeit, bis diese Datenbestände über das WWW verfügbar gemacht werden. Ein Grund hierfür ist die Attraktivität des WWW. Als spektakulärster Internetdienst vereint es fast alle Funktionen der übrigen Dienste und macht es so natürlich benutzerfreundlicher.
 

4.2.6 Usenet
Das Usenet stellt einen Dienst zur Verfügung, der das Übermitteln und Verteilen von Nachrichten zur Verfügung stellt. Dieser Dienst ist in sogenannten Gruppen organisiert. Jede Gruppe repräsentiert ein Sachgebiet, über das die Usenet-Benutzer diskutieren können. Es gibt zu fast allen Themen, die man sich vorstellen kann, eine sogenannte Newsgroup. Der Vergleich mit einer Zeitung ist erlaubt, präsentiert sich doch eine Gruppe wie eine weltweit einsehbare Zeitung, die jedoch den unschätzbaren Vorteil hat, daß sie zu jeder Zeit und von jedem Internet-Benutzer aktualisiert werden kann.
 

4.2.7 Konzepte des World Wide Web (WWW)
Das World Wide Web (WWW) ist der neueste und leistungsfähigste Informationsdienst im Internet. Das WWW integriert die meisten anderen Informationsdienste in verständlicher und leicht anwendbarer Weise. Bisher benötigte man einen FTP-Client für den Zugriff auf FTP-Archive oder einen Gopher-Client für einen Gopher-Server. Ein WWW-Browser bietet unter anderem Zugang zu diesen Diensten. WWW-Dokumente werden in der Sprache HTML (HyperText Markup Language) geschrieben. Die Rohfassung eines WWW-Dokuments bestehet aus (Plain)-Text, der durch Formatierungsanweisungen ergänzt wird. Über das Protokoll HTTP (HyperText Transfer Protocol) tauschen Server und Clients HTML-Dokumente untereinander aus. Ein graphischer WWW-Browser bringt das vom WWW-Server entgegengenommene HTML-Dokument in eine ansprechende Form, indem er die von den HTML-Anweisungen festgelegten Formatierungen durchführt. Das WWW wurde ursprünglich am Europäischen Zentrum für Hochenergiephysik CERN in Genf entwickelt. Die Entwicklung begann 1989, und ein Schwerpunkt der ersten Arbeiten war die Definition des Client/Server-Protokolls HTTP.
 

4.2.7.1 Querverweise (Hyperlinks)
Die Navigation im WWW wird von sogenannten Querverweisen (Hyperlinks, kurz: Links) dominiert. Diese Links sind in WWW-Dokumenten eingebettet und erleichtern so das Navigieren. In graphischen WWW-Browsern kann sich der Benutzer mit Hilfe der Maus durch das WWW bewegen, ohne auch nur eine einzige Tastatureingabe vorzunehmen. Es ist jedoch auch möglich, sich durch das WWW zu bewegen, indem man seine Zieladressen manuell dem Browser übergibt. Dies scheint etwas umständlich, hat aber den Vorteil, daß man auch tatsächlich zu seinem Ziel gelangt. Sind nämlich auf einem WWW-Dokument keine Links eingebettet, dann kann man die ganze Funktionalität der Hyperlinks nicht ausnutzen. Es ist möglich, daß ein Link auf dasselbe WWW-Dokument, auf dem man sich gerade befindet, zeigt, nur auf eine andere Position. Weiterhin kann ein Link auf ein WWW-Dokument verweisen, das auf dem gleichen WWW-Server liegt oder aber auch auf ein WWW-Dokument, das auf einem ganz anderen WWW-Server liegt. Diese Funktionalität erleichert das Navigieren für den Benutzer im WWW erheblich.
 

4.2.7.2 Hypertext
Wie im vorigen Abschnitt angedeutet, findet innerhalb des WWW das Hypertext-Konzept Verwendung. Unter Hypertext versteht man eine nichtlineare Folge von Text. Im Gegensatz zu herkömmlichem Text, der linear gelesen wird, ermöglicht Hypertext eine flexiblere Organisation des Textes, indem Referenzen zwischen verschiedenen Textteilen (Knoten) verwendet werden, um weitergehende Informationen zu erhalten. Der Text ist in Form eines Netzes organisiert, wobei jeder Knoten textuelle Informationen beinhaltet und jede Verbindung auf weitere textuelle Informationen referenziert. Der jeweilige Benutzer eines solchen Hypertext-Dokumentes bestimmt, welchen der möglichen Referenzen er folgen möchte. Der Eindruck des Benutzers, sich frei durch die Verfügung stehenden Informationen zu bewegen, ist eines der wesentlichen Kriterien für Hypertext.

 

Abb. 5: Eine einfache Hypertextstruktur
 
 

4.2.7.3 Hypertext Markup Language (HTML)
Im WWW werden ASCII-Textdokumente mit einer Auszeichnungssprache markiert, die als Hypertext Markup Language (HTML) bezeichnet wird. Dieses ist eine Erweiterung des eben beschriebenen Hypertext-Konzepts. Ein Knoten innerhalb eines HTML-Dokumentes kann nicht nur textuelle Referenzen enthalten, sondern auch sogenannte multimediale Information. Ausgangspunkt für eine Referenz können dann beispielsweise Teile von Bildern, Animationen, Video oder Text sein. Diese Erweiterung des Hypertext-Konzepts wird auch als Hypermedia bezeichnet. Mit dieser Auszeichnungssprache lassen sich Textformatierungen vornehmen, die die Struktur des Dokuments, wie z.B. die Hyperlink-Funktionalität, beschreiben. Die Formatierungen werden im allgemeinen als Tags bezeichnet. Ein Hyperlink-Tag in einem WWW-Dokument sieht dann z.B. so aus:
<A HREF="http://www.norman.wolff/intro.html">Hyperlink zum Dokument intro.html auf dem WWW-Server www.norman.wolff</A>.
Der WWW-Server interpretiert das HTML-Dokument und stellt dann dem Benutzer die Hyperlink-Funktionalität zur Verfügung. In dem obigen HTML-Fragment wird der Tag <A HREF=><A> zur Darstellung von Hyperlinks benutzt. Es ist nicht zwingend notwendig, daß WWW-Dokumente in HTML abgefaßt werden müssen. Der Nachteil von nicht strukturierten Textdokumenten ist jedoch, daß bis auf die in dem Text vorhandene Information keine weitere Funktionalität zur Verfügung gestellt werden kann. Eine komplexe Einführung in HTML findet sich z.B. in EISE96.
 

4.2.7.4 Uniform Resource Locator (URL)
Das Konzept der Uniform Resource Locator (URL) bietet eine Möglichkeit, um Ressourcen im Netz auf eine einheitliche Art und Weise zu identifzieren. Da URL´s nicht nur von Maschinen interpretiert werden sollen, sondern auch von Menschen, hat man sich zu einer kurzen und verständlichen Schreibweise entschlossen. Die URL soll aus druckbaren Zeichen ohne Leerzeichen bestehen. Um eine bestehende Ressource im Netz zu beschreiben, benötigt man im wesentlichen drei Informationen. Diese sind eine Zugriffsmethode, ein Rechnername und ein Verzeichnis- oder Dateiname. Eine gültige URL ist z.B. http://www.norman.wolff/intro.html. Hierbei ist die Zugriffsmethode http, der Servername ist www.norman.wolff und das gewünschte Dokument ist mit intro.html betitelt. Neben der Zugriffsmethode http erstreckt sich das URL-Konzept auch auf andere Inter-Protokolle, wie z.B. Gopher, FTP und Telnet. Unterschieden werden weiterhin absolute und relative URLs. Absolute URLs geben vollständig an, wie eine Datei zu erreichen ist. Relative URLs dagegen verweisen auf Dokumente, die auf dem gleichen Server liegen, wie das aktuelle Dokument.
 

4.2.7.5 WWW-Browser
In der Client/Server-Umgebung des WWW steuert der WWW-Browser (kurz Browser) die Abläufe. Er fordert über die anfängliche URL ein WWW-Dokument an, interpretiert die HTML-Anweisungen und präsentiert dem Benutzer das WWW-Dokument unter Ausnutzung aller Möglichkeiten, die die jeweilige Umgebung zur Verfügung stellt. Unterschieden wird zwischen graphikfähigen Browsern, die graphische Elemente darstellen können und Browsern, die nur in einer Textumgebung arbeiten. Beide Browser haben ihre Berechtigung, die graphischen aufgrund ihrer Möglichkeit, die Funktionalität des WWW weitesgehend auszunutzen, die Text-Browser, die den Zugang zum Internet z.B. auch auf Text-Terminals möglich machen. Im weiteren Text wird jedoch von einem graphischen WWW-Browser ausgegangen. Der Browser ist also die Schnittstelle zwischen Benutzer und Internet. Mit Hilfe des Browser navigiert sich der Benutzer durch das Internet zu seinem gewünschten Ziel. Das Verhalten des Browser ergibt sich aus dem WWW-Dokument, das er im Moment geladen hat. Sind in dem WWW-Dokument z.B. HTML-Formatierungen enthalten, die eine Graphikdatei anzeigen und eine Audiodatei abspielen ermöglichen sollen, so wird der Browser dies tun, soweit er dazu in der Lage ist. Browser gibt es praktisch für alle Rechnerplattformen. Somit ist die Nutzung des WWW unabhängig vom Rechner, solange er TCP/IP unterstützt und eine IP-Verbindung zum Internet besitzt (siehe 4.3).
 

4.2.7.6 WWW-Server
Die Server Software, die beim WWW zum Einsatz kommt, wird als WWW-Server oder Web-Server bezeichnet. Dem WWW-Server ist standardmäßig die Portnummer 80 zugeordnet. Wenn nun ein Client ein bestimmtes Dokument anfordert, holt der Server dieses Dokument und schickt es zum Client zurück. Der Web-Server macht im Grunde nichts anderes, als angeforderte Dokumente zurückzuschicken oder eine spezielle Art von Skripten auszuführen. WWW-Dokumente sind üblicherweise statische Elemente, wie z.B. HTML-Seiten, Grafikdateien oder Audiodateien. Dies hat den Vorteil, daß sie vom Web-Server dem Benutzer relativ schnell verfügbar gemacht werden können. Der Nachteil jedoch ist, daß nicht alle lokalen Informationsquellen in das WWW-Schema mit statischen Elementen passen. Wenn der Inhalt einer Datenbank im WWW präsentiert werden soll, hat es keinen Sinn, diese Informationen auf statische HTML-Seiten zu legen. Der Platzbedarf könnte zu groß werden, und auch die Suchmöglichkeiten sind in diesem Fall stark eingeschränkt.
Gateways bieten durch einen Erweiterungsmechanismus für das WWW eine Lösungsmöglichkeit für solche Probleme. Ein Gateway formt eine Informationsquelle, die nicht in das WWW-Schema paßt, so um, daß sie für den Browser wie eine Datei auf dem Web-Server erscheint. In der Praxis ist ein Gateway einfach ein Skript oder ein Programm, das über den Web-Server Benutzereingaben entgegennehmen kann und z.B. HTML-Code, eine URL oder andere Daten zum Benutzer über den Web-Server zurückschickt. Der Mechanismus zur Kommunikation zwischen Gateway und Web-Server wird als Common Gateway Interface (CGI) bezeichnet (siehe 7.11.1).
 

4.2.7.7 Hypertext Transfer Protocol (HTTP)
Das Hypertext Transfer Protocol (HTTP) wird von Browser und Web-Server zur Kommunikation benutzt. Jede Anfrage eines Browsers an einen Web-Server nach einem Dokument stellt eine neue Verbindung dar. Wenn ein Browser ein HTML-Dokument von einem Web-Server anfordert, wird eine Verbindung hergestellt, das Dokument übertragen und die Verbindung wieder beendet. Dies bedeutet, daß HTTP ein zustandsloses Protokoll ist. Die Interaktion mit dem Benutzer wird dadurch sehr erschwert. Um Reaktionen von dem Benutzer zu verarbeiten, muß jedesmal eine Verbindung zum Web-Server aufgebaut werden. Erst dann kann auf die Eingaben des Benutzers reagiert werden und ein neues Dokument zurückgeschickt werden. Derzeit wird die Variante HTTP/1.0 eingesetzt. Weitere Entwicklungen sind geplant. HTTP/1.0 ermöglicht die Vereinbarung von Datentypen zwischen Web-Server und Browser. Das Protokoll wird zu diesem Zweck um MIME-Informationen (Multimedia Internet Mail Extensions) erweitert. HTML benutzt z.B. den MIME-Typ text und den MIME-Subtyp html. Dies wird wie folgt notiert: text/html.

Abb. 6: HTML-Dokument mit vollständigem Header
 

Web-Server und Browser unterstützen noch viele andere Typen, etwa image/gif. Bei HTTP/1.0 sendet ein Browser mit jeder Anforderung einer Seite vom Web-Server eine Liste der MIME-Typen, die er unterstützt. Anhand dieser Angaben versucht der Web-Server nur solche MIME-Typen zu schicken, die der Browser-Client auch unterstützt. Der Web-Server sendet daraufhin zunächst den MIME-Typ der übermittelten Datei, eine Leerzeile und im Anschluß daran die eigentlichen Daten. Beim MIME-Typ text/plain oder text/html interpretiert der Browser die Daten selbst und zeigt sie am Bildschirm an. Bei anderen Typen entscheidet er anhand der MIME-Informationen, zu welchem externen Darstellungs- oder Abspielprogramm die Daten jeweils weiterzuleiten sind.
 

4.3 Protokolle im Internet
Welche Protokolle sind dafür verantwortlich, daß die Kommunikation im Internet reibungslos verläuft ? Die Protokollsuite, die die Verständigung erst möglich macht, heißt TCP/IP. Diese Abkürzung steht für Transmission Control Protocol/Internet Protocol, was eigentlich nur die beiden am häufigsten verwendeten Protokolle der Suite bezeichnet. Jeder Rechner im Internet unterstützt TCP/IP. Wenn Rechner A in Hamburg und Rechner B in Los Angeles die Kommunikation über die TCP/IP-Protokolle unterstützen und beide an Netze angeschlossen sind, die eine Verbindung über TCP/IP aufbauen können, dann sollten diese Rechner auch in der Lage sein, miteinander Daten auszutauschen. Netzprotokolle bestehen aus Folgen binärer Daten, die in Gruppen zu sogenannten Paketen zusammengefaßt werden. Diese Pakete werden über Medien, wie Koaxialkabel, Glasfaserkabel oder Telefonleitungen in Form von elektrischen oder optischen Signalen übertragen. Bestimmte Pakettypen enthalten Daten, während andere den Empfang von Daten bestätigen. Die Protokolle in der TCP/IP-Suite sind geschichtete Protokolle. Dies bedeutet, daß sich die Protokolle der Suite die verschiedenen Aufgaben teilen.
In diesem Abschnitt werden die drei wesentlichen Protokolle der Suite behandelt: das Internet Protocol IP, das Transmission Control Protocol TCP und das User Datagram Protocol UDP.
 

4.3.1 Das Internet Protocol IP
Das Internet Protocol bildet die Basis für die beiden anderen größeren Protokolle der TCP/IP-Familie, nämlich TCP und UDP. TCP und UDP sind in IP ähnlich eingepackt wie Briefe in Briefumschlägen. Genauso wie Briefumschläge die Adreßinformationen enthalten, ohne die der Brief nicht beim richtigen Empfänger ankommt, liefert das IP-Paket die Adresse, die für den Transport der Daten zum richtigen Internet-Rechner notwendig ist. Im Gegensatz zu den Adressen auf Postsendungen sind die Adressen auf IP-Paketen 32 Bit lange Zahlen. Der Übersichtlichkeit wegen wird die 32 Bit Zahl in vier Gruppen von jeweils 8 Bit zerlegt. Danach werden die 8-Bit-Gruppen in jeweils eine Dezimalzahl umgewandelt und durch Punkte getrennt. Da eine Internetadresse 32 Bit lang ist, gibt es maximal 2³² verschiedene Adressen.
 

4.3.2 Das Transmission Control Protocol TCP
TCP bietet im wesentlichen zwei Dienste, die bei IP fehlen: garantierte Zustellung und die Serialisierung von Daten, d.h. die Daten kommen in der Reihenfolge an, in der sie abgeschickt worden sind. TCP verwendet Sequenznummern, um die Reihenfolge festzulegen, in der die zu sendenden Daten beim Empfänger erscheinen sollen. In jedes neue IP-Paket wird neben den Daten eine um 1 erhöhte Sequenznummer eingetragen. Der Empfänger der IP-Pakete kann die bei ihm ankommenden TCP-Daten anhand der TCP-Sequenznummern registrieren und außerdem feststellen, ob sie vollständig sind. Existieren nach der Registrierung die Sequenznummern 1, 2 und 5, dann fehlen zwei IP-Pakete mit TCP-Daten. TCP veranlaßt dann die erneute Übertragung der verlorenen Pakete. Aufgrund dieser beiden Eigenschaften kann TCP einen Datenstrom zwischen zwei Rechnern simulieren, d.h. eine Verbindung, die über eine dedizierte serielle Leitung läuft, obwohl das zugrundeliegende Netz keine Punkt-zu-Punkt-Verbindung anbietet. TCP hat ein weiteres wichtiges Merkmal, nämlich Portnummern. Portnummern bilden quasi eine weitere Adreßschicht unter der IP-Adresse. Rechner werden über IP-Adressen eindeutig identifiziert. Portnummern kennzeichnen einzelne Dienste auf einem Rechner. Da man auf einem vernetzten Rechner mehrere Dienste ablaufen lassen möchte, wird ein Bezeichner gebraucht, der dem Rechner mitteilt, an wen sich die TCP-Daten richten, z.B. an den Telnet- oder WWW-Dämon. Der Rechner empfängt die TCP-Daten und ermittelt über die Zielportnummer, an welches Programm die Daten weitergereicht werden sollen. Die Portnummer besteht aus einer 16 Bit langen Zahl, so daß ein Rechner Dienste an Portnummern von 0 bis 65535 bereitstellen könnte. Portnummern unter 1024 werden in UNIX privilegierte Ports genannt, da an diesen Ports wartende Server nur mit root-Berechtigung gestartet werden können. Diese Sicherheitsmaßnahme soll verhindern, daß nicht privilegierte Benutzer einen Server an einem solchen Port starten.
 

4.3.3 Das User Datagram Protokol UDP
UDP ist ein ziemlich karges Protokoll: Es nimmt, was es von IP bekommt, und fügt dem lediglich zwei Merkmale hinzu - wobei eines davon auch noch optional ist. Das erste sind die Portnummern. Wie TCP verwendet UDP 16 Bit lange Portnummern. Der optionale Teil des UDP-Protokolls ist die Prüfsummenbildung. Mit diesem Verfahren wird festgestellt, ob die UDP-Daten während der Übertragung versehentlich geändert wurden. UDP eignet sich also für kurze Anfragen und Antworten, die bequem in einem IP-Paket Platz haben. Paßt die gesamte Information in ein einziges IP-Paket, gibt es keinen Grund, sich mit TCP zu belasten, bei dem anfangs die Sequenznummern synchronisiert werden müssen und während der Kommunikation zusätzlicher Aufwand nötig ist.
 

4.4 Das Domain Name System DNS
Das Domain Name System (DNS) wurde geschaffen, um Rechnern statt den IP-Adressen auch logische Namen zuordnen zu können. DNS verwendet hierarchische Namen, wie z.B. w3g.gkss.de, ftp.informatik.uni-hamburg.de. Diese Domänennamen (Domains) bestehen aus Textfeldern, die durch Punkte getrennt sind. Die Felder am Anfang des Domänennames sind die speziellsten, das erste bezeichnet in der Regel einen bestimmten Rechner. Die Namen gegen Ende sind die allgemeinsten, letzte bezeichnen oft die Art der Organisation, in der sich der Rechner befindet, z.B. com für commercial oder gov für staatliche Einrichtungen. Diese Namen sind eigentlich nur in den USA relevant. In Deutschland haben fast alle Rechner die Endung de, egal ob es sich um Universitäts- oder Firmenrechner handelt. Insgesamt existieren drei Hauptkomponenten, aus denen sich das DNS zusammensetzt:

• Der Domain Name Space ist ein in einer Baumstruktur angelegter, hierarchisch strukturierter Namensraum. Ausgehend von der Wurzel folgen die Top Level Domains, wie de, com, edu. Diese spalten sich dann in weitere Unterdomains auf.
   

• Name Server sind Programme bzw. Rechner, die die Informationen über die Struktur des Domain Name Space verwalten und aktualisieren. Ein Name Server hat normalerweise nur eine Teilsicht des Domain Name Space zu verwalten.

• Resolver stellen für den Client Anfragen an den Name Server. Resolver sind einem Name Server zugeordnet. Bei Anfragen, die er nicht beantworten kann, kann er aufgrund von Referenzen andere Name Server kontaktieren.
   
   
   

4.5 Sicherheitsaspekte
Im Internet werden Informationen in Form von Paketen über das Netz geschickt. Diese Pakete werden allerdings nicht gezielt von einem Rechner zu einem anderen geschickt. Die Netzwerkverbindung des Rechners ist vielmehr derart konfiguriert, daß alle Pakete, die über das Netz eingehen, gelesen und auf ihren Adressaten überprüft werden. Dies ist der Grund, weshalb einzelne Pakete von Rechnern aus eingesehen werden können, die dafür eigentlich nicht vorgesehen sind. Man nennt diesen Vorgang auch Packet Sniffing. Im Internet ist dafür Sorge zu tragen, daß kein fremder, unerwünschter Rechner Zugang zum eigenen lokalen Netzwerk erhält. Dies ist z.B erreichbar mit Hilfe von Firewalls. Als Firewall bezeichnet man ganz allgemein ein System, das die Zugriffe zwischen zwei Netzwerken kontrolliert. Manche Firewalls legen Restriktionen auf das, was übertragen werden darf, andere auf das, was nicht übertragen werden darf.
Eine weitere Methode, um die Übertragung zwischen Browser-Client und Web-Server sicherer zu machen, ist der Einsatz von Verschlüsselungsmechanismen. Secure Socket Layer (SSL) ist das am häufigsten eingesetzte Verschlüsselungsprotokoll. SSL unterstützt Authentisierung, Ver- und Entschlüsselung und stellt die Korrektheit der Daten zwischen Anwendungen sicher. Das SSL-Protokoll ermöglicht eine Kommunikation zwischen Client/Server-Anwendungen, ohne daß Dritte abhören können (vgl. SSL98).Eine weitere Möglichkeit zur sicheren Kommunikation ist die Verwendung von kryptographischen Verfahren, die z.B. beim Versenden von elektronischer Post zum Einsatz kommen (vgl. GARF96).
 

4.6 Zukunftsaspekte
Durch die täglich steigende Benutzerzahl des Internets wird es unumgänglich sein, die Netzkapazität ständig zu erweitern. Insbesondere schnellere Netzleitungen sollen den steigenden Anforderungen des Internets gerecht werden.
Auch im Bereich der Domänennamen scheint eine neue Entwicklung zutage zu treten. Es wird darüber diskutiert, ob das Namensvergabeverfahren mittelfristig umgestellt wird, da bei der alten Konzeption mit der rasanten Weiterentwicklung nicht gerechnet worden ist.
Im Bereich der Protokolle scheint sich ein wichtiger Trend abzuzeichnen: Das Protokoll HTTP soll langfristig vom Internet Inter-ORB Protokoll (IIOP), das ebenfalls auf TCP/IP basiert, abgelöst werden. IIOP, nicht zustandslos wie HTTP, ermöglicht verteilte Anwendungen in einem heterogenen Netz. HTTP wurde ja ursprünglich für den Zugriff auf HTML-Seiten konzipiert und nicht für komplexe Client/Server-Anwendungen im Internet.

5 Ausgewählte Metainformationssysteme mit WWW-Interface
 

Dieses Kapitel diskutiert zwei bereits am Internet angeschlossene Metainformationssysteme, nämlich den Umweltdatenkatalog UDK des Bundeslandes Niedersachsen und das zentrale Umwelt- und Klimadaten-Metainformationssystem ZUDIS. Besonderes Augenmerk wird hierbei auf die Nutzerführung gelegt, d.h. wie gelangt der Benutzer zu den gewünschten Daten. Zum Abschluß des Kapitels folgt eine Bewertung zu den bisherigen WATiS-Versionen gegenüber den beiden vorgestellten Metainformationssystemen.
 

5.1 Der Umweltdatenkatalog UDK Niedersachsen
Der Umweltdatenkatalog UDK wurde auf Initiative des Landes Niedersachsen ins Leben gerufen. Der Inhalt des UDKs ist die Beschreibung von Datenbeständen, die ihrerseits die primär interessierenden Umweltobjekte beschreiben. Daher läßt sich der UDK als ein Metainformationssystem klassifizieren. Mit Hilfe des UDK sollen Antworten auf folgende Fragen gefunden werden (vgl. UDK98):

• Welche relevanten Informationen aus dem Umweltbereich sind prinzipiell bei den Behörden verfügbar?
• Wo sind diese Informationen abgelegt ?

• Wie können diese Informationen erhalten werden ? Wer ist der richtige Ansprechpartner, und wie kann er erreicht werden ?

Umweltrelevante Datenbestände werden im UDK jeweils durch UDK-Objekte beschrieben. In der folgenden Abbildung wird der Zusammenhang zwischen realen Umweltobjekten, Umwelt-Datenobjekten, wie z.B. Meßreihen, Bildern, und UDK-Objekten, nämlich Informationen über Informationsbestände, veranschaulicht.
 

Abb. 7: Zusammenhang zwischen Umweltobjekten, Umwelt-Datenobjekten und UDK-Objekten (siehe LESS95).

Um eine systematische und vollständige Erfassung aller Datenbestände zu gewährleisten, werden die UDK-Objekte in einer baumförmigen Hierarchie, dem sogenannten Primärkatalog, erfaßt. Die UDK-Objekte werden durch eine Reihe von Attributen beschrieben. In diesen Attributen gibt es verschiedene Recherchemöglichkeiten für UDK-Objekte. Im UDK gibt es zwei Arten von Suchmöglichkeiten: Suche nach UDK-Objekten und Suche nach Adressen, wobei sich erstere noch weiter in allgemeine Suche, Detailsuche und Schlagwortsuche unterscheiden läßt. Bei der Adreßsuche und bei der allgemeinen Objektsuche wird ein einzelner Suchbegriff bzw. ein Teilwort auf eine ganze Reihe von Suchattributen abgebildet. Im Gegensatz dazu wird in der Detailobjektsuche und Schlagwortobjektsuche nach bestimmten Attributen bzw. Attributgruppen gezielt gesucht. Für jede Suchanfrage ist einstellbar, ob nach vollständigen Begriffen oder Teilworten gesucht werden soll und dabei die Groß-/Kleinschreibung beachtet oder ignoriert werden soll.

• Allgemeine Suche:
  Bei der allgemeinen Objektsuche kann ein Suchbegriff eingegeben werden. Zur Auswahl sinnvoller Suchbegriffe kann der Thesaurus zu Hilfe genommen werden.
  Nach dem angegebenen Suchbegriff wird in einer Menge von Attributen der UDK-Objekte gesucht. Die gefundenen Objekte werden mit ihrem Objektnamen ausgegeben. In der Ergebnisliste hat der Benutzer die Möglichkeit, eine oder beliebig viele UDK-Objekte auszuwählen, um diese vollständig anzeigen zu lassen.
   
• Detailsuche:
  Bei der Detailsuche gibt es die Möglichkeit, gezielt im Objektnamen, dem Adreßkennzeichen, in der Beschreibung sowie im Fach-, Raum- oder Zeitbezug zu suchen. So ausgewählte Suchstrings können logisch miteinander verknüpft werden und die Suche konkretisieren.
   

• Schlagwortsuche:
  Hier können Objekte über Schlagworte gesucht werden. Eingegebene Schlagworte können wiederum logisch miteinander verknüpft werden.

Als Ergebnis des Suchens wird generell eine Liste der Ergebnisse zurückgeliefert, auch wenn diese möglicherweise sehr lang sein kann. Anhand dieser Liste kann sich der Benutzer einen Überblick über die gefundenen Ergebnisdatensätze verschaffen. Durch Auswahl der für ihn relevanten Datensätze aus der Ergebnisliste kann deren ausführliche Darstellung ausgegeben werden. Bei der ausführlichen Darstellung werden sämtliche Attribute der angewählten UDK-Objekte bzw. Adressen ausgegeben. Eine erfolgreiche Suche im UDK führt zwangsläufig auf eine Adresse, bei der die Daten zu erhalten sind, für die sich der Benutzer interessiert. Erst nach Kontaktierung dieser Adresse ist es möglich, mehr Informationen über aufgefundene UDK-Objekte zu erhalten. Der UDK bietet Zugang zu Metainformationen über vorhandene Datenbestände, die im jeweiligen Bundesland gehalten werden (vgl. UDK98).
 

Abb. 8: Suchmaske nach Umweltdaten im UDK

5.2 Das Zentrale Umwelt- und Klimadaten-Metainformationssystem ZUDIS
Dieses Metainformationssystem mit WWW-Interface ist vom Forschungszentrum Karlsruhe entwickelt worden, mit dessen Hilfe die in Deutschland existierenden Informationsbestände an umweltrelevanten Daten beschrieben werden. ZUDIS soll alsdialogorientiertes Informationssystem gleichzeitig die Aufgabe eines Beratersystems erfüllen, denn

• ZUDIS soll die erforderliche Transparenz über vorhandene Datenbestände schaffen.
• ZUDIS dient politischen Entscheidungsträgern und Forschungsförderationen als Analyse- und Planungsinstrument.

• ZUDIS informiert als zentrales Verzeichnis für das Umweltdatenmanagement der "Herrmann von Helmholtz-Gemeinschaft Deutscher Forschungszentren (HGF)" über die dort vorhandenen umweltrelevanten Datenbestände und Zugangsmöglichkeiten.

Die Informationsbestände werden im ZUDIS in einem relationalen Datenbanksystem (Oracle) gehalten und organisiert (vgl. ZUDI98). Die Datensatzstruktur orientiert sich am Directory Interchange Format DIF (siehe Kapitel 3.1.1.1). Die Abfrage nach Datenbeständen kann über interaktive Spezifikation von Parametern, wie z.B. Datenanbieter, Raum, Zeit, erfolgen. Der Benutzer formuliert die Suchanfrage menügestützt im WWW (siehe Abb. 9). Von hier wird die Anfrage an das Datenbanksystem weitergegeben und ausgewertet. Beim Anzeigen des Suchergebnisses werden dem Benutzer weitere Optionen zur weiteren Bearbeitung, wie z.B. Ansicht der Datensatzbeschreibungen, angeboten. In Zukunft soll die Suche nach Informationen nicht mehr ausschließlich menügesteuert sein, sondern auch über eine Stichwortsuche möglich sein. Dies soll durch einen Thesaurus unterstützt werden, der die eingegebenen Suchbegriffe mit Hilfe eines semantischen Netzwerkes von Begriffen auf die Schlüsselworte der ZUDIS-Dokumente abbildet.
 

Abb. 9: Orts- und zeitbezogene Suche im ZUDIS
 
 

5.3 Bewertung UDK, ZUDIS gegenüber WATiS mit LOTSE
Ein echter Vergleich zwischen den beiden Nutzerführungen vom UDK und ZUDIS mit dem LOTSE V2 ist kaum möglich, zu unterschiedlich sind die Formen, in denen die Benutzungsschnittstellen der jeweiligen Systeme erscheinen. Es lassen sich unabhängig von der Art der Benutzungsschnittstelle, die beim UDK und ZUDIS graphischer Natur sind und dabei WWW-Techniken verwendet haben (gegenüber dem LOTSE V2, der ein reines Textinterface als Benutzungsschnittstelle zur Verfügung stellt) Aussagen über das Datenmaterial treffen, das von den jeweiligen Systemen zur Verfügung gestellt wird. Der UDK bietet Metainformation über gespeicherte UDK-Objekte. In fast allen Fällen der UDK-Recherche enthält die ausgegebene Metainformation eine Adresse, unter der weitergehende Informationen über das UDK-Objekt erhältlich ist. Die Metainformation wird in Tabellenform ausgegeben und wirkt so etwas nüchtern, da es keine Möglichkeit gibt, außer der Kontaktaufnahme mit der angegebenen Adresse weitere Informationen über UDK-Objekte zu erlangen.
 

Abb. 10: Präsentation eines UDK-Objekts

 

Das ZUDIS präsentiert sich als Sammelbecken von Metainformationssystemen und bietet eine Schnittstelle an, die es ermöglicht, ein Informationssystem, das Metainformation über Umweltdatenbestände bereithält, ausfindig zu machen. Im ZUDIS gibt es z.B. bei gewünschten Daten über das Wattenmeer einen Verweis auf das WATiS. Außerdem besteht beim ZUDIS die Möglichkeit, eigene Datenbestände dem System bekannt zu machen und so für einen großen Nutzungsradius zu sorgen. Das ZUDIS könnte man als ein System bezeichnen, das Metainformation über Metainformationssysteme zur Verfügung stellt.

Abb. 11: Ergebnis der ZUDIS Suchanfrage

 

 

Der LOTSE V2 bietet keine graphische Benutzungsschnittstelle. Mit hinreichend großem Aufwand lassen sich aber komplexe Suchanfragen an die WADABA gestalten. Der LOTSE V2 bietet zudem die Möglichkeit, direkt auf die entsprechenden Rohdaten zuzugreifen; eine spezielle Kennung ist hierbei erforderlich. Hierbei sind die Projektionen im 4-dimensionalen Suchraum zu erwähnen (vgl. WILL94). Eines der größten Mankos des LOTSE V2 im Vergleich zum UDK und ZUDIS ist die spartanisch ausgestattete Benutzungsschnittstelle. Mit Hilfe einer x3270-Terminalemulation ist es möglich, über das Internet den LOTSE V2 zu benutzen, aber eigenwillige Eingaben, die betriebssystembedingt sind, machen die Benutzung extrem kompliziert, während die WWW-Interfaces von UDK und ZUDIS wesentlich leichter zu bedienen sind.
McWATiS und LOTSE/p bieten zwar eine graphische Benutzungsschnittstelle, aber keine funktionalen Erweiterungen gegenüber dem LOTSE V2. Eine Bewertung mit anderen Systemen mit WWW-Anbindung ist insofern schwierig, da diese Systeme nur auf dem Apple Macintosh implementiert sind und nur lokal nutzbar sind.
 

6 Grundlagen von Graphischen Fenstersystemen
 

 Fenstersysteme haben innerhalb kurzer Zeit in die Systemsoftware von Rechnern aller Größenordnungen Einzug gehalten. Der Grund dafür ist, daß sie eine direktere Abbildung der Vorgänge in einem Rechner auf die menschliche Gedankenwelt ermöglichen als herkömmliche Dialogsysteme, die ausschließlich auf textueller Kommunikation oder der Anzeige von Werten beruhen. Die Unterstützung des Benutzers liegt zum einen in der visuellen Ausgabe der Ergebnisse, die der Rechner mitzuteilen hat und die bewußt in Analogie zu Objekten der realen Welt stehen. Zum anderen wird Hilfestellung geleistet durch Mechanismen, die der parallelen Arbeitsweise des Benutzers entgegenkommen. Mehrere Anwendungen sind auf dem Bildschirm gleichzeitig durch ein oder mehrere Fenster vertreten. Alle diese Anwendungen und sogar alle ihre Fenster können zu jedem Zeitpunkt durch Eingaben angesprochen oder aktiviert werden (vgl. KLIN96). Die Benutzerführung LOTSE/Web ist konzeptionsbedingt in ein Fenstersystem eingebettet. Diese Eigenschaft macht es nötig, die Grundlagen von Fenstersystemen zu betrachten, um bei der weiteren Konzeption und Realisierung der Benutzerführung diese auch miteinzubeziehen.
 

6.1 Eingabe
Ein Fenstersystem erfordert eine Texteingabe sowie ein graphisches Eingabegerät, welches zum Zeigen auf Dialogelemente benutzt wird. Für die Texteingabe unterscheidet man die Tastatur und die Schrift. Die graphischen Eingabegeräte, die für Fenstersysteme relevant sind, sind die Maus, der Lichtgriffel und das Tablett.
 

6.1.1 Graphische Zeigegeräte
Man unterscheidet zwischen graphischen Eingabegeräten, die direkt arbeiten und solchen, die indirekt funktionieren. Indirekte Zeigegeräte erlauben es, die Handgelenke oder Unterarme ruhen zu lassen und bewegen durch das Gerät einen Zeiger (engl. Cursor) auf dem Bildschirm. Bei direkten Eingabegeräten erfolgt die Positionierung auf dem Bildschirm selbst.
Die Maus und auch das Tablett sind typische Repräsentanten der indirekten Eingabe, wogegen der Lichtgriffel und die Berührschirme (engl. Touchscreens) für die direkte Eingabe stehen. Ein weiteres Unterscheidungsmerkmal ist die Frage, ob sich die Positionierung in absoluten oder relativen Koordinatensystemen vollzieht. Die Maus als Vertreter einer relativen Positionierung, kann angehoben werden, zurückgesetzt und dann erst weiterbewegt werden. Ein Lichtgriffel oder ein Tablett liefern dagegen Koordinaten in einem globalen Koordinatensysten, das durch die Bildschirmausdehnung respektive durch die Größe des Tabletts vorgegeben ist.
 

6.1.2 Tastatur
Die Tastaturen von Rechenanlagen sind im wesentlichen von den Tastaturen der Schreibmaschinen übernommen worden. Zu beachten ist die jeweils länderspezifische Tastenanordnung. Weiterhin wird auf eine Verbesserung der Ergonomie der Tastaturen gedrängt, die eine vorteilhaftere Bedienung ermöglichen soll.
 

6.1.3 Spracheingabe
Die Spracheingabe dient hauptsächlich als Ersatz für die Texteingabe per Tastatur, kann aber auch als Navigationseingabe fungieren und als solche (zumindest teilweise) das graphische Zeigegerät ersetzen. Diese Form der Eingabe ist aber noch sehr fehleranfällig, z.B. differiert die Sprechgeschwindigkeit und die Art der Aussprache von Mensch zu Mensch, was die fehlerfreie Erkennung der Spracheingabe beeinträchtigt.
 

6.1.4 Andere Eingabegeräte
Als weitere Eingabegeräte sind z.B. noch das Lippenlesen, Beobachtung der Augen, 3D-Eingabe ("Datenhandschuh"), Erkennung von Gesten zu nennen, die jedoch nur in Spezialfällen angewendet werden und sich zum Teil noch in der Forschungs- und Entwicklungsphase befinden.
 

6.2 Ausgabe
Für ein graphisches Fenstersystem sind Komponenten der Ausgabe: der Bildschirm selbst, der Bildspeicher und der Graphikprozessor, der den Bildspeicher beschreibt.
 

6.2.1 Graphikprozessor
Die Graphik, die für Fenstersysteme erforderlich ist, zeichnet sich zum einen dadurch aus, daß sie hochgradig dynamisch sein muß. Dies bedeuetet, daß ständig und in Echtzeit Änderungen auf Bildspeichern durchgeführt werden müssen. Zum anderen sind die elementaren Operationen relativ einfach. Um den Geschwindigkeitsanforderungen entsprechen zu können, besteht die Graphikhardware neben einem schnellen Speichermedium aus einem Graphikprozessor, der elementare Befehle vom Hauptprozessor übernimmt. Diese Befehle kann er selbständig und nebenläufig zum Hauptprozessor ausführen.
 

6.2.2 Bildspeicher
Der Bildspeicher enthält das gesamte Bild, das auf dem Bildschirm dargestellt werden soll. Daher kann der Graphikprozessor auf jeden Bildpunkt durch wahlfreien Zugriff, also in konstanter Zeit, zugreifen und diesen Bildpunkt manipulieren.
 

6.2.3 Bildschirme
Für Bildschirme sind folgende Parameter und Kriterien relevant: die Anzahl der Bildpunkte, die Größe des Bildschirms, die Größe einer Bildschirmfläche (in Verbindung mit einer sinnvollen Auflösung, die die Anzahl der Bildpunkte in einer Bildschirmausdehnung bezeichnet).
 

6.2.4 Sprachausgabe
Die Sprachausgabesysteme arbeiten, indem sie für jedes Phonem (aus der Sicht der Lautgebung die elementaren Objekte einer Sprache) eine Laut-Codierung speichern und diese bei der Ausgabe wiedergeben. Ein großes Problem hierbei ist die Qualität der Sprachausgabe, die je nach verwendetem System sehr stark differieren kann. Wie die Spracheingabe ist die Sprachausgabe in Dialog- und Fenstersystemen eher als eine Ergänzung zu sehen, da die Forschung und Entwicklung auf diesem Gebiet noch längst nicht abgeschlossen sind.
 

6.2.5 Ziele und Anforderungen für Fenstersysteme
Für ein universelles Fenstersystem kommen eine Reihe von Anforderungen in Betracht
(vgl. KLIN96, S.47ff.):

• Ein Fenstersystem sollte weder hardwareabhängig noch plattformabhängig sein.
   
• Die Geschwindigkeit der Ausgabe und die Reaktion auf Eingaben müssen bei häufigen Aufgaben, z.B. Edititeren eines Textes oder Verschieben eines Fensters, ohne spürbare Verzögerung vor sich gehen.
   

• Ein Fenstersystem sollte in der Lage sein, auf verschiedene Benutzervorlieben einzugehen.

• Parallelität aus Benutzersicht bedeutet, daß mehrere Anwendungsprogramme gleichzeitig Ausgaben auf den Bildschirm bringen und unabhängig voneinander auf Eingaben reagieren können.

• Eine Anwendung kann beliebig viele Fenster benutzen.

• Neben der alphanumerischen Eingabe muß mindestens ein Typus graphischer Eingabegeräte ansprechbar sein.

• Ein Fenstersystem sollte netzwerkfähig sein, um mit entfernten Applikationen kommunizieren zu können.

• Das Fenstersystem sollte multimediafähig sein, d.h. auch andere Medien als Text und Grafik verarbeiten können.
   
   

6.4. Kriterien für Fenstersysteme
Für die Beurteilung eines Fenstersystems sind Kriterien eine sinnvolle Hilfestellung. Einige Kriterien zu Fenstersystemen sind z.B. Verfügbarkeit, Produktivität, Parallelität, Leistung, Graphikgrundmodell, Stile, Erweiterbarkeit, Anpaßbarkeit, Teilbarkeit der Ressourcen, verteilte Fenstersysteme, Struktur und Komfort des API, Unabhängigkeit, Kommunikation zwischen Applikationen etc.
 

6.5 Komponenten eines Fenstersystems
Graphikfähige Bildschirme, Graphikprozessoren, Netzwerkkomponenten, graphisches Eingabegerät und eine Tastatur bilden abstrakt die Hardwarekomponenten eines Fenstersystems ab. Die Software, die ja das eigentliche Fenstersystem ausmacht, läßt sich wie folgt beschreiben (siehe Abb. 13):

• Die Anwender-Werkzeuge sorgen dafür, daß die gängigen Dialogbausteine nicht für jede Applikation neu implementiert werden müssen. Diese Schicht wird auch als Toolkit oder Construction Set bezeichnet.

• Das Window Management erledigt die Anzeige der verschiedenen Applikationen auf dem Bildschirm und liefert Dialogmöglichkeiten auf Sessionebene.

• Die Ressourcen-Verwaltung ist dafür verantwortlich, daß der konkurrierende Zugriff auf Ressourcen eine Synchronisation erfährt.

• Das Graphikbasissystem realisiert die Ausgabefunktion für Fenstersysteme. Um die hohe Geschwindigkeit für die Ausgabe zu gewährleisten, sind die elementaren Graphikfunktionen in effizienter Weise und hardwarenah realisiert.

            Abb. 12: Schichten-Modell der Fenstersystemkomponenten (verändert aus KLIN96, S.57)
 

6.6 Interaktionsformen
Der folgende Abschnitt stellt die wichtigsten Interaktionsformen zwischen Benutzer und Rechner vor. Es werden fenster-, kommando-, menü-, piktogramm-, masken- und multimedia-basierte Interaktionen sowie die direkte Manipulation betrachtet (vgl. HUEB90, S. 49ff. und STAR94, S. 83ff.).
 

6.6.1 Fensterbasierte Interaktion
Fenster sind im Rahmen von direkter Manipulation (s. 6.6.6) Objekte, die direkt vom Benutzer manipuliert werden können. Als direkte Manipulation werden dabei alle Funktionen betrachtet, die zu direkten Veränderungen des Fensters führen. Indirekte Manipulation kann z.B. mittels Menüs erfolgen. Es ist erst eine Selektion innerhalb eines Menüs nötig, um das Fenster tatsächlich manipulieren zu können. Als Hybride Manipulation wird die Kombination von direkter und indirekter Manipulation bezeichnet.
 

6.6.2 Kommandobasierte Interaktion
Kommandosprachen, wie z.B. von Betriebssystemen, sollen die Interaktion zwischen dem System und dem Benutzer erleichtern. Im allgemeinen gilt: Jedes Kommando sollte abkürzbar sein und mit Standardoptionen aufrufbar sein. Makros sollten vom Benutzer selbst erstellt werden können. Hilfefunktionen sollten für alle Kommandos verfügbar sein. Eine kommandobasierte Schnittstelle wird durch das Lesen eines Kommandos und seiner Parameter betrieben. Ausgehend von der Eingabe eines Kommandos wird eine bestimmte Prozedur mit den verfügbaren Paramtern ausgeführt. Danach wartet die Schnittstelle auf die Eingabe des nächsten Kommandos.
 

6.6.3 Menübasierte Interaktion
Ein Menü ist als eine Menge von Optionen definiert, die auf dem Bildschirm oder in einem Bildschirmausschnitt direkt angezeigt werden, wobei die Selektion und Ausführung einer oder mehrerer Optionen zu einer Veränderung an der Benutzungsschnittstelle führt. Für den Designprozeß eines Menüs sind zwei Aspekte wesentlich: die Beschreibung der Menüeinträge und die Anordnung bzw. Gruppierung der Menüoptionen innerhalb eines Bildschirmausschnitts. Die inhaltliche und organisatorische Ausrichtung von Menüeinträgen sollte dem Arbeitsablauf der Benutzer entsprechen.
 

6.6.4 Piktogrammbasierte Interaktion
Ein Piktogramm (icon) ist ein symbolisch verschlüsseltes graphisches Element. Sein Inhalt sollte einer Metapher entsprechen, die möglichst vielen Benutzern verständlich sein sollte. Piktogramme werden verwendet, um Benutzern bekannte Objekte zu verschlüsseln. Piktogrammbasierte Kommandosprachen basieren auf Symbolen, welche statische und dynamische Elmemente zur Aufgabenerfüllung verschlüsseln. Sie können editiert und zusammengesetzt werden.

Charakteristisch für piktogrammbasierte Systeme sind:

• Editierfunktionen, die die Generierung und Manipulation von Piktogrammen erlauben.
• Verarbeitungsfunktionen. Diese stellen die Verbindung von Anwendungsdaten und Funktionen zu den Piktogrammen her.

• Speicherung. Die Datenstrukturen zur Beschreibung von Piktogrammen werden meist in einer eigenen Datenbank gespeichert. Verweise zu anderen gespeicherten Daten, wie Prozeduraufrufen, Übersetzungsroutinen, die in direktem Zusammenhang mit der Bedienung der Piktogramme stehen, werden ebenfalls als Eigenschaften bzw. Beziehungen der Piktogramme abgespeichert.

6.6.5 Maskenbasierte Interaktion
Bei Anwendungen, welche die Verarbeitung unterschiedlicher Daten oder die Verarbeitung großer Mengen von Daten erfordern, kann die Erfassung dieser Daten durch direkte Eingabe oftmals erleichert werden. Diese direkte Erfassung kann mittels Bildschirmmasken oder Formularen durchgeführt werden. Eine Maske (form) läßt sich als einen segmentierten Bildschirmausschnitt, der die strukturierte Eingabe von Daten unterstützt, beschreiben. Masken bieten den Vorteil, Daten, deren Struktur bekannt ist, direkt und ohne Zwischenschritt eingeben zu können. Der Aufbau von Masken spiegelt oft Datenstrukturen wider und erlaubt zusätzlich zur Benennung der Datenfelder die Eingabe von Werten entsprechend den Datenfeldern. Masken erlauben eine Überprüfung der Plausibilität von Eingaben. Zur Vermeidung falscher Eingaben sollten einige Grundregeln beachtet werden:
 

• Verwendung von speziellen Datentypen: Kann direkt ein Datentyp für einen Eintrag verwendet werden, so sind Plausibilitätsüberprüfungen unmittelbar möglich. Werden sie durchgeführt, so kann die Eingabe erst dann akzeptiert werden, wenn sie korrekt eingegeben wurde.

• Visual Clustering: Besteht eine Dateneingabe aus mehr als acht Zeichen, so sollte sie logisch segmentiert werden.

• Berücksichtigung von Konventionen: Datumseinträge, Telefonnummern, Postleitzahlen und Trennzeichen bei großen Zahlen werden meist nach kulturellen Gewohnheiten vorgenommen. Wenn möglich, sollten unterschiedliche Konventionen unterstützt werden.

• Formatfreie Eingaben: Trotz aller Vorstrukturierung sollte es den Benutzern möglich sein, die Einträge an beliebigen Stellen innerhalb des vorgesehenen Feldes zu beginnen. Die Positionierung sollte automatisch vorgenommen werden.

6.6.6 Direkte Manipulation
Direkte Manipulation ist ein umfassendes Konzept, welches von graphischen Benutzungsschnittstellen unterstützt werden kann. In HUEB90 werden die drei Hauptprinzipien der Direkten Manipulation genannt:

• Bestimmte Objekte werden ständig auf dem Bildschirm verfügbar gehalten.
• Physikalische Gesten, z.B. Zeigen, Ziehen, Positionieren sowie die Auswahl und direkte Ausführung von Funktionen ersetzen eine komplexe Kommandosyntax.

• Schnelle, umkehrbare Operationen, deren Wirkung auf das betreffende Objekt unmittelbar sichtbar wird.

Bei geeigneter Definition der Objekte und bei geeigneter Zuordnung von Operationen lassen sich folgende Vorteile der direkten Manipulation erkennen: Die Grundfunktionalität ist schnell erlernbar. Auch gelegentliche Nutzer können operationale Konzepte erkennen und aktivieren, Fehlermeldungen werden selten benötigt. Der Nutzer erhält sofort eine Bestätigung über den Erfolg seiner Aktivität. Das System wird für den Nutzer transparenter, fehlerhafte Schritte können rückgängig gemacht werden, Reaktionen des Systems sind teilweise vorhersehbar.
Demgegenüber stehen auch einige Nachteile: Der Aufbau der Graphik ist zeitintensiv, Graphiken können mehrdeutig sein, der Nutzer muß die Bedeutung der graphischen Komponenten erlernen, der Wechsel der Handposition zwischen Maus und Tastatur behindert den Arbeitsvorgang. Auch der Vorteil der Anschaulichkeit ist bei unpassenden Metaphern und der damit verbundenen unpassenden Darstellung von Objekten nicht gegeben. Die Bedienung der Benutzungsschnittstelle wird kontraproduktiv, da das Verhalten des Systems nicht den Erwartungen des Benutzers entspricht. Charakteristisch für Schnittstellen mit direkter Manipulation sind:

• die semantische Nähe zum Aufgabenbereich des Benutzers bei geeigneter Auswahl der visualisierten Objekte,
• die direkte Ausführbarkeit von Operationen bei geeigneter Auswahl der den visualisierten Objekten zugeordneten Operationen,

• die unmittelbare Verschiebbarkeit von Datenobjekten und Kontrolleingaben auf dem Bildschirm.

Bei der Benutzung direkter Manipulationsschnittstellen können sich folgende Schwierigkeiten ergeben:

• Inkonsistenz von Operationen: Der Benutzer muß gemäß dem selektierten Objekt seine Erwartungshaltung bezüglich der Systemausgabe ständig anpassen.
• Implizites Auslösen von Operationen: Schon das Vermindern des Drucks auf eine Taste der Maus kann bei bestimmten Positionen oder Selektionen Operationen auslösen.
• Die Positionierung des Zeigegeräts entscheidet über die zur Verfügung stehenden Operationen. Fehlbedienungen können unabsichtlich ausgelöst werden.

• Die Hilfe für den Benutzer muß sich an den Datenobjekten und Kontrollobjekten orientieren, die durch die Cursorposition angesprochen werden. Der Aufwand zur Umsetzung dieser Erfordernis ist oftmals sehr hoch. Daher finden sich kaum aufgabengerechte Hilfefunktionen.

Im Vergleich zu menü- oder kommandosprachengesteuerten Systemen sind Operationen bei direkter Manipulation nur dann verfügbar, wenn das mittels der Operationen manipulierbare Objekt visuell verfügbar ist. Dieser Umstand ist nicht nur beim Entwurf von Schnittstellen mit direkter Manipulation zu beachten, sondern auch bei der Programmierung derselben. Operationen können als Ereignisse (events) betrachtet werden. Eigene Komponenten der Schnittstelle -Event Handler- bedienen den Benutzer, dessen Eingaben als Menge von Ereignissen interpretiert werden können. Die Dialogkontrolle besteht aus einer Endlosschleife, die Ereignisse entgegennimmt und an den ensprechenden Event Handler weiterreicht. Ereignisse können Zustandsveränderungen nach sich ziehen. Ereignisse sollten auch gespeichert werden können, damit alle Benutzereingaben und Systemausgaben registriert werden können.
 

6.6.7 Multimedia Interaktion
Multimedia Interaktion bestimmt eher als Schlagwort die Diskussion um die Kombination elementarer Interaktionsformen denn als technisches, organisatorisches oder software-ergonomisches Konzept. Da die Vorstellungen bezüglich einer Definition von Multimedia Systemen sehr unterschiedlich sind, existiert keine präzise und einheitliche Definition derartiger interaktiver Systeme. Um einen Konsens zu finden, lassen sich jedoch folgende minimale Eigenschaften von Multimedia Systemen erkennen:

• Unterschiedliche Interaktionsmedien werden integriert.
   

• Eines oder mehrere Interaktionsmedien sind dynamisch, d.h. zeitabhängig, z.B. Audio oder Animationen, wobei die menschliche Wahrnehmung an eine feste zeitliche Abfolge gebunden ist. Text, Graphik und z.B. Standbilder stellen im Gegensatz dazu zeitunabhängige Medien dar.

• Als Medien kommen Text, Graphik, Bilder, Audio, Video oder Sprache zum Einsatz, wobei die Beschränkungen der Informationsübermittlung von Text und Graphik durch Audio-, Video-, Simulations- und Animationskomponenten überwunden werden sollen.

• Bedingt durch die Integration wird die Flexibilität der Anzeige und Übermittlung von Informationen erhöht. Dabei stehen Möglichkeiten der individuellen Anpaßbarkeit sowie Erhöhung der Bandbreite an Informationsarten im Mittelpunkt der Gestaltung derartiger Systeme.

• Die Wahl der Informationsdarstellung liegt beim Benutzer.

Die Effizienz der Interaktion soll durch die mehrfache und anschauliche Darstellung von komplexen Inhalten gesteigert werden. Die Handlungsmöglichkeiten für Benutzer sind neben der individuellen Steuerbarkeit der Interaktion das Festlegen des Zeitpunkts der Informationsdarstellung und -übermittlung sowie die Auswahl und Kombination von Informationselementen. Multimedia könnte als die rechnerbasierte Kombination mehrerer zeitabhängiger und zeitunabhängiger Medien, die individuell und selektiv bearbeitet werden können, bezeichnet werden.

 

zeitunabhängiges Medium	Elemente	Größe
Text	druckbare Zeichen	10 KB (fünf Seiten)
Graphik	Vektoren	100 KB
Rasterbild	Bildpunkte	1 MB

Tab. 2: Informationsarten bei multimedialer Interaktion und zeitunabhängigen Medien

 

zeitabhängiges Medium	Elemente	Größe
Tonaufnahme	Lautstärkepegel	650 MB (Audio-CD)
Bewegtbild	Rasterbild oder Graphik	>1 GB

Tab. 3.: Informationsarten bei multimedialer Interaktion und zeitabhängigen Medien

 
Die Realisierung von Multimedia Systemen stößt zur Zeit auf folgende grundlegende Probleme:

• Schwierigkeiten bei der notwendigen technischen Integration bisher in sich geschlossener und daher auch teilweise inkompatibler Systeme aus Film-, Rechner- und Nachrichtentechnik.

• Das Fehlen von Konzepten und Verfahren zur Gestaltung und Entwicklung von Multimedia Systemen.

  7 Konzeption der Benutzerführung LOTSE/Web

Dieses Kapitel beschreibt den von mir gewählten Ansatz zur Realisierung der neuen Benutzerführung LOTSE/Web. Das "Web" im Namen des Systems steht dabei für World Wide Web und soll verdeutlichen, daß es sich um eine WWW-basierte Anwendung handelt.
 

7.1 Entwurfsmethodik
 Bei der Wahl der Entwurfsmethodik für die Benutzerführung LOTSE/Web kommen zwei Möglichkeiten in Betracht. Zum einen kann der traditionelle Ansatz des Softwareentwurfs ausgehend von einer Top-Down-Vorgehensweise verfolgt werden, in dem das Software-Produkt in aufeinander aufbauenden Entwurfsphasen entwickelt und schrittweise verfeinert wird. Demgegenüber werden im iterativen Entwurfsansatz Prototypen entwickelt, die schrittweise verbessert werden. Der erste Prototyp wird bereits in einer frühen Entwurfsphase entwickelt und evaluiert, damit weitere Erkenntnisse über die Akzeptalität gewonnen werden können. Die Abbildung 13 stellt beide Ansätze gegenüber. Man unterscheidet horizontale und vertikale Prototypen (vgl. OBER92):

• Ein horizontaler Prototyp stellt die Benutzungsschnittstelle einer Anwendung dar. Er enthält alle Funktionen hinsichtlich der Darstellung auf der Oberfläche in Form von stark verkürzten Implementierungen. Beispielsweise können alle Tasten abgebildet werden, die bei Betätigung zu einem Wechsel in einen anderen Dialog führen oder eine entsprechende Meldung ausgeben.

• Ein vertikaler Prototyp ist hinsichtlich einiger ausgewählter Funktionen vollständig implementiert.

        Abb. 13: Top-Down-Ansatz vs. Prototypenentwicklung (vgl. HUEB90, S.21)

 
Der iterative Entwurf erweist sich vor allem dann als besonders geeignet, wenn die Anforderungen nicht vollständig bekannt sind oder wenn Erfahrungen im Umgang mit dem zu entwickelnden System notwendig sind. In Benutzungsschnittstellen tritt der Mensch als eine Komponente des Softwaresystems auf. Verhalten und Eigenschaften der individuellen Benutzer unterscheiden sich und sind nicht vollständig vorhersehbar. Unter Abschätzung der Eigenschaften, Fähigkeiten und Aufgaben des Benutzers wird ein Benutzer- und Aufgabenmodell entwickelt und die Benutzungsschnittstelle darauf abgestimmt. Eine wichtige Beobachtung ist hierbei, daß der Entwickler einer Benutzungsschnittstelle häufig nicht in der Lage ist, die Eigenschaften der potentiellen Benutzer vollständig einzuschätzen. Anstelle einer detaillierten Spezifikation der Benutzerinteraktion wird daher versucht, die Benutzungsschnittstelle in einem iterativen Prozeß an die Benutzereigenschaften anzupassen und während dieses Prozesses nähere Aufschlüsse über die Benutzereigenschaften zu erlangen. Durch Partizipation der Benutzer während des Entwicklungsprozesses ist eine Verbesserung der Benutzbarkeit zu erreichen. Die Spezifikation kann sich in diesem Fall darauf beschränken, die Bedingung für eine Akzeptanz eines Entwurfes festzulegen. Durch den iterativen Entwurf ist eine praktische Evaluierung des Systems frühzeitig möglich, so daß die Wahrscheinlichkeit, daß das System die Erwartung und Anforderungen erfüllt, erhöht wird (vgl. RAAS93).

 
7.2 Software-ergonomische Anforderungen
In DIN 66234 Teil 8 sind Grundsätze ergonomischer Dialoggestaltung enthalten. In dieser Norm sind fünf Grundsätze genannt (vgl. DIN88):

• Aufgabenangemessenheit
• Selbstbeschreibungsfähigkeit
• Steuerbarkeit
• Erwartungskonformität

• Fehlerrobustheit

Diese fünf Grundsätze werden in der DIN 66234 Teil 8 wie folgt definiert:

• Ein Dialog ist aufgabenangemessen, wenn er die Erledigung der Arbeitsaufgabe des Benutzers unterstützt, ohne ihn durch Eigenschaften des Dialogsystems unnötig zu belasten.

• Ein Dialog ist selbstbeschreibungsfähig, wenn dem Benutzer auf Verlangen Einsatzzweck sowie Leistungsumfang des Dialogsystems erläutert werden können und wenn jeder einzelne Dialogschritt unmittelbar verständlich ist oder der Benutzer auf Verlangen dem jeweiligen Dialogschritt entsprechenden Erläuterungen erhalten kann.

• Ein Dialog ist steuerbar, wenn der Benutzer die Geschwindigkeit des Ablaufs sowie die Auswahl und Reihenfolge von Arbeitsmitteln oder Art und Umfang von Ein- und Ausgaben beeinflussen kann.

• Ein Dialog ist erwartungskonform, wenn er den Erwartungen der Benutzer entspricht, die sie aus Erfahrungen mit bisherigen Arbeitsabläufen oder aus einer Benutzerschulung mitbringen sowie den Erfahrungen, die sie sich während der Benutzung des Dialogsystems und im Umgang mit dem Benutzerhandbuch bilden.

• Ein Dialog ist fehlerrobust, wenn trotz erkennbar fehlerhafter Eingaben das beabsichtigte Arbeitsergebnis mit minimalem oder ohne Korrekturaufwand erreicht wird. Dazu müssen dem Benutzer die Fehler zum Zwecke der Behebung verständlich gemacht werden.

Diese Normung gibt eine recht anschauliche Darstellung für ein Anforderungspaket an eine Benutzerführung wieder, die auch Anforderung für die Konzeption des LOTSE/Web ist.
 

7.3 Funktionale Anforderungen
Die Funktionalität des LOTSE/Web orientiert sich an den bisher entwickelten Benutzerführungen. Eine Erweiterung gegenüber älteren Versionen ist die Möglichkeit der Volltextrecherche über die vorhandenen Metadaten. Diese Volltextrecherche wird über eine Suchmaschine realisiert, die diese Funktionalität zur Verfügung stellt. Während die Metadaten der Projekte im WATiS frei verfügbar sind, so sind die Rohdaten der Projekte nur für eingetragene Benutzer des WATiS bestimmt. Hierbei ist ein Mechanismus zu konzipieren, der die sichere Übertragung von Daten eingetragener WATiS-Benutzer gewährleistet. Die Integration von anderen Datenbeständen als die aus der WADABA wird prinzipiell unterstützt.
 

7.4 Portabilitätsanforderungen
Eine der Hauptanforderungen bei der Konzeption der Benutzerführung LOTSE/Web ist die der Portabilität. Dies bedeutet, daß der Einsatz dieser Benutzerführung auf möglichst vielen Plattformen möglich ist, und zwar ohne irgendeinen Portierungsaufwand. Die Benutzerführung LOTSE/Web ist prinzipiell auf keine spezielle Rechnerplattform angewiesen. Es müssen einige Prämissen erfüllt sein, damit der LOTSE/Web auf einer Plattform einsetzbar ist, doch diese Prämissen sind unabhängig von der Konzeption der Benutzerführung. Um diesen Grad an Portabilität zu erreichen, müssen die Clients über eine Netzverbindung zu dem Server verfügen, der die Benutzerführung LOTSE/Web zur Verfügung stellt. Zum anderen ist auf der Client-Seite ein WWW-Browser erforderlich, in dem die Benutzerführung LOTSE/Web ablaufen kann. Der WWW-Browser ist also eine unverzichtbare Komponente des LOTSE/Web, ohne die keine Kommunikation ablaufen kann.
 

7.5 Erweiterbarkeit
Der Funktionsumfang des LOTSE/Web soll problemlos erweiterbar sein. Neue Funktionen können bei Bedarf als CGI-Skripte oder als Java-Programme in die bestehende Nutzerführung integriert werden, ohne daß die bisherige Funktionalität darunter leidet. Wenn in Zukunft Daten in multimedialer Form, wie z.B. Audio oder Video, vorliegen, so können diese in das bestehende System integriert werden. Fast alle WWW-Browser unterstützen diese Formate.
Die Nutzerführung LOTSE/Web sollte nicht nur auf Datenbestände beschränkt sein, die in der zentralen Datenbank WADABA innerhalb der GKSS gehalten werden. Auch andere Datenbanken können bei Bedarf integriert werden. Konzepte für Datenbankzugriffe werden in Abschnitt 7.10 vorgestellt.
 

7.6 Architektur auf WWW-Basis
Die prinzipielle Systemarchitektur des LOTSE/Web wird in der folgenden Abbildung verdeutlicht:

Abb. 14: prinzipielle Systemarchitektur des LOTSE/Web Systems
 

Der WWW-Browser kommuniziert mit einem WWW-Server, der die Funktionalität der Benutzerführung bereitstellt. Der WWW-Server ist dann auch für die Kommunikation mit Systemen, die Daten bereitstellen, die über den LOTSE/Web erlangt werden können, verantwortlich. Die Kommunikation zwischen dem WWW-Browser und dem WWW-Server wird über das Internet realisiert. Der WWW-Server kann jetzt Funktionalität zur Verfügung stellen, die der Benutzer, also der WWW-Browser als Hilfsmittel des Benutzers, verwenden kann. Dieses geschieht nun völlig plattformunabhängig. Eine weitere unverzichtbare Systemkomponente ist also der WWW-Server, denn nur so kann die Funktionalität der Benutzerführung beim Client genutzt werden. Zusätzlich wird ein weiterer WWW-Server benötigt, der das SSL-Protokoll (siehe 4.5) unterstützt. Dieser WWW-Server ist ausschließlich für die sichere Übertragung von sicherheitsrelevanten Daten, wie z.B. Paßwörtern, zuständig.
 

7.7 Navigation
Die Navigation durch die Daten des WATiS wird mit folgenden Komponenten ermöglicht:

• Auf Grundlage des Menübaums (siehe 3.3.6) werden Hypertextstrukturen erstellt, die ein Navigieren innerhalb des Menübaums möglich machen.

• Eine Projektindexliste ermöglicht die direkte Anwahl zu Metainformation über WATiS-Projekte.

• Eine Suchmaschine, die die Metainformation über WATiS-Projekte indiziert hat, ermöglicht eine Volltextrecherche über die Metainformation von WATiS-Projekten.

• Ein ortsbezogener Zugriff über Bilder topographischer Karten auf Datenbestände von Projekten wird mittels Bitmap-Graphiken zur Verfügung gestellt.

Der Menübaum wird als ein HTML-Dokument derart aufbereitet, so daß mittels Hyperlinks ein Durchlaufen des Menübaumes von jedem Knoten zu seinen Nachfolger- bzw. zu seinem Vorgängerknoten möglich gemacht wird, mit Ausnahme des Einstiegs, der keinen Vorgängerknoten besitzt und den Blättern des Menübaums, die die Projekte des WATiS repräsentieren.
Die Projektindexliste ermöglicht den direkten Zugang zu Metainformation und Daten eines WATiS Projekts und wird als statisches HTML-Dokument dargestellt (siehe Abbildung A.4). Als Suchmaschine wird das frei verfügbare Produkt HARVEST eingesetzt (siehe 8.2.2). Sie ermöglicht die Volltextrechtrecherche über die vorhandene Metainformation. Als Ergebnis liefert die Suchmaschine eine Liste von HTML-Dokumenten zurück, auf denen das gewünschte Suchmuster gefunden wurde (siehe Abbildung A.6). Ein ortsbezogener Zugriff über Bilder topographischer Karten auf Datenbestände von Projekten wird mittels Bitmap-Graphiken zur Verfügung gestellt. Diese Funktionalität wird mit Hilfe eines Java-Applets bereitgestellt. Der Benutzer kann auf einer Karte eine Box aufziehen und bekommt als Rückmeldung eine Liste von Projekten, die in diesem Gebiet Daten erhoben haben. Zusätzlich kann ein Zeitraum eingegeben werden, der dann mit dem aufgezogenen Suchrechteck eine orts- und zeitabhängige Suche realisiert. Der Benutzer hat auch die Möglichkeit der Wahl von verschiedenen Karten.
 

7.8 Oberflächengestaltung der Benutzungsschnittstelle
Die Oberflächengestaltung richtet sich daran aus, welche Möglichkeiten ein WWW-Browser für das Oberflächendesign zur Verfügung stellt. Ein WWW-Browser stellt grundsätzlich eine Funktionalität zur Verfügung: die graphische Repräsentation von HTML-Dokumenten. Eine weitere Möglichkeit zur Oberflächengestaltung ist die Verwendung der Programmiersprache Java. Mit Java können sogenannte Applets programmiert werden, die über einen WWW-Browser gestartet werden können. Applets sind Programme, die über das Internet geladen werden können und eine komplexere Interaktion mit dem Benutzer ermöglichen. Die Verwendung von HTML läßt eine komplexe Interaktion mit dem Benutzer nur bedingt zu. Dieses ist auf die Verwendung des http-Protokolls zurückzuführen, das Interaktionen zwischen WWW-Browser und WWW-Server nur mittels neuerlichem Verbindungsaufbau von WWW-Browser zum WWW-Server bewerkstelligen kann. Innerhalb von einem WWW-Browser gibt es also zwei Möglichkeiten zur Oberflächengestaltung: Zum einen ist dies die Verwendung von HTML, zum anderen bietet die Programmiersprache Java innerhalb ihres Abstracting Windows Toolkit (AWT) Möglichkeiten zum Design einer Benutzungs-oberfläche. HTML bietet folgende Komponenten für eine Interaktion mit dem Benutzer: Hyperlinks, Ankreuz-, Auswahl- und Schaltflächen und Texteingabezeilen. Mit Ausnahme von Hyperlinks lassen sich diese Komponenten in Formulare integrieren, um deren Funktionalität voll auszuschöpfen. Der Einsatz dieser Komponenten sollte also immer in Formularen erfolgen.
 

Hyperlinks
Hyperlinks stellen (siehe 4.2.7.1) die sogenannte Hypertextfunktionalität zur Verfügung. Durch entsprechende Referenzen ist es möglich, auf andere Stellen im aktuellen Textdokument zu verweisen oder auch eine beliebige WWW-Adresse aufzurufen.
 

Formulare (Forms)
Bei Formularen handelt es sich um eine Ansammlung von Interaktionskomponenten, deren Inhalt in einem Paket an den WWW-Server geschickt wird. Diese Information kann dann vom WWW-Server ausgewertet und weiterverarbeitet werden (siehe 7.11.1).

Die wichtigsten Interaktionskomponenten innerhalb eines Formulars sind:

Checkboxen
Dieser Typ ist ein Ankreuzfeld. Es können beliebig viele Ankreuzfelder in einem Formular angewählt werden.
 

Radio-Buttons
Radio-Buttons sind Auswahlfelder, die sich ähnlich wie Checkboxen verhalten. Der Unterschied besteht darin, daß aus einer Gruppe von Auswahlfeldern nur eines ausgewählt werden kann. Wählt der Benutzer ein anderes Feld an, wird das vorherige jeweils deaktiviert.
 

Schaltfläche (Submit-Button)
Der Submit-Button ist eine Schaltfläche, die sofort alle ausgefüllten Formulardaten an den Server schickt. Um ein Formular an einen WWW-Server zu schicken, ist diese Komponente unerläßlich. Zusätzlich gibt es die Möglichkeit, benutzerdefinierte Schaltflächen zu erstellen.
 

Texteingabefelder (Textareas)
Textareas sind Texteingabefelder, die Tastatureingaben erlauben.
 

Pull-down-Menüs und Auswahllisten (Scroll-List)
Mit Hilfe des <select>-Tags können Pull-down-Menüs oder Auswahllisten in ein Formular integriert werden.
 

In der folgenden Abbildung werden einige der eben beschriebenen Oberflächenkomponenten dargestellt.
 

                                                    Abb. 15: Oberflächenkomponenten
 

Das Java Abstract Windowing Toolkit (AWT) stellt die eben genannten Komponenten ebenfalls bereit, jedoch läßt sich innerhalb von Java eine ganz andere Funktionalität erreichen. In HTML ist eine Formular-Interaktion unerläßlich, um überhaupt eine Interaktion mit dem Benutzer zu realisieren. In Java können diese Komponenten jedoch innerhalb eines Programms verwendet werden, was den Interaktivitätsgrad der Komponenten drastisch erhöht (siehe 8.3.1).
 

7.9 Datenrepräsentation
Die Repräsentation der Daten aus dem WATiS gliedert sich in zwei Teilbereiche. Der eine Teil umfaßt die Repräsentation der Metadaten, der andere die Repräsentation der eigentlichen Projektdaten. Diese Teilung ist notwendig, da die Vorgabe zu erfüllen ist, daß nur die Metadaten des WATiS öffentlich gemacht werden sollen und die Projektdaten nur einem eingeschränkten Nutzerkreis zugänglich gemacht werden sollen. Dieses ist nötig, da die Projektdaten einem Copyright unterliegen. Berechtigte Benutzer haben jedoch die Sicht auf alle verfügbaren Projektdaten.
Die Metadaten der Projektdaten werden auf zwei Arten präsentiert. Zum einen werden die Metadaten der WATiS-Projekte als statische HTML-Dokumente aufbereitet. Für jedes Projekt im WATiS wird ein statisches HTML-Dokument erstellt und auf einem festen Platz im WWW-Server gespeichert. Die statische Speicherung der Metainformation für ein Projekt ist vorteilhaft für die Schnelligkeit der Repräsentation, da hier keine anderen Aktionen als das Aufrufen des Dokuments vom WWW-Server zum Darstellen der Metainformation nötig ist. Zum anderen ist es für die eingesetzte Suchmaschine unerläßlich, daß Metainformation über WATiS-Projekte statisch vorliegt. Denn sonst wäre die Indizierung der Metainformation praktisch unmöglich und eine Volltextrechereche über die Metainformation nicht realisierbar. Theoretisch könnte die Suchmaschine auch dynamische HTML-Dokumente indizieren, die dafür benötigten Parameter, kann sie jedoch nicht vorhersehen. Der Nachteil statischer Repräsentation der Metadaten von WATiS-Projekten ist die Gefahr von unzureichender Aktualität der statischen HTML-Dokumente. Dies kann aber durch die Installierung eines Aktualierungsprozesses auf dem WWW-Server verhindert werden, der die statischen HTML-Dokumente in einem festen Zeitintervall immer wieder neu erzeugt. Die Darstellung der Metainformation eines WATiS-Projekts kann jedoch auch dynamisch erfolgen. In jedem statischen HTML-Dokument existiert ein Hyperlink, der über die CGI-Schnittstelle (siehe 7.11.1) ein Skript referenziert, das dynamisch die Metainformation aus der WADABA generiert. Die Repräsentation der Metainformation über WATiS-Projekte gliedert sich wie folgt (siehe Abbildung A.10):

• Projektakronym
• Titel des Projektes
• Zeitangaben über das Projekt:
  • Datum des Projektbeginns
  • Datum des Projektendes
  • Datum der ersten Dateneingabe

  • Datum der letzten Dateneingabe

• Koordinaten der definierten Projektfläche
• Koordinaten der Fläche, in der Daten erhoben worden sind
• Adressen der beteiligten Personen
• Datum des letzten Updates der Metainformation für das jeweilige Projekt

• Angabe der Datenquellen

Die Umrandung der definierten Projektfläche sowie der Fläche, in der Daten erhoben worden sind, können über einen Hyperlink graphisch als sogenannte Bounding-Box auf einer geographischen Karte dargestellt werden. Diese Darstellung wird mit einem Java-Applet realisiert. Die Angabe der Datenquellen kann URL´s enthalten, falls auf anderen Rechnern weitere Information über dieses Projekt verfügbar ist. Sind zu dem jeweiligen Projekt Daten in der WADABA verfügbar, so kann der Benutzer sich zu der Auswahl von Projektdaten weiterleiten lassen.
Die Repräsentation der Projektdaten erfolgt erst nach einer Paßwortabfrage. Die Projektdaten-Repräsentation erfolgt im Gegensatz zur Metainformationsdarstellung vollkommen dynamisch. Der Grund hierfür ist in dem Umfang der Daten zu sehen. Es ist nicht sinnvoll, große Datenbestände statisch vorzuhalten, weil sonst eventuell Inkonsistenzen zwischen statisch auf HTML-Dokumenten gespeicherten Projektdaten und den Projektdaten in der WADABA auftreten können.
Die Projektdaten des jeweiligen WATiS-Projektes, die als Tabellen in der WADABA vorliegen, werden auf einem dynamisch erzeugten HTML-Dokument dargestellt. Hier kann nun eine Auswahl vorgenommen werden, welche Projekttabelle gewünscht wird. Die jeweilige Projekttabelle wird dem Benutzer in Auszügen präsentiert. Dieses ist zwingend notwendig, da die Größe der Projekttabellen zwischen einem Kilobyte und mehreren Megabytes differieren kann. Sollte eine Tabelle im WWW-Browser dargestellt werden, die einige Megabytes groß ist, so kann es zu erheblichen Wartezeiten kommen, die dem Benutzer nicht zugemutet werden können. Ist die jeweilige Projekttabelle für den Benutzer von Interesse, so ist die Möglichkeit gegeben, die Tabelle auf dem lokalen Rechner des Benutzers abzuspeichern.
 

7.10 Middleware
Traditionelle Client/Server-Systeme basieren auf einer Zwei-Ebenen-Architektur. Diese Architektur wird auch als Two Tier Architecture bezeichnet. Hierbei befindet sich der Client auf einer Ebene und der Server auf einer zweiten. Diese Architektur kann um eine Ebene, zur sogenannten Drei-Ebenen-Architektur (Three Tier Architecture), erweitert werden. Die neu hinzugefügte Ebene wird als Middleware bezeichnet. Besondere Aufgabe von Middleware ist die Schaffung einer transparenten Umgebung, d.h. Lösen der Heteroginität von Betriebssystemen und der Probleme verteilter Systeme. Als Beispiel für den Einsatz von Middleware kann folgendes System dienen: ein Client kommuniziert über Middleware mit einem Datenbankserver (siehe Abb. 16)

                            Abb. 16: Middleware
 

Die Middleware ist in diesem Beispiel für die Kommunikation mit dem Datenbankserver verantwortlich. Vorteile von einer Drei-Ebenen-Architektur sind:

• Entlastung der Clients und damit die Möglichkeit der Realisierung von "thin clients"

• Entlastung des globalen Netzverkehrs aufgrund eines geringeren Datentransferbedarfs

• Bessere Skalierbarkeit

• Zusätzliche Möglichkeiten der Integration von Sicherheitsmechanismen

Die Nachteile einer Drei-Ebenen-Architektur sind:

• Zusätzliche Serverlast, zusätzlicher Hardwarebedarf

• Erhöhter Entwicklungs-, Management- und Administrationsaufwand

• Mögliche Erhöhung des lokalen Netzverkehrs

Die als Middleware realisierten Dienste stehen somit netzwerkweit zur Verfügung. Durch die steigende Anzahl der im Netz zur Verfügung stehenden Dienste ist eine geeignete Auswahl für die geforderten Aufgaben kompliziert und unübersichtlich geworden. Dieses Problem zu lösen, ist die Aufgabe des sogenannten Tradings. Die Aufgabe des Tradings ist es, eine geeignete Dienstauswahl in einem verteilten System zur Verfügung zu stellen (vgl. KOOR97).
Die im nächsten Abschnitt vorgestellten Architekturen für einen Datenzugriff stellen, bis auf eine Ausnahme, Drei-Ebenen-Architekturen dar. Lediglich der Zugriff über JDBC (siehe 7.11.2) basiert auf einer Zwei-Ebenen-Architektur.
 

7.11 Datenzugriffskonzepte für den LOTSE/Web
Eine wesentliche Fragestellung bei der Konzeption eines Informationssystems ist, wie der Datenzugriff realisiert werden kann. Bei der Konzeption des LOTSE/Web beschränkt sich diese Fragestellung auf den Komplex, wie über das Internet auf Datenbestände zugegriffen werden kann. Für dieses Einsatzspektrum bieten sich diese Architekturen an:

• das Common Gateway Interface (CGI)
• die Java Database Connectivity (JDBC)
• die Remote Method Invocation (RMI)

• die Common Object Request Broker Architecture (CORBA)

Im folgendem Abschnitt werden diese Architekturen im Hinblick auf den Datenzugriff des LOTSE/Web eingehender untersucht.
 

7.11.1 Common Gateway Interface (CGI)
Um über einen WWW-Server auf Datenbestände zuzugreifen, die nicht in das erwartete WWW-Schema passen, in diesem Fall Datenbanken, ist es nötig, ein sogenanntes Gateway bereitzustellen, um diese Bestände zu erreichen und somit nutzbar zu machen. Der Mechanismus zur Kommunikation zwischen diesem Gateway und dem WWW-Server wird als Common Gateway Interface (CGI) bezeichnet.
Die CGI-Schnittstelle ist eine Methode, die direkt vom WWW-Server bereitgestellt wird.
Abbildung 17 zeigt den prinzipiellen Informationsfluß zwischen CGI, WWW-Server und WWW-Client.

 
                                            Abb. 17: Informationsfluß durch das CGI
 

Die CGI-Schnittstelle ermöglicht die Ausführung von Skripten oder Programmen auf dem WWW-Server. Diese Skripte oder Programme können eine Verbindung zu einer Datenquelle aufnehmen, Informationen entnehmen und diese im HTML-Format an den WWW-Server zurückgeben, der dann wiederum diese HTML-Ausgabe an den WWW-Client weiterreicht. Es ist nicht zwingend, daß das Skript oder Programm HTML-Code zurückliefert, wenn aber kein HTML-Code zurückgeliefert wird, dann bekommt der WWW-Client auch keine vollständig interpretierbare Ausgabe zurück.

Der Datenbankzugriff über die CGI-Schnittstelle kann folgendermaßen geschehen: Der WWW-Client startet ein Skript über die CGI-Schnittstelle, welches dann die Verbindung zum Datenbankserver herstellt. Die Verbindung zur Datenbank wird über ein C-Programm realisiert, das vom CGI-Skript per Remote Shell Kommando aufgerufen wird. Dieses C-Programm stellt auf Betriebssystemebene die Verbindung zum Datenbankserver her und liefert die gewünschten Daten zum CGI-Skript zurück, welches wiederum eine HTML-Ausgabe erzeugt und diese über den WWW-Server zum WWW-Client zurückschickt. Folgende Abbildung verdeutlicht diesen Architekturvorschlag:

 
            Abb. 18: Architektur für Datenzugriff über CGI

Vorteile des Common Gateway Interface:
Ein großer Vorteil des Common Gateway Interface ist die relativ problemlose Handhabung. Die CGI-Skripte oder Programme können in jeder beliebigen Spache verfaßt werden, die auf dem jeweiligen System lauffähig ist. Zudem lassen sich einfache Anwendungen sehr schnell mit Hilfe der CGI-Schnittstelle implementieren.
 

Nachteile des Common Gateway Interface:
Die fehlende Komplexität der Interaktivität ist einer der größten Nachteile der CGI-Schnittstelle. Das aufgerufene CGI-Skript oder Programm kann nach dessen Aufruf nicht mehr mit dem WWW-Client interagieren. Die einzige Interaktion ist, die vorgesehene Ausgabe an den WWW-Client zurückzuschicken. Einen Mechanismus zu entwickeln, der diese Quasi-Zustandslosigkeit behebt, ist nur durch einen immensen Aufwand zu realisieren und daher nicht akzeptabel. Weiterhin belasten CGI-Skripte oder Programme den Server in nicht zu vernachlässigender Weise. Die Skripte oder Programme können zwar in beliebigen Sprachen erstellt werden, sie müssen aber auf dem jeweiligen Rechner lauffähig sein. Portabilität ist daher nicht unbedingt gewährleistet.
Eine standardisierte oder zumindest quasi-standardisierte CGI-Schnittstelle zu Datenbanken exisitiert nicht. Der Datenbankzugriff muß explizit programmiert werden, wie es im Prototyp realisiert wird, indem ein CGI-Skript ein Remote Shell Kommando absetzt, um dann über ein externes C-Programm die Verbindung zu einem Datenbankserver herzustellen.
 

7.11.2 Java Database Connectivity (JDBC)
Die Java Database Connectivity (JDBC) ist eine API, die entwickelt wurde, um den Bedarf nach einer standardisierten Java-Anwendungsschnittstelle zu relationalen Datenbank-Managementsystemen zu befriedigen. JDBC ermöglicht den Zugriff auf Datenbanken innerhalb von Java-Anwendungen. Diese Zugriffsmöglichkeiten sind sowohl von der Rechnerplattform, auf der die Anwendung läuft, als auch vom zugrunde liegenden Datenbanksystem unabhängig. Die JDBC-Spezifikation ermöglicht das Erstellen von Java-Code zum Herstellen einer Datenbankverbindung, zum Verschicken von SQL-Statements an die Datenbank und zum Retrieval von Anfrageergebnissen. Weiter beinhaltet JDBC Möglichkeiten zur Konversion von SQL-Datentypen zu Java-Datentypen und umgekehrt (vgl DICK97).
 

                        Abb. 19: Ablaufszenario der JDBC-API
 

Die Behauptung der Plattform- und Datenbankunabhängigkeit der JDBC bedarf leider einiger Einschränkungen. Der Zugriff von Java-Programmen auf Datenbanken geschieht über JDBC-Treiber. Diese Treiber sind aber von Datenbank zu Datenbank verschieden. Diese Komponente der Datenbankabhängigkeit bezieht sich aber nicht auf die eigentliche Anwendung, denn man kann dem WWW-Client entweder die Möglichkeit geben, diese benötigten Treiber aus dem Internet zu laden, sofern sie dann in Java implementiert sind, oder man kann sie auf einem zusätzlichen Server kapseln.
Als nachteilig zu bemerken ist, daß die JDBC-API die SQL-Statements ungeprüft zur Datenbank weiterleitet. Die Fehlermeldungen kommen dann vom DBMS, falls denn ein Fehler vorliegt, und werden an die Anwendung zurückgegeben. Fehler werden so oftmals erst zur Laufzeit entdeckt. JDBC kann momentan nur auf relationale DBMS zugreifen, Zugriffsmöglichkeiten auf objektorientierte DBMS sind zur Zeit noch nicht vorgesehen. Dieser Nachteil relativiert sich insofern, daß im praktischen Einsatz so gut wie kaum objektorientierte DBMS verwendet werden. Im normalen Einsatz von JDBC werden Paßwörter, die zur Verbindung mit der Datenbank nötig sind, unverschlüsselt über das Netz zum Datenbankserver übertragen. Eine sichere Übertragung der Paßwörter kann nur durch eine eigene Implementierung erfolgen. Der gesamte Zugangsmechanismus wird auf den WWW-Client abgebildet, der dann möglicherweise zum "Fat-Client" wird, d.h. als eigentlicher Client muß er Aufgaben wahrnehmen, die eigentlich von einem Server-Rechner erfüllt werden sollten (vgl. DICK97). Der Einsatz von JDBC im LOTSE/Web wird in der folgenden Abbildung veranschaulicht: 

 
                            Abb. 20: LOTSE/Web-Architektur mit JDBC-Konzept
 

Der WWW-Client lädt vom WWW-Server ein Java-Applet, welches mit Hilfe von JDBC die Verbindung zum Datenbankserver aufbaut. Das DBMS liefert wieder über JDBC etwaige Ausgaben an den WWW-Client, also an das Java-Applet, zurück.
 

7.11.3 Remote Method Invocation (RMI)
Dieser Abschnitt stellt das Konzept der Remote Method Invocation (RMI) zur Program-mierung von verteilten Softwaresystemen mit Java vor. Im vorangegangenen Abschnitt wurde deutlich, daß die direkte Verbindung des WWW-Clients an den Datenbankserver eher unerwünscht ist, sei es wegen Sicherheitsaspekten oder der Gefahr des unnötigen Aufblähens des Clients. Eine Erweiterung dazu wäre die Hinzunahme eines Servers, der die Verbindungen zum Datenbankserver koordiniert. Es muß dem WWW-Client explizit eine Methode zur Verfügung gestellt werden, welche die Verbindung zu einem entfernten Datenbankserver auf- oder abbaut, wobei diese Methode auf dem zusätzlichen Server zu implementieren wäre (da der WWW-Client keine direkte Verbindung zum Datenbankserver besitzen darf). Dieses Prinzip ähnelt einem Remote Procedure Call (RPC). Diese Methode heißt in Java RMI. RMI ermöglicht die Ausführung von Java-Programmen, die untereinander einen Kommunikationsbedarf besitzen, in unterschiedlichen Adreßräumen (DICK97). Die folgende Abbildung veranschaulicht die RMI-Architektur:

 
                                    Abb. 21: RMI-Architektur

7.11.4 Common Object Request Broker Architecture (CORBA)
Die Common Object Request Broker Architecture (CORBA) ist ein Standard der Object Management Group (OMG). Die OMG ist ein Konsortium von über 600 Firmen und wurde 1989 mit dem Ziel gegründet, eine Architektur für verteilte Systeme auf objektorientierter Basis zu entwickeln. Auf der Basis der Architektur kann eine Anwendung aus verschiedenen Komponenten geformt werden, die im Netzwerk verteilt vorliegen. Mit der Object Management Architecture (OMA) hat die OMG eine Softwarearchitektur spezifiziert, die das Zusammenarbeiten von Anwendungen verschiedener Hersteller ermöglicht, und zwar unabhängig von Betriebssystem, Hardware, Ort etc. Kern dieser Architektur ist die Spezifikation des Object Request Brokers (ORB). Er ist das von der OMA vorgesehene universelle Kommunikationsmedium für beliebig geartete Objekte in verteilten, heterogenen Systemen. Der dazugehörige Standard heißt CORBA. Dieser Standard zeichnet sich durch folgende Eigenschaften aus (vgl. REDL96 und OMG98):

• Objektorientierung
  Die grundlegenden Einheiten der Architektur sind Objekte, wobei ein Objekt im Sinne der OMA eine beliebige, eindeutig identifizierbare Einheit ist.

• Verteilungstransparenz
  CORBA-Programme greifen auf entfernte Objekte mit denselben Mechanismen zu wie auf lokale Objekte. Der genaue Aufenthaltsort eines Objekts bleibt für seine Clients in der Regel unbekannt.

• Effizienz
  Die Architektur für den ORB ist von der OMG bewußt so gehalten, daß effiziente Implementationen möglich sind, die z.B. im Falle rein lokaler Kommunikation dem klassischen Funktionsaufruf nur unwesentlich nachstehen.

• Hardware-, Betriebssystem- und Sprachunabhängigkeit
  Die Komponenten eines CORBA-Programms können auf verschiedenen
  Betriebssystemen, Hardwarearchitekturen und mit verschiedenen Programmiersprachen realisiert werden.

• Offenheit
  Über den ORB können Programme verschiedener Hersteller zusammenarbeiten.

Die Gundlage aller Standardisierungsaktivitäten der OMG ist die Object Management Architecture (OMA). In ihr werden Objekte als die grundlegenden Bausteine für verteilte Anwendungen festgeschrieben. Ein zentraler Aspekt der OMA ist die Beschreibung von Interfaces. Die OMG stellt dafür eine eigene Sprache namens Interface Description Language (IDL) bereit. Mit ihr werden die äußerlich sichtbaren Eigenschaften von Objekten (Attribute, Operationen, Exceptions, für die Kommunikation mit dem Objekt benötigten Datentypen) spezifiziert. Die OMA unterteilt die Bestandteile einer verteilten Anwendung in Komponenten. Konkret handelt es sich jeweils um eine Menge von Objekten, die gemeinsam eine bestimmte Aufgabe erfüllen. Die von ihnen wahrgenommene Aufgabe wird als Dienst (Service) bezeichnet. In separaten Standards identifiziert die OMG eine Reihe von Komponenten. Sie beschreibt ihre Aufgaben, d.h. die von ihnen bereitzustellende Funktionalität, und definiert die Interfaces der dazugehörigen Objekte.
Die OMA ordnet jede Komponente einer der folgenden fünf Gruppen zu: ORB, Object Services, Common Facilities, Domain Services, Application Objects. Folgende Abbildung stellt das OMA-Referenz-Modell dar:

Abb. 22: OMA Referenzmodell
 

Im folgenden werden die einzelnen Komponenten der OMA näher erläutert:
 

ORB
Der Object Request Broker (ORB) ist eine Komponente, die von Objekten zur Kommunikation mit anderen Objekten sowohl innerhalb desselben Programms als auch mit Objekten in einem anderen Programm genutzt werden kann. Er ermöglicht das transparente Weiterleiten eines Operationsaufrufs zu einem Zielrechner und schließlich zu dem betreffenden Objekt, unabhängig davon, welches Betriebssystem dort verwendet wird und in welcher Programmiersprache das aufgerufene Objekt implementiert ist. Der Aufrufer muß noch nicht einmal wissen, auf welchem Rechner sich das angesprochene Objekt physisch befindet. Die gemeinsame Benutzung des ORB als universelles Kommunikationsmedium ist eine grundlegende Voraussetzung für die Interoperalität zwischen verschiedenen Anwendungen.
 

Object Services
Object Services sind elementare, betriebssystemähnliche Funktionen, die in CORBA-Objekte mit in IDL spezifizierten Interfaces verpackt werden. Sie bilden einen Fundus an wiederverwendbaren Bausteinen, auf die der Benutzer bei Bedarf zurückgreifen kann. Sobald dieser Fundus umfassend genug ist, können verteilte Anwendungen vollkommen unabhängig von den Eigenschaften des lokalen Betriebssystems und der Hardware entwickelt werden. Sie müssen sich lediglich auf die standardisierten Schnittstellen des ORB bzw. der Object Services beziehen. Von der OMG werden Object Services für folgende Aufgaben definiert:

• Auffinden von Objekten im Netz (Naming Service)
• Behandlung asynchroner Ereignismeldungen (Event Service)
• langfristige Speicherung von Objektzuständen (Persistent Object Service)
• Schutz des Systems vor unerlaubter Benutzung (Security Service)
• Synchronisation von Uhren (Time Service)
• Koordinierung von nebenläufigen Aktivitäten (Concurrency Control Service)

• Regelung der Erzeugung und Beseitigung von Objekten (Lifestyle Service)

Die Spezifizierung der Object Services ist bislang nur teilweise abgeschlossen, so daß in der obigen Aufzählung nur die elementarsten Services genannt wurden.
 

Common Facilities
Common Facilities sind komplexe funktionale Einheiten, die einen wesentlichen Teil einer Anwendung ausmachen. Sie können durch Konfigurierungsmechanismen an verschiedene Aufgabenstellungen angepaßt werden und somit in mehreren Anwendungen eingesetzt werden. Die Common Facilities bauen auf den Object Services auf und sind stärker spezialisiert als diese.
 

Domain Services
Domain Services, die auch als Vertical Market Facilities bezeichnet werden, sind Lösungen für spezielle Anwendungsgebiete, die in Bezug auf ihren prinzipiellen Aufbau standardisiert sind. Oft handelt es sich dabei auch nur um eine systematische Beschreibung von bereits existierender Software in IDL.
 

Application Objects
Uinter einem Application Object verbirgt sich jeweils ein konkretes Produkt oder System, wie es vom Endbenutzer gesehen wird. Ein Application Object ist folglich etwas, das traditionell als Anwendung bezeichnet wird. Es ist für ein bestimmtes Anwendungsgebiet optimiert und stellt eine individuelle Lösung für ein spezielles Problem dar.

7.12 Bewertung der Datenzugriffskonzepte
 Um die in Kapitel 7.10 vorgestellten Vorteile des Einsatzes von Middleware auszunutzen, sollte der Datenbankzugriff über eine Drei-Ebenen-Architektur realisiert werden. Eine CORBA-Implementierung stellt sich für die Zukunft als erstrebenswert an. Der hohe Entwicklungsaufwand einer solchen Implementation stellte sich aber für diese Arbeit als zu zeitaufwendig dar. Realisiert wird der Datenbankzugriff über die CGI-Schnittstelle, über JDBC aus einem Java-Applet und über den Einsatz eines RMI-Servers. In Kapitel 8 werden die Vor- und Nachteile der Realisierungen beschrieben.

8 Realisierung
 

Dieses Kapitel beschreibt die Umsetzung der Konzeption der Benutzerführung LOTSE/Web. Vorgestellt werden die Programmiersprachen, mit denen die Realisierung der Benutzungsschnittstelle vorgenommen worden ist. Weiter werden die Koponenten dargestellt, die zur Realisierung der Systemarchitektur benötigt wurden. Dargestellt wird auch die Realisierung der Benutzungsoberfläche und die Realisierung des Datenbankzugriffs. Abschließend wird der LOTSE/Web diskutiert, der sich aus den vorangegangenen Komponenten zusammensetzt.

 
8.1 Entwicklungsplattform
Die Systemarchitektur wurde auf einer Unix-Workstation implementiert. Diese Wahl wurde getroffen, weil sich diese Plattform gegenüber anderen am vorteilhaftesten herausstellte. Die Mehrzahl der frei verfügbaren Tools zum Realisieren der Systemumgebung basieren auf Unix-Systemen. Es ist aber trotzdem möglich, die Systemarchitektur des LOTSE/Web auch auf anderen Plattformen zu installieren, wie z.B. auf einer PC-Plattform, die jedoch Vorteile einer Unix-Umgebung, wie z.B. Schnelligkeit, Robustheit, vermissen läßt. Zudem war die Vorgabe, die Systemarchitektur auf einer weitverbreiteten Rechnerplattform innerhalb der GKSS zu implementieren, zu erfüllen. Die Mehrzahl aller eingesetzten Systeme innerhalb der GKSS sind Unix-Systeme.
 

8.2 Systemarchitektur-Komponenten
Wie in Kapitel 7 beschrieben, sind folgende Systemkomponenten Bestandteil der Systemarchitektur: WWW-Server, SSL-WWW-Server, Suchmaschine, Datenbank und für die Benutzerseite ein WWW-Browser.
 

8.2.1 WWW-Server

Apache-WWW-Server
Die zentrale Komponente der Systemarchitektur ist ein WWW-Server. Der Server wird dazu benötigt, um die Kommunikation mit dem Benutzer zu ermöglichen. Frei verfügbare WWW-Server sind für fast alle Plattformen vorhanden. Für die Realisierung der Systemarchitektur wird der Apache-WWW-Server eingesetzt. Dieser Server ist frei verfügbar und unterliegt einer ständigen Weiterentwicklung (vgl. APAC98).
 

Apache-SSL-WWW-Server
Für die Übertragung von sicherheitsrelevanten Daten, wie z.B. Paßwörtern, wird parallel zum eigentlichen WWW-Server ein zweiter Server eingesetzt, der das SSL-Protokoll unterstützt. Er unterscheidet sich nicht im Namen, sondern im eingesetzten Übertragungsprotokoll https und einem anderen Port, auf dem er die Kommunikation betreibt. Als Basis wurde auch hier ein Apache-WWW-Server eingesetzt, der aber zusätzlich durch die frei verfügbare Software SSLeay (vgl. LEAY98) modifiziert wurde, um die sichere Übertragung zu ermöglichen. Der Apache-SSL-Server wird beim LOTSE/Web nur für die sichere Übertragung der Benutzerpaßwörter für den Zugang zur Datenbank eingesetzt. Der sicheren Übertragung von Daten steht die wesentlich geringere Übertragungsgeschwindigkeit zwischen Server und Client gegenüber, so daß SSL-Server nur bei sicherheitsrelevanten Transaktionen eingesetzt werden sollten.
 

8.2.2 HARVEST-Suchmaschine
Zu jedem Projekt innerhalb der WADABA wird eine statische HTML-Seite mit einer Datenbeschreibung generiert. Diese statischen Seiten sind effizient indizierbar. Sie werden über eine Suchmaschine zugänglich gemacht. Das zugrundeliegende System aus Schlagwort-Extraktion, Indizierung und Abfragefunktionen benutzt die Werkzeuge der HARVEST-Sammlung. Diese frei verfügbare Suchmaschine wurde von der Universität Colorado entwickelt (vgl HARV98). Je nach Konfiguration kann die Suchmaschine auch andere Datenbestände indizieren als die im Prototypen LOTSE/Web verwendetete Indizierung der statischen HTML-Seiten.
 

8.2.3 Datenbank
Als Speicherungsort für die Wattenmeerdatenbank wird das kommerzielle relationale Datenbankmanagementsystem ORACLE verwendet. Diese Datenbank ist auf einem speziellen Rechner innerhalb der GKSS installiert und kann über das Netz angesprochen werden. Das ORACLE-Datenbanksystem ist gekennzeichnet durch die nachfolgend beschriebenen Eigenschaften:

• Das Relationale Datenbankmodell
• Die Möglichkeit zur Verwaltung zentraler oder verteilter Datenbestände
• Das Client/Server-Konzept erlaubt den nebenläufigen Zugriff mehrerer Anwender auf die Datenbestände.
• Die relationale Datenbankabfragesprache SQL (Structured Query Language) nach dem ANSI-Standard
• Unterstützung der prozeduralen Spracherweiterung PL/SQL zur Ausführung von Transaktionen, den sogenannten PL/SQL-Anweisungen

• Verfügbarkeit des ORACLE-Datenbanksystems mit vergleichbarer Funktionalität als Laufzeitsystem für Rechner unterschiedlicher Hersteller und Leistungsklassen

Für den Zugriff auf die Daten stellt das Datenbanksystem nicht nur die Standard SQL-Abfrageschnittstelle zur Verfügung, sondern auch die Pro*C-Programmierschnittstelle und eine JDBC-Schnittstelle. Die JDBC-Schnittstelle ist nötig, um von Java-Anwendungen heraus über das Netz auf die ORACLE-Datenbank zugreifen zu können.
 

8.2.4 WWW-Browser
Um die Benutzungsschnittstelle dem Client zugänglich zu machen, ist ein WWW-Browser nötig. Alle relevanten WWW-Browser, wie z.B. Netscape, Internet Explorer oder Hotjava, sind frei verfügbar und stehen so allen potentiellen Nutzern zur Verfügung. Um die volle Funktionalität der Benutzerführung LOTSE/Web zu nutzen, muß der WWW-Browser in der Lage sein, Java-Applets auszuführen. Die eben genannten WWW-Browser erfüllen diese Bedingung.
 

8.3 Implementationskomponenten
Dieser Abschnitt beschreibt die verwendeten Komponenten, die zur Realisierung des LOTSE/Web verwendet wurden. Die Implementation wurde mit den Sprachen Java, Perl und C vorgenommen, die im folgenden näher erläutert werden.
 

8.3.1 Java
Java ist eine objektorientierte Programmiersprache. In einem objektorientierten System besteht eine Klasse aus einer Reihe von Daten sowie aus Methoden, die mit diesen Daten arbeiten. Zusammengenommen beschreiben Daten und Methoden den Zustand und das Verhalten eines Objekts. Klassen werden in einer Hierarchie angeordnet, so daß Unterklassen das Verhalten von übergeordneten Klassen (Superklassen) erben können. Eine Klassenhierarchie besitzt immer eine Stammklasse. Java wird mit einem sehr umfangreichen Satz von Klassen ausgeliefert. Diese sind in Paketen angeordnet. Beispielsweise stellt Java Klassen zur Verfügung, mit denen Komponenten graphischer Benutzungsschnittstellen erzeugt werden können (das Abstract Windowing Toolkit) oder Klassen, die die Netzwerkfunktionalität unterstützen. Java ist eine interpretierte Sprache: Der Java-Compiler erzeugt Byte-Code für die Java Vitual Machine (JVM) und keinen direkten Maschinencode. Ein Java-Programm wird durch den Java-Interpreter ausgeführt, der den kompilierten Byte-Code zur Ausführung bringt. Java-Byte-Code ist nicht von einer speziellen Plattform abhängig, d.h. Java-Programme können auf jeder Plattform ausgeführt werden, auf die die JVM portiert wurde. Diese Eigenschaft wird als architekturneutral bezeichnet.
Eine herausragende Eigenschaft von Java ist die Möglichkeit der Applet-Programmierung. Ein Applet ist eine Art Minimalanwendung, die für die Ausführung in einem WWW-Browser oder in einem Applet-Viewer gedacht ist. Applets unterscheiden sich von normalen Java-Anwendungen in einer Reihe von Punkten. Einer der wichtigsten ist, daß Applets bei ihrer Ausführung einer Reihe von Sicherheitsbeschränkungen unterliegen. Ein Applet besteht häufig aus unbekanntem Code, weshalb beispielsweise der Zugriff auf das lokale Dateisystem nicht erlaubt werden kann. Mit Java-Applets ist es möglich, daß Java-Programme innerhalb eines javafähigen WWW-Browsers ablaufen können und so komplexere Anwendungen für den Benutzer bereitgestellt werden können, als dies mit HTML-Seiten oder mit Hilfe der CGI-Schnittstelle möglich ist. Für die Anbindungen an Datenbanken stellt Java mit JDBC ein umfangreiches Paket für Abfragen und Manipulationsmöglichkeiten von Daten bereit (vgl. FLAN96).
 

8.3.2 Perl
Perl steht für "practical extraction and report language", was die Sprache recht treffend charakterisiert. Ziel der Entwickler bei der Erstellung von Perl war es, eine Sprache zu entwickeln, die einerseits die wichtigsten Programmierbefehle wie Schleifen, Verzweigungen, etc. enthält und andererseits aber auch die Möglichkeit bietet, leicht Such- und Ersetzungsoperationen wie in einem Editor durchzuführen. Somit entstand Perl im wesentlichen als eine Synthese aus der Programmiersprache C und den UNIX-Funktionen sed und awk. Die Programme, die man in Perl schreibt, werden als ASCII-Files gespeichert (wie ein shell-Skript) und erst unmittelbar vor der Ausführung kompiliert. Dies macht Programme einerseits leicht editierbar und auch auf andere Rechnersysteme übertragbar. Andererseits zeichnen sich Perl-Programme insbesondere bei Suchfunktionen durch eine hohe Geschwindigkeit aus. Perl ist Public-Domain-Software und somit (incl. Source-Code) frei verfügbar. Daher sollte es eigentlich auf jedem UNIX-System vorhanden sein. Außerdem existieren Portierungen für viele andere Rechnersysteme wie Macintosh, Atari, MS-DOS, OS/2, VMS etc., wobei bei Nicht-UNIX-Systemen meist nicht die gesamte Funktionalität zur Verfügung steht. Perl bietet sich als Sprache für CGI-Skripte an, da sie eine mächtige Stringbehandlung bietet, die das Verarbeiten z.B. von Benutzereingaben wesentlich erleichtert (vgl. WALL97).
 

8.3.3 C
Die Sprache C wird bei der Realisierung des LOTSE/Web für die Verbindung zur Datenbank eingesetzt. Mit der PRO*C-Schnittstelle des Datenbanksystems ORACLE können innerhalb eines C-Programms Datenbankzugriffe realisiert werden. Dies hat aber den Nachteil, daß dieses C-Programm abhängig von dem jeweiligen Betriebssystem ist, auf dem es läuft. Es stellt nur eine Möglichkeit dar, wie Datenbankzugriffe realisiert werden können. Zu Beginn dieser Arbeit war die Entwicklung von JDBC noch nicht so weit vorangeschritten, so daß man den Zugriff auf die Datenbank auf diese Weise hätte realisieren können.
 

8.4 Oberflächenrealisierung
Das Erscheinungsbild der Benutzungsoberfläche orientiert sich an den Darstellungsmöglichkeiten von dem jeweils eingesetzten WWW-Browser. Der WWW-Browser ist in der Lage, HTML-Dokumente graphisch aufzubereiten oder aber auch Java-Applets ablaufen zu lassen. Dargestellte HTML-Dokumente können statischer oder dynamischer Natur sein. Die dynamischen HTML-Dokumente werden ausschließlich durch Perl-Programme erzeugt, d.h. über die CGI-Schnittstelle wird ein Perl-Programm dazu veranlaßt, eine HTML-Ausgabe an den WWW-Browser des Benutzers zurückzuschicken. Beim LOTSE/Web wird die Oberfläche bis auf die Kartenverarbeitung mit Hilfe von HTML-Dokumenten dargestellt. Die Kartenverarbeitung wurde mit Hilfe von Java-Applets realisiert.
 

8.5 Realisierung des Datenbankzugriffs
Die in Kapitel 7.11 vorgestellten Datenzugriffskonzepte wurden - mit Ausnahme einer CORBA-Implementation - umgesetzt. Ein CORBA-basierter Zugriff auf Datenbanken erwies sich als zu zeitaufwendig für eine Realisierung (siehe 8.8).
 

8.5.1 CGI
Der Datenbankzugriff über die CGI-Schnittstelle des WWW-Servers wurde folgendermaßen realisiert: In einem CGI-Programm wird ein C-Programm auf dem Datenbankserver remote ausgeführt. Dieses C-Programm enthält als Argumente das auszuführende SQL-Statement und eine Datenbankbenutzer-Kennung mit dazugehörigem Paßwort. Das C-Programm kommuniziert mit der Datenbank und liefert als Ausgabe einen String mit dem Ergebnis der SQL-Abfrage. Diese Ausgabe wird innerhalb des CGI-Skripts analysiert und in eine zwei-dimensionale Array-Datenstruktur zur weiteren Verarbeitung abgelegt. Folgende Ausschnitte aus einem CGI-Programm verdeutlichen diese Datenbankzugriffsmethode:
.
.
.
# SQL-Abfrage
$sqlstring = "select PROJEKT,TITEL from DOKUMENT.PROJEKTE order by PROJEKT";

# C-Programm auf Datenbankserver starten und Speichern des
# Outputs des C-Programms
$sqlresult = `rsh $ORACLE_host -l $gkss5_user $backend \\""$sqlstring"\\" \\"$ORACLE_user\\" \\"$ORACLE_pw\\"`;

# Umwandlung des Outputs in ein zweidimensionales Array durch
# Subroutine &sqlresult_to_table
&table = &sqlresult_to_table($sqlresult);

# weitere Verarbeitung des Abfrageergebnisses
.
.
.
 

Ein großer Nachteil des Datenbankzugriffs über die CGI-Schnittstelle ist, daß pro SQL-Abfrage jeweils ein kompletter An- und Aufbau der Datenbankverbindung nötig ist. Bei vielen SQL-Abfragen innerhalb eines CGI-Programms kann es dann durchaus zu Wartezeiten kommen.
 

8.5.2 JDBC
Der Datenbankzugriff mit JDBC wird entweder über ein Java-Applet oder eine Java-Applikation realisiert. Für den LOTSE/Web wurde der Einsatz von JDBC in Java-Applets nur beispielsweise erprobt. Aus Sicherheitsgründen sollte davon abgeraten werden, daß Java-Applets direkt mit Datenbankservern kommunizieren, da alle sicherheitsrelevanten Daten, wie z.B. Datenbankuserkennung und das dazugehörige Paßwort, innerhalb des Applets auf Client-Seite liegen und somit unerwünschte Manipulationen im Bereich des Möglichen liegen.
Innerhalb eines Java-Programms (Applet oder Applikation) kann nun eine Verbindung zur Datenbank aufgebaut werden und SQL-Statements an die Datenbank weitergegeben werden. Ist eine Verbindung zur Datenbank erfolgreich aufgebaut, so bleibt diese bestehen, d.h. es können beliebig viele SQL-Statements an die Datenbank weitergeleitet werden, bis die Verbindung explizit wieder abgebaut wird. Folgendes Programmbeispiel veranschaulicht den Einsatz von JDBC in einer Java-Applikation:

import java.sql.*;
.
.
.
public class JDBC_Beispiel {

public static void main (String args [])
    throws SQLException, ClassNotFoundException {
.
.
.

//Lade den JDBC-Treiber für eine ORACLE-Datenbank
Class.forName ("ORACLE.jdbc.driver.ORACLEDriver");

// Datenbankverbindung aufbauen
Connection conn =
DriverManager.getConnection ("jdbc:ORACLE:thin:@DATENBANKSERVER:1521:WADABA", "DB-UID", "PW");
 

// Erzeuge ein SQL-Statement
Statement stmt = conn.createStatement ();

// Führe eine SQL-Abfrage aus und speichere das Ergebnis
ResultSet rset = stmt.executeQuery("select PROJEKT, TITEL from DOKUMENT.PROJEKTE order by PROJEKT");

// Das Ergebnis der SQL-Abfrage wird in einer Datenstruktur ResultSet zur
// weiteren Verarbeitung gespeichert
.
.
.
// Schließen der Datenbankverbindung
conn.close();
}

} // Ende der JDBC-Beispiel-Applikation
 

Diese Java-Applikation baut eine Verbindung zu einer Datenbank auf und führt eine SELECT-Abfrage durch. Das Ergebnis dieser Abfrage wird in einer Datenstruktur ResultSet gehalten.
 

8.5.3 RMI
Eine weitere Methode, den Datenbankzugriff zu realisieren, ist RMI. Mit dieser Methode ist es möglich, einen eigenen Server zu konstruieren, der für den Auf- und Abbau der Datenbankverbindung verantwortlich ist. Java-Applets oder Applikationen kommunizieren nun nicht mehr direkt mit dem Datenbankserver, sondern mit einem RMI-Server, der die Abfrageergebnisse an das Applet bzw. Applikation zurückschickt. Zur Implementation eines RMI-Servers wird zunächst ein Interface benötigt, das die Methoden deklariert, die remote benutzt werden können.

// Interface fuer den RMI-Beispiel-Server.

public interface RMIBeispielServ extends java.rmi.Remote {

//Deklaration der remote Methoden

ResultSet SQLquery (String sqlstring) throws java.rmi.RemoteException;

}

Dieses Interface beinhaltet nur eine Methode. Sie erwartet einen SQL-String und gibt als Ausgabe das Abfrageergebnis als Datentyp ResultSet zurück. Der dazugehörige RMI-Server kann folgendermaßen realisiert werden:

/*
* RMIBeispielServer.java
* Einfacher BeispielServer, der eine Methode remote zur
* Verfuegung stellt.
*/

import java.rmi.*;
import java.rmi.server.UnicastRemoteObject;
import java.sql.*;
 

 public class RMIBeispielServer extends UnicastRemoteObject
             implements RMIBeispielServ
{
private String serverName;

public RMIBeispielServer (String s) throws RemoteException {
  super();
  serverName = s;

public ResultSet SQLquery(String SQLstring) throws RemoteException  {
 

// Versuche Verbindung zur Datenbank aufzubauen und das
// Abfrageergebnis an den Client zurueckzuschicken

ResultSet rset = null;
String s = null;

try {

Class.forName ("ORACLE.jdbc.driver.ORACLEDriver");

  Connection conn =
  DriverManager.getConnection ("jdbc:ORACLE:thin:@gkss05:1521:wadaba",
          "DB-User", "DB-Password");
  Statement stmt = conn.createStatement ();
  rset = stmt.executeQuery(SQLstring);
}

catch (SQLException ex) {/* Exception Handling */}

catch ( ClassNotFoundException cnfexc ) {/* Exception Handling */}

    return rset;

  }

public static void main (String args []){

  System.setSecurityManager (new RMISecurityManager());

  try {
    RMIBeispielServer obj = new RMIBeispielServer ("RMIServer");
    Naming.rebind ("//guisun3/RMIServer", obj);
    System.out.println ("RMIServer in der Registry gebunden.");
      }

  catch (Exception e) {/* Exception Handling */}
}

Der RMI-Server enthält nun die Implementierung der Methode SQLquery. Clients können nun über diesen Server SQL-Statements an eine Datenbank schicken und die Abfrageergebnisse als Antwort des Servers erhalten.
 

8.6 Realisierung des LOTSE/Web
Auf der Serverseite ist die Installation der beiden WWW-Server auszuführen. Zum einen der "normale" WWW-Server, der alle Komponenten, bis auf die sichere Übertragung von Benutzerkennungen und Paßwörtern, der Benutzungsschnittstelle zur Verfügung stellt und zum anderen einen weiteren WWW-Server, der eben nur die sichere Übertragung von Daten realisiert. In der Abbildung 23 werden die realisierten Komponenten der Benutzerführung dargestellt. Diese Komponenten bestehen aus CGI-Programmen, Java-Programmen in Appletform und statischen HTML-Dokumenten. Pfeile an den jeweiligen Komponenten verdeutlichen den Ablauf, mit dem sich der Benutzer durch die Programme bewegt. Die waagerechte Linie symbolisiert den Übergang von der Metadatenebene zur Sachdatenebene. Bis zu diesem Punkt sind alle Informationen für die ganze Welt einsehbar. Werden nun aber konkrete Projektdaten verlangt, so ist die Benutzung des Systems erst durch eine gültige Benutzer/Paßwortkombination möglich. Im folgenden Abschnitt werden die einzelnen Komponenten näher erläutert.
 

Statische HTML-Dokumente
Die statischen HTML-Dokumente, die für die Aufbereitung des Menübaums, die Projektindex-Liste und für die Metainformation der jeweiligen Projekte benötigt werden, werden durch Perl-Programme erzeugt und an den spezifischen Stellen für den WWW-Server abgelegt. Diese Programme werden in festen Zeitintervallen ausgeführt, damit der aktuelle Datenbestand aus der WADABA auch auf den statischen HTML-Dokumenten repräsentiert wird.
 

Suchmaschine
Die Suchmaschine wurde so konfiguriert, daß sie in festen Zeitintervallen die statischen HTML-Dokumente, auf denen die Metainformation von Projekten aus der WADABA repräsentiert wird, indiziert.
 

Geographische Suche
Die geopraphische Suche wurde durch ein Java-Applet realisiert, das die Möglichkeit zur orts- und zeitbezogenen Recherche bietet. Die nötigen Datenbankzugriffe wurden zunächst über die JDBC-Schnittstelle realisiert. Im Verlauf der Realisierung wurde ein RMI-Server entwickelt, der die Kommunikation mit der Datenbank übernahm. Da sich diese Lösung als nicht robust genug für den Dauereinsatz zeigte, wurde auf der Zugriff letztendlich über das "bewährte" C-Backend vorgenommen. Im Dauerbetrieb zeigten sich hier keine Ausfälle.
 

Graphische Darstellung des Projektgebiets
Die graphische Darstellung des Projektgebiets wurde ebenfalls durch ein Java-Applet realisiert. Es stellt das jeweilige Projektgebiet durch ein Rechteck dar, auf das ein digitalisiertes Satellitenbild gezeichnet wird.
 

Dynamische Repräsentation von Metainformation
Die dynamische Repräsentation von Metainformation eines Projekts wurde durch ein in Perl programmiertes CGI-Programm realisiert.
 

CGI-Programme für die Darstellung von Projektdaten
Die Programme, die für die Ausgabe von Projektdaten benötigt wurden, sind ausnahmslos in Perl programmierte CGI-Programme. Die hierbei nötigen Datenbankzugriffe werden über die CGI-Schnittstelle realisiert (siehe 8.5.1):

• Datenbankanmeldung
• Auswahl der Projekttabellen
• Anzeigen des Tabelleninhaltes
• Anzeigen der Tabellenbeschreibung
• Anzeigen von einzelnen Spaltenbeschreibungen

• Downloadmöglichkeit von Projekttabellen

Abb. 23: Komponenten des LOTSE/Web
 

8.7 Probleme bei der Realisierung
Im Laufe der Implemenation traten einige Probleme auf. Als ein großes Problem erwies sich der Zustand der WADABA in dem relationalen Datenbanksystem ORACLE. Es stellte sich heraus, das einige Datenbankobjekte, wie z.B. Tabellen oder Views, nicht vollständig oder sogar fehlerhaft von der IBM-DB2-Datenbank auf das ORACLE-System portiert wurden. Die Suche nach den fehlerhaften Objekten erwies sich als sehr zeitaufwendig. Zudem mußten diese Fehler manuell behoben werden, was sich auch als sehr arbeits- und zeitintensiv herausstellte.
Auch der Einsatz von JDBC gestaltete sich anfangs sehr problematisch. Erst in der 1.1-Version des Java-Development-Kits (JDK) war das JDBC-Package Bestandteil des JDK. Mit der neuen Version des JDK wurden z.B. einige Komponenten, wie z.B. das Behandeln von Ereignissen, komplett neu definiert.
Die JDBC-Anbindung an das ORACLE-Systems erwies sich anfangs auch als sehr probelematisch. Hinzu kommt auch noch, das ein Update von der Version 7.1 auf die Version 7.3 des ORACLE-Systems vorgenommen wurde. Während dieses sehr zeitintensiven Updates war die Datenbank oft nicht verfügbar.
Als sehr zeit- und arbeitsaufwendig erwies sich auch die Konfiguration und Installation der HARVEST-Suchmaschine und des SSL-WWW-Servers. Nach erfolgreichem Installieren laufen diese Komponenten jedoch stabil und zuverlässig.
 

8.8 Offene Punkte
Wie in Kapitel 2 bereits angedeutet, steht der 4-dimensionale Suchraum noch nicht zur Verfügung. Erst bei erfolgreicher Portierung der dazugehörigen Datenbankobjekte von der IBM-DB2-Datenbank auf das ORACLE-System kann diese Funktionalität angeboten werden.
Eine Online-Hilfe für jeden Schritt innerhalb der Benutzerführung steht noch nicht zur Verfügung. Die Bedienungsanleitung aus Anhang A steht jedoch als HTML-Dokument zur Einsicht bereit.
Die Benutzerführung LOTSE/Web führt momentan nur durch den Datenbestand der Wattenmeerdatenbank WADABA. Die Möglichkeit, auf andere Datenbanken Zugriff zu erlangen, die Umweltdaten enthalten, war nicht möglich.
Ein CORBA-basierter Zugriff auf Datenbanken wurde nicht realisiert, da sich die Implemenation dieser Methode als zu zeitintensiv herausstellte. Eine CORBA-basierte Architektur für den Zugriff auf Datenbanken wird von dem zur Zeit laufenden Projekt TIDE (siehe Kapitel 9) konzipiert und realisiert.

9 Zusammenfassung und Ausblick

 
In dieser Arbeit wurde die Benutzerführung LOTSE/Web für das Wattenmeerinformationssystem WATiS als eine WWW-basierte Anwendung konzipiert und realisiert. Dadurch kann der LOTSE/Web einer großen Zahl von Nutzern zugänglich gemacht werden. Die Benutzung des LOTSE/Web ist zudem auf keine spezielle Rechnerplattform angewiesen. Der Benutzer benötigt lediglich einen graphischen WWW-Browser und eine Verbindung zum Internet. Die Funktionalität der bisher entwickelten Nutzerführungen wurde im wesentlichen beibehalten. Eine Volltextrecherche über die vorhandene Metainformation wird über eine Suchmaschine möglich gemacht und erweitert die bisher vorhandene Funktionalität. Zudem wurde gezeigt, daß Konzepte, wie z.B. RMI oder CORBA, existieren, die einen Zugriff auf andere Datenbestände erleichtern. Der LOTSE/Web ist problemlos in seiner Funktionalität erweiterbar. Neue Funktionen können in bestehende Programme integriert werden oder auch als neue Komponenten in die LOTSE/Web-Architektur eingefügt werden.
Die Einbeziehung von Mitarbeitern der GKSS innerhalb des Entwicklungsprozesses hat sich als äußerst positiv, wenn auch zeitaufwendig erwiesen. Der Funktionsumfang konnte somit den Benutzerwünschen angepaßt werden.
Der Datenbankzugriff über ein C-Programm erwies sich im Dauereinsatz am robustesten. Der Zugriff über JDBC stellte sich zwar auch als problemlos heraus, doch aus Sicherheitsgründen wurde eine reine JDBC-Anbindung an die Datenbank verworfen. Der Datenbankzugriff über einen RMI-Server erwies sich im Langzeitverhalten als nicht stabil genug.
Für die Zukunft ist davon auszugehen, daß die Benutzerführung sich zu einer integrierten, auf Java basierenden Lösung weiterentwickeln wird. Die Verwendung von CGI-Skripten für die Interaktion mit dem Benutzer erweist sich für die Zukunft als viel zu unflexibel. In dem zur Zeit laufenden Projekt TIDE (siehe Kapitel 1) wird eine dreistufige Systemarchitektur unter Einsatz von CORBA konzipiert und realisiert (vgl. GEHL97).

ANHANG

---

Literaturverzeichnis
 
 

 

GEHL97	Gehlsen, B.; Krasemann H.; Kriebisch, R.; Lamersdorf, W.; Page, B..: Das Projekt TIDE-Werkzeuge für eine einheitliche Sicht auf heterogene, verteilte Umweltdaten 1997
GEIS90	Geiser, G.: Mensch-Maschine-Komunikation. München; Wien: Oldenbourg 1990
GERK95	Gerken, B.; Meyer, R.: Geographische Informationssysteme. Universität Hamburg: Fachbereich Informatik 1995
GOTT90	Gottlob, G. (Hrsg.): Expertensysteme. Wien; New York: Springer 1990
GRUE94	Grützner, R.; Häuslein, A.; Page, B.: Softwarewerkzeuge für die Umweltmodellierung und -simulation. In: PAGE94, S. 157 - 182
GUEN94	Günther, O.; Radermacher, F.-J.; Riekert W.F.: Umweltmonitoring. In PAGE94, S. 51 - 79
GUND96	Gundavaram, S.: CGI-Programmierung im World Wide Web. Bonn: O'Reilly 1996
HARV98	Harvest Search Engine. URL: ://harvest.cs.colorado.edu
HDF98	The Hierachical Data Format. URL: http://dao.gsfc.nasa.gov/data_stuff/formatPages/HDF.html
HERR97	Herrmann, E.: CGI Programming with Perl 5. Indianapolis: sams.net 1997
HILT95	Hilty, L. M. et al.: 8. Symposium Informatik für den Umweltschutz. Marburg: Metropolis-Verlag 1995
HOSE97	Hosenfeld, F.: Internetzugang zur Datenbank des ökologischen Infoarmationssystems KERIS. Vilm: 1997
HUEB90	Hübner, W: Entwurf graphischer Benutzerschnittstellen. Berlin: Springer-Verlag 1990
JAES91	Jaeschke, A.; Keitel, A.; Mayer-Föll, R.; Radermacher, F. J.; Seggelke, J.: Metawissen als Teil von Umweltinformationssystemen. In : Günther, O.; Kuhn, H.; Mayer-Föll, R.; Radermacher, F.J.: Konzeption und Einsatz von Umwelt- informationssystemen. Berlin: Springer, Informatik-Fachberichte 301 1991
JAES93	Jaeschke, A. et al. (Hrsg.): Informatik für den Umweltschutz, 7. Sympo-sium 1993. Berlin; Heidelberg; New York: Springer-Verlag 1993
KLIN96	Klingert, Arnold: Einführung in Graphische Fenstersysteme. Berlin, Heidelberg: Springer-Verlag 1996

 

KÖNI96	König, H.; Krumm, H.: Implementierung von Kommunikationsprotokollen.In: Informatik Spektrum 19, S. 316-325. Berlin: Springer-Verlag 1996
KORD97	Kordes, M.: WWW-Zugang zu Umweltdaten über Rechnernetze am Beispiel der Umweltbehörde Hamburg. Universität Hamburg: Fachbereich Informatik 1997
KRAS94	Krasemann H.; Riethmüller, R.: WATiS - Das Informationssystem zur öko- logischen Beobachtung des Wattenmeeres im Verbund von Forschung und Verwaltung. URL: http://w3gkss.de/watis/TEXT/GIS2-94.html. (Ver- öffentlicht in: GIS-Geo-Information-Systems Vol.7 No.2 April 1994)
KRAS96	Krasemann, H. L.; Müller, A.; Patzig, S.; Riethmüller, R.; Wagler, H.: WATiS - Das Wattenmeerinformationssystem für Forschung und Verwaltung. URL: http://w3g.gkss.de/watis/TEXT/Einfuehrung.html 1996
KREM94	Kremers, H. (Hrsg.): Umweltdatenbanken. Marburg: Metropolis-Verlag 1994
KREM95	Kremers, H.; Pillmann, W.: 9. Symposium Informatik für den Umwelt-schutz. Marburg: Metropolis-Verlag 1995
KUEH97	Kuehnel, R.: Die Java-1.1-Fibel. Bonn: Addison-Wesley-Longman 1997
LAME94	Lamersdorf, W.: Datenbanken in verteilten Systemen. Braunschweig, Wiesbaden: Vieweg 1994
LAUS95	Lausen, G. (Hrsg.): Datenbanksysteme in Büro, Wissenschaft, Technik. Berlin: Springer-Verlag 1995
LAUT95	Lautenschlager, M.: Vereinheitlichte Metadatenstruktur zur Beschreibung klimarelevanter Daten. 1995
LEAY98	SSLeay. URL: http://www.cs.tamu.edu/helpdocs/ssl/
LEIT92	Leithäuser, K.: Entwicklung eines Nutzerführungssystems für das Wattenmeerinformationssystems WATiS. 1992
LESS95	Lessing, H.; Günther, O.; Swoboda, W.: Ein objektorientiertes Klassen-konzept für den Umwelt-Datenkatalog (UDK). In: KREM95, S. 391-399
LIU96	Liu, C.; Peek, J.: Internet-Server: Einrichten und Verwalten. Bonn: O'Reilly 1996
LOCK87	Lockemann, P. C. (Hrsg.); Schmidt, J. W. (Hrsg: Datenbank-Handbuch. Berlin;Heidelberg: Springer-Verlag 1987

 

METT95	Metternich, P.: Das Zentrale UmweltDaten-InformationsSystem ZUDIS am Forschungszentrum Karlsruhe. 1995
NAGL90	Nagl, M.: Softwaretechnik: Methodisches Programmieren im Großen. Berlin; Heidelberg 1990
NIEM97	Niemeyer, P.: Java: Expedition ins Programmierreich. Bonn: O'Reilly 1997
OBER90	Oberquelle, H.: Software-Ergonomie I. Universität Hamburg, Fachbereich Informatik: Vorlesungsskript WS 90/91
OBER92	Oberquelle, H.: Software-Ergonomie II. Universität Hamburg, Fachbereich Informatik: Vorlesungsskript WS 92/93+B37
OMG98	Object Management Group. URL: http://www.omg.org/
PAGE93	Page, B.; Häuslein, A.; Greve, K.: Das Hamburger Umweltinformationssystem HUIS. Umweltbehörde Hamburg. 1993
PAGE94	Page, B.; Hilty, L. M.: Umweltinformatik. München, Wien: Oldenbourg-Verlag 1994
RAAS93	Raasch, J.: Systementwicklung mit Strukturierten Methoden. München; Wien: Hanser 1993
REDL96	Redlich, J.-P.: CORBA 2.0: Praktische Einführung für C++ und Java. Bonn: Addison-Wesley 1996
RIEC95	Rieche, B.; Dittrich K. R.: Einsatz und Nutzen einer Metaebene für förderierte Datenbanksysteme am Beispiel der Molekularbiologie. In: LAUS95, S. 358-372
RUDO97	Rudolph, P.; Mossgraber, J; Schmid, H.: ELISE-Ein Konzept zum Aufbau eines WWW-basierten Informationssystems für die Elbe-Ökologie und Integrationsvorschläge für vorhandene Umweltinformationssysteme. Berlin, Karlsruhe: 1997
SAYE97	Sayegh, A.: Corba - Standard, Spezifikationen, Entwicklung. Cambridge; Köln; Paris: O'Reilly 1997
SCHE94	Scheller, M.; Boden, K.-P.; Geenen, A.; Kampermann, J.: Internet - Werkzeuge und Dienste. Berlin: Springer Verlag
SCHU94	Schütz, T.; Lessing, H.: Metainformation von Umwelt-Datenobjekten - Zum Datenmodell des Umwelt-Datenkataloges Niedersachsen. In: JAES93, S. 19-28

 

SLOM88	Sloman, M.: Verteilte Systeme und Rechnernetze. München; Wien: Hanser 1988
SSL98	Secure Socket Layer. URL: http://www.w3.org/Security
STAR94	Stary, C.: Interaktive Systeme. Braunschweig: Vieweg 1994
TRES96	Tresch, M.: Middleware: Schlüsseltechnologie zur Entwicklung verteilter Informationssysteme. In: Informatik Spektrum 19, S. 249-256. Berlin: Springer-Verlag 1996
UDK98	Der Umweltdatenkatalog Niedersachsen. URL: http://www.mu.uni-hannover/WWW-UDK
ULTS94	Ultsch, A.: Einsatzmöglichkeiten von Neuronalen Netzen im Umweltbereich. In: PAGE94, S. 201 - 226
WALL97	Wall, L.; Christiansen, T.; Schwartz, R. L.: Programmieren mit Perl. Cambridge; Köln; Paris: O'Reilly 1997
WILL93	Willmann, D.: Grafisch orientierte Abfragen bei verteilter Datenhaltung für das Wattenmeerinformationssystem WATiS. 1993
WINT94	Winter, V.: Erweiterung eines Nutzerführungssystems für Umweltdatenbanken. 1994
WOLF96	Wolff, N.; Lüders, M.; Cummerow, R.: Metainformationssysteme im Umweltbereich. Universität Hamburg: Fachbereich Informatik 1996
ZEID92	Zeidler, A.; Zellner, R.: Software-Ergonomie. München, Wien: Oldenbourg 1992
ZIEG93	Ziegler, J.; et al.: Benutzergerechte Software-Gestaltung. München; Wien: Oldenbourg 1993
ZUDI98	Das Zentrale Umwelt- und Klimadaten-Metainformationssystem ZUDIS. URL: http://hbksun17.fzk.de:8080/ZUDIS/zudis.html

Abkürzungsverzeichnis
 
 

API	Application Programming Interface
AWI	Alfred-Wegener-Institut
AWT	Abstract Windowing Toolkit
CERA	Climate and Enviromental Data Retrieval and Archive -Datenmodell
CGI	Common Gateway Interface
CORBA	Common Object Request Broker Architecture
DBMS	Datenbank Management System
DIF	Directory Interchange Format
DKRZ	Deutsches Klimarechenzentrum
DNS	Domain Name Service
E-Mail	Electronic Mail
FTP	File Transfer Protocol
GCMD	Global Change Master Directory
GIS	Geographisches Informationssystem
GKSS	GKSS Forschungszentrum Geesthacht
HDF	Hierarchical Data Format
HGF	Hermann von Helmholtz-Gemeinschaft Deutscher Forschungseinrichtungen
HTML	Hypertext Markup Language
HTTP	Hypertext Transfer Prorocol
IIOP	Internet Inter ORB Protocol
IP	Internet Protocol
JDBC	Java Database Connectivity
LOTSE	Lan Ocean Thematic Search Engine
OMA	Object Management Architecture
OMG	Open
ORB	Object Request Broker
RDBMS	Relationales Datenbank Management System
RMI	Remote Method Invocation

 

SQL	Structured Query Language
SSL	Secure Socket Layer
TCP	Transmission Control Protocol
UDK	Umweltdatenkatalog
UDP	User Datagram Protocol
UIS	Umweltinformationssystem
URL	Uniform Ressorce Locator
WADABA	Wattenmeerdatenbank
WAIS	Wide Area Information Service
WATiS	Wattenmeerinformationssystem
WWW	World Wide Web
ZUDIS	Zentale Umwelt- und Klimadaten-Metainformationssystem

Bedienungsanleitung für den LOTSE/Web

Der LOTSE/Web führt den Benutzer durch die Daten der innerhalb der GKSS befindlichen Wattenmeerdatenbank WADABA. Die Benutzung erfordert eine Internetverbindung und einen WWW-Browser. Der WWW-Browser ist das zentrale Hilfsmittel für den Benutzer, um sich mit Hilfe der Benutzerführung LOTSE/Web durch die Datenbestände der WADABA zu bewegen. Auch bei geringen Vorkenntnissen entwickelt der Benutzer schnell ein Gefühl für die Handhabung der Benutzerführung, solange er mit der elementaren Funktionalität des WWW vertraut ist. Dieses beginnt mit der Eingabe einer URL in den WWW-Browser, um mit einem WWW-Server zu kommunizieren, der dem Benutzer Informationen bereitstellt. Die Bedienungsanleitung für den LOTSE/Web gliedert sich wie folgt:

• Start der Benutzerführung
• Datensuche im kompakten Menübaum
• Datensuche im strukturierten Menübaum
• Datensuche im Projektindex
• Datensuche per Suchmaschine
• Geographische Suche
• Metainformation einsehen

• Projektdaten einsehen

Start der Benutzerführung

Der Benutzer startet seinen WWW-Browser mit der URL http:/w3g.gkss.de/lotse. Ab diesem Punkt startet die mausgesteuerte Benutzerführung LOTSE/Web (s. Abb. A1).

Abb. A.1: Startseite des LOTSE/Web

Hier werden dem Benutzer fünf Möglichkeiten für die Suche nach Daten angeboten:

• Die Kompakte Version des Menübaums ermöglicht die Navigation über Schlagworte bis hin zu den Projekten, für die weitere Datenbeschreibungen vorhanden sind.
• Im Gegensatz zur kompakten Version des Menübaums springt der Benutzer von Knoten zu Knoten des Baumes, wobei jeder Knoten von einer statischen HTML-Seite repräsentiert wird. Der Vorteil gegenüber der kompakten Version besteht darin, daß die HTML-Seite, die jeden Knoten repräsentiert, sehr klein ist und daher geringe Ladezeiten benötigt.
• Eine Projektindexliste stellt alle vorhandenen Projekte alphabetisch dar und ermöglicht den direkten Zugang zu vorhandener Metainformation und den Zugang zu den Projektdaten.
• Eine Suchmaschine ermöglicht die Volltextrecherche über die vorhandene Metainformation der Projekte innerhalb der Wattenmeerdatenbank.

• Eine Kartensuche ermöglicht die geographische Suche von Projekten.

Datensuche im kompakten Menübaum

Der gesamte Menübaum wird als ein HTML Dokument bereitgestellt. Der Benutzer kann sich durch Anklicken der Hyperlinks durch den gesamten Baum bewegen (siehe Abb. A.2).

Abb. A.2: Kompakte Version des Menübaums

Datensuche im strukturierten Menübaum

Die Datensuche in der strukturierten Version des Menübaums gestaltet sich ähnlich wie in der kompakten Version. Hier wird aber nicht der komplette Baum als HTML-Dokument geladen, sondern die einzelnen Knoten des Baumes werden als einzelne HTML-Dokumente bereitgestellt (siehe Abb. A.3).

Abb. A.3: Strukturierte Version des Menübaums

Datensuche im Projektindex

Der Projektindex listet alle vorhandenen Projekte des WATiS alphabetisch auf. Per Mausklick kann die vorhandene Metainformation zu einem Projekt eingesehen werden oder zeigt den Kontext an, den das Projekt im Menübaum einnimmt (siehe Abb. A.4)

 
        Abb. A.4: Projektindex
 
 

Datensuche per Suchmaschine

Die Suchmaschine ermöglicht die Volltextrecherche über die vorhandenen Metadaten von Projekten. Die Such-Optionen können vom Benutzer selbst bestimmt werden

(siehe Abb. A.5).

            Abb. A.5: Anfrageformular der Suchmaschine

Bei Treffern der Suchmaschine gibt die Suchmaschine eine Liste von HTML-Seiten zurück, die eine Übereinstimmung mit dem Suchbegriff haben (siehe Abb. A.6).

            Abb. A.6: Ergebnis der Suchmaschinen-Recherche
 
 

Geographische Suche

Bei Anwahl der geographischen Suche zieht der Benutzer ein Rechteck auf der digitalisierten Karte auf, d.h. einen Punkt wählen, Maustaste gedrückt lassen und einen zweiten Punkt wählen, dann die Maustaste lösen. Innerhalb dieses aufgezogenen Rechtecks wird durch Drücken des SHOW-Buttons die Anzeige der innerhalb des Rechtecks vorhandenen Projekte veranlaßt. Soll ein neues Rechteck erzeugt werden, so braucht der Benutzer nur nach vorgestelltem Muster vorgehen. Die vorherige Eingabe wird dann automatisch gelöscht. Eine zweite Möglichkeit ist das Drücken des RESET-Buttons, der Benutzereingaben auch verwirft.

Der RESET-Button löscht aber zudem auch Ausgaben des Systems (siehe Abb. A.7). Durch die Eingabe eines Zeitraums hat der Benutzer die Möglichkeit, ein weiteres Kriterium zur Suche. Somit ist eine orts- und zeitabhängige Suche nach Projekten durchführbar. Hat der Benutzer ein Rechteck aufgezogen und das System durch Drücken des SHOW-Buttons die Anzeige der innerhalb des Rechtecks vorhanden Projekte veranlaßt, werden zwei neue Fenster erzeugt. In dem einen Fenster werden die Projekte mit ihrem Kürzel und dem Titel angezeigt, in dem anderen Fenster befinden sich Buttons, die mit dem jeweiligen Projektkürzel beschriftet sind (siehe Abb. A.8). Durch Drücken einer der Buttons wird das jeweilige Projektgebiet auf der Karte als blinkendes Rechteck dargestellt und zudem das Öffnen eines neuen Browser-Fenster veranlaßt, das die vorhandene Metainformation für das betreffende Projekt anzeigt (siehe Abb. A.9).

Abb. A.7: Geographische Suche

Abb. A.8: Neu erzeugte Fenster, die textuelle Information

und Buttons enthalten
 

Abb. A.9: Projektgebiet wird innerhalb der Karte angezeig,t und ein neues Browserfenster wird mit beschreibenden Daten des Projekts geöffnet
 
 

Metainformation einsehen

 Metainformation über ein Projekt kann nicht nur über die geographische Suche erlangt werden, sondern auch über die drei ersten Auswahlpunkte des Ausgangsmenüs. Sowohl die Auswahl von Projekten in der kompakten und strukturierten Version des Menübaums, im Projektindex als auch die Recherche über die Suchmaschine liefern eine Referenz für die Anzeige von Metainformation.

Abb. A.10 : Metainformation über ein Projekt

Auf der HTML-Seite, auf der die Metainformation für ein Projekt dargestellt wird (siehe Abb. A.10), gibt es für den Benutzer weitere Möglichkeiten zum Erlangen von zusätzlicher Information. Wenn für das Projekt Koordinaten für das definierte Projektgebiet bzw. Koordinaten für die tatsächlich erhobenen Daten vorhanden sind, kann der Benutzer auf das jeweilige Windrosensymbol klicken, was eine graphische Darstellung des Projekt- bzw. Datengebiets erfolgen läßt (siehe Abb. A.11). Die Adressenangabe(n) zu jedem Projekt läßt sich durch eine Auswahl detaillierter anzeigen (siehe Abb. A.12). Sind Sachdaten des entsprechenden Projekts vorhanden, gibt es einen Button, der zur Authentisierungsmaske führt. Existieren andere beschreibende Datenquellen zu einem Projekt, so werden diese durch Angabe eines Hyperlinks zugänglich gemacht.
 
 

Abb. A.11: Anzeige der Fläche in der für das Projekt SCHADS Daten erhoben wurden

Abb. A.12 : Detaillierte Adressenangabe

Abb. A.13: Möglichkeit zum Zugang zu Projektdaten in der WADABA und
zusätzliche Information zu einem Projekt

 

Projektdaten einsehen

Durch Anklicken des Buttons in Abb. A.13 gelangt der Benutzer zur Authentisierungsmaske und muß seine Projektkennung und sein Paßwort eingeben, um Zugang zu den Projektdaten in der WADABA zu erhalten (siehe Abb. A.14).

Abb. A.14: Authentisierungsformular

Hat der Benutzer die korrekte Kennung und Paßwort eingegeben, erscheint eine Übersicht der Datenbank-Tabellen des jeweiligen Projekts (siehe Abb. A.15). Der Benutzer hat nun die Möglichkeit, sich die Inhalte der Tabellen oder sich weitere Informationen zu den Tabellen anzeigen zu lassen (siehe Abb. A.18).

Abb. A.15: Auflistung der Tabellen eines Projekts

Zusätzlich besteht auf dieser HTML-Seite die Möglichkeit, sich eine Übersicht von anderen Projekten anzeigen zu lassen, die ebenfalls Daten in der WADABA besitzen. Per Mausklick kann sich der Benutzer den Inhalt einer Projekttabelle anzeigen lassen (siehe Abb. A.16). Besitzt die Tabelle mehr als 500 Zeilen, so kann der Benutzer sich den Inhalt der Tabelle durch Drücken des DOWNLOAD-Buttons auf seinen lokalen Rechner laden und in seinem Dateisystem speichern. Einzelne Spaltenbeschreibungen einer Tabelle können durch Mausklick abgerufen werden (siehe Abb. A.17). Auf dieser HTML-Seite besteht für den SQL-erfahrenen Benutzer außerdem die Möglichkeit zur Eingabe von selbstdefinierten SQL-SELECT-Statements.

Abb. A.16 : Inhalt einer Projekttabelle

         Abb. A:17: Beschreibung einer Tabellenspalte

            Abb. A.18: Beschreibung aller Spalten einer Projekttabelle