Louis Perrochon

Gateways in globalen Informationssystemen

Diss. ETH Nr. 11708

Gateways in globalen Informationssystemen

ABHANDLUNG
zur Erlangung des Titels

DOKTOR DER TECHNISCHEN WISSENSCHAFTEN
der
EIDGENÖSSISCHEN TECHNISCHEN HOCHSCHULE ZÜRICH

vorgelegt von

Louis Perrochon
Dipl. Informatik-Ingenieur ETH

Angenommen auf Antrag von

Prof. Dr. C. A. Zehnder, Referent
Prof. Dr. M. Norrie, Korreferentin

1996

Abhandlung zur Erlangung des Titels eines Doktors
der Technischen Wissenschaften der Eidgenössischen
Technischen Hochschule (ETH) Zürich.

Diss. ETH Nr. 11708

Prof. Dr. C. A. Zehnder, Referent
Prof. Dr. M. Norrie, Korreferentin

©1996, Louis Perrochon

VORWORT


Die vorliegende Arbeit entstand aus einer Reihe von Teilprojekten unter der Leitung von Prof. C. A. Zehnder im Rahmen der Forschungsgruppe "Entwicklung und Anwendungen" im Institut für Informationssysteme des Departements Informatik der ETH Zürich. Das Gesamtprojekt begann 1992 unter dem Arbeitstitel "Unified Use of Heterogeneous Information Systems".

Dabei wuchs die Erkenntnis, dass Schnittstellen, und damit IS-Gateways, eine der wichtigsten Grundlagen für die Beherrschung der immer komplexer werdenden Welt der Informationssysteme sind. Die vorliegende Arbeit ist die Umsetzung dieser Erkenntnis. Mit dem Fortschreiten dieser Arbeit ist eine interessante Verlagerung des Schwerpunktes innerhalb der Forschungsgruppe von Prof. C. A. Zehnder zu beobachten. Standen früher Entwurf und Entwicklung eines Informationssystems im Mittelpunkt der Lehr- und Forschungstätigkeit, so sind unterdessen die Zusammenhänge zwischen mehreren Informationssystemen in den Vordergrund gerückt. Die vorliegende Arbeit beschäftigt sich mit dauernd gleichzeitig betriebenen, heterogenen und autonomen Informationssystemen.

Namentlich danken möchte ich an dieser Stelle Prof. C. A. Zehnder, dessen Hinweise zur klaren Begriffsbildung und dessen grosszügige Unterstützung das Gelingen dieser Arbeit erst ermöglichten. Frau Prof. M. Norrie danke ich für die Übernahme des Korreferats, Prof. J. Gutknecht für die Anmerkungen zur Sprache IDLE. R. Fischer, D. Müller und M. Zollinger leisteten im Rahmen von Studienarbeiten und Diskussionsgruppen substantielle Beiträge.

ZUSAMMENFASSUNG


Mit der Verfügbarkeit von immer leistungsfähigeren und billigeren weltweiten Datennetzen entsteht eine stark wachsende Nachfrage nach integrierter Nutzung der durch diese Datennetze erschliessbaren Informationsquellen. Eine solche integrierte Nutzung von beliebig vielen, beliebig heterogenen Teilsystemen wird durch globale Informationssysteme ermöglicht. Globale Informationssysteme stellen hohe, aber spezifische Anforderungen an die Einbindung von Teilsystemen. So müssen die Teilsysteme beispielsweise mit anderen zusammenarbeiten können, ohne speziell darauf vorbereitet zu sein.

Die bisherigen Ansätze zur Integration von Datenbanken, etwa die Bildung von verteilten, föderierten oder Multidatenbanken, eignen sich nicht für globale Informationssysteme. Erstens gehen sie von Datenbanken als Teilsystemen aus und stellen somit hohe Anforderungen an die einzubindenden Teilsysteme. Zweitens versuchen sie, die Einbindung mit einer Perfektion zu erreichen, die oft weder nötig noch erwünscht ist. Sie verlangen im wesentlichen, dass sich die Teilsysteme mehr oder weniger einem globalen Ziel unterordnen.

Diese Arbeit zeigt einen anderen Weg. Die einzubindenden Teilsysteme bleiben unverändert funktionsfähig, der Zugang zu den daraus erhältlichen Informationen erfolgt über geeignete Zwischenelemente, sogenannte Gateways. Dabei lassen sich Gateways für bestimmte Typen von Informationssystemen systematisch bereitstellen. Mit diesem Ansatz gelingt es, auf heterogene, bestehende Informationssysteme ohne Änderung derselben in einer neuen, integrierten Art zuzugreifen. Im Vordergrund steht dabei der Lesezugriff. Für Mutationen bleiben die einzelnen Teilsysteme zuständig.

Um Strukturen in globalen Informationssystemen beschreiben zu können, wird die grafische Notation "SGIS" eingeführt. SGIS erlaubt eine einfache Darstellung statischer Konfigurationen und dynamischer Abläufe innerhalb dieser Konfigurationen.

Ein theoretischer Teil über Gateways zwischen Informationssystemen (sogenannte IS-Gateways) schlägt neben einer allgemeinen Klassifikation auch eine Referenzarchitektur für IS-Gateways vor. Die Klassifikation erlaubt das einfache Einschätzen einer konkreten Situation sowie Rückschlüsse auf geeignete Lösungsansätze. Die Referenzarchitektur beschreibt ein IS-Gateway durch dessen Elemente, die Schnittstellen dazwischen und das Zusammenwirken der Elemente.

Als Hilfsmittel für die schnelle Realisation von IS-Gateways wird die Schnittstellenbeschreibungssprache IDLE vorgestellt. Mit IDLE lassen sich auch Benutzerschnittstellen effizient formal beschreiben, so dass anstelle des Endbenutzers ein Programm diese benutzen kann. Dies erlaubt anderen Programmen den Zugriff auf bestehende Informationssysteme über die Benutzerschnittstelle.

In einem praktischen Teil werden anhand von fünf realisierten IS-Gateways die theoretischen Konzepte verdeutlicht und umgesetzt.

Den Abschluss der Arbeit bilden konkrete Hinweise für die effiziente Entwicklung von IS-Gateways.

ABSTRACT


The introduction of faster and cheaper global data networks has resulted in a significant growth in demand for integrated access to new and existing information sources. A Global Information System allows integrated access to any number of such information sources independent of the degree of heterogeneity of the associated subsystems. However, Global Information Systems do place integration demands on these subsystems in that they require them, for example, to be able to cooperate even if not designed for this purpose.

Previous approaches for database integration such as those adopted for distributed, federated and multi-database systems are not feasible for Global Information Systems. These approaches assume the subsystems to be database management systems and, further, expect that they conform to some form of global goal in order to be integrated. They do not scale up to such large, evolving networks with high-levels of heterogeneity in terms of the essential nature of the information sources.

This thesis presents a different approach based on the integration of subsystems by means of gateways. A gateway is a program which allows global access to data stored in a subsystem without requiring changes to that subsystem. The subsystem continues to operate normally and remains responsible for updates to local data while the gateways enable data to be retrieved by any users and applications of the global network.

We introduce a graphical language, SGIS, for describing the general architecture, configurations and components of Global Information Systems. The language SGIS supports the description of both the structure and dynamic interactions of such systems.

Gateways between information systems (IS-gateways) are discussed in detail and we propose both a reference architecture and a classification scheme. The reference architecture describes an IS-gateway in terms of its elements, the interfaces and the interoperation of the elements. The classification scheme can be used to identify integration situations associated with one or more subsystems and select appropriate gateway solutions.

To support the development of individual IS-gateways, we have developed an Interface Description Language, IDLE. The IDLE language facilitates the formal description of user interfaces to subsystems, thereby allowing a gateway program to access a subsystem in a manner similar to local users.

The thesis describes five different IS-gateways which were developed to validate the concepts developed in this work. We also present general guidelines for the efficient development of IS-gateways.

INHALT


              Vorwort 3Zusammenfassung 4Abstract 61 Einleitung 121.1 Globale Nutzung von Mono-Informationssystemen 121.2 Ein alltägliches Problem 131.3 Problemstellung und Zielsetzung der Arbeit 151.4 Übersicht über die Praxisbeispiele 171.5 Gliederung der Arbeit 202 Ausgangslage 212.1 Grundlagen 212.1.1 Monoinformationssysteme 212.1.2 Client-Server-Architektur bei Mono-IS 232.1.3 Globale Informationssysteme 242.1.4 Verallgemeinerung der Client-Server-Architektur 252.1.5 SGIS - Strukturbeschreibung globaler IS 292.1.6 Interaktionskonstrukte 302.1.7 Vielfalt in globalen Informationssystemen 322.2 IS-Gateways 362.3 Gründe für den IS-Gatewayeinsatz 392.3.1 Technische Inkompatibilitäten und andere Gründe 392.3.2 Kosten durch die Vielfalt der Benutzerschnittstellen 392.3.3 Softwarewartung 412.3.4 Migration von Informationssystemen 432.3.5 Alterung von Schnittstellen 442.3.6 Änderungen in der Informatikinfrastruktur 452.4 Grenzen von IS-Gateways 462.4.1 Effizienzeinbussen 462.4.2 Auch IS-Gateways müssen angepasst werden 462.5 Andere Ansätze mit Bedeutung für globale Informationssysteme 472.5.1 Kommunikation mit dem Server 472.5.2 Spezielle Datenbeschreibungssprachen 492.5.3 Referenzarchitekturen 492.5.4 Normen 502.5.5 Schemaintegration 522.5.6 Offenheit / Anpassungsfähigkeit 522.5.7 IS-Gateway-ähnliche Ansätze 532.5.8 Bewertung der bisherigen Arbeiten 542.6 Schlussfolgerungen aus Kapitel2 553 Theoretische Grundlagen von IS-Gateways 563.1 Einleitung 563.2 Grundlegende Klassifikationsmerkmale 573.2.1 Flexibilität IS-Gateways 573.2.2 Funktionalitätsumfang von Transformation und Vermittlung 583.3 Klassifikation nach IS-Gatewayfunktionalität 603.3.1 Synchronisationsvermittlung 603.3.2 Zustandsvermittlung 633.3.3 Befehlsvermittlung 663.3.4 Datenstrukturtransformation 663.3.5 Realisation von zusätzlicher Funktionalität 673.3.6 Sicherheit 683.3.7 Zwischenspeicherung 693.4 Klassifikation nach Entwurfsvarianten 703.4.1 Zustandsorientierung im IS-Gateway 703.4.2 Beständigkeit von IS-Gateways 713.4.3 VerwendeteServerschnittstelle 723.5 Die Rolle der Semantik in IS-Gateways 743.6 Komponenten eines IS-Gateways 753.6.1 Die IS-Gateway Referenzarchitektur 753.6.2 Das Zustandsdiagramm eines IS-Gateways 783.7 Multigateways 803.8 Schlussfolgerungen aus Kapitel3 834 Die Sprache IDLE 854.1 Zweck 854.2 IDLE-Konzepte 864.2.1 Kapselung der Kommunikation mit Client und Server 864.2.2 Phasen 874.2.3 Variablen 894.3 Syntax von IDLE 924.4 Semantische Bedeutung der IDLE-Befehle 944.4.1 Kontrollstrukturen 944.4.2 Umgang mit Streams 964.4.3 Kommunikation mit dem Clienten 974.4.4 Fehlerbehandlung 1004.4.5 Verschiedenes 1015 Praxisbeispiele 1025.1 Umfeld der Praxisbeispiele, W3 1025.1.1 W3 als globales Informationssystem 1025.1.2 Client-Server-Architektur 1035.1.3 Datenbeschreibungen in W3 1045.1.4 Gateways in W3 1045.1.5 Java 1065.2 TS/IDLE: Einbindung von Mono-IS in W3 1065.2.1 Zweck 1065.2.2 Umsetzerrolle des Translation Servers (TS) 1065.2.3 Konzepte 1075.2.4 Klassifikation 1095.2.5 Resultate 1105.3 LibAgent: integrierter Zugriff auf IS 1135.3.1 Zweck 1135.3.2 Konzept 1145.3.3 Realisation 1145.3.4 Klassifikation 1165.3.5 Resultate 1175.4 StD: Server für tabellarische Daten 1185.4.1 Zweck 1185.4.2 Konzept 1185.4.3 Realisation 1195.4.4 Klassifikation 1235.4.5 Resultate 1235.5 PubDINIS: öffentlicher W3-Kiosk 1245.5.1 Zweck 1245.5.2 Konzept 1255.5.3 Realisation 1265.5.4 Klassifikation 1275.5.5 Resultate 1275.6 WAB: W3-Zugriff für Blinde 1285.6.1 Zweck 1285.6.2 Konzept 1295.6.3 Realisation 1305.6.4 Klassifikation 1315.6.5 Resultate 1316 Hinweise für den Praxiseinsatz 1336.1 Eingliederung in das Unternehmensumfeld 1336.2 Entwurfsschritte 1336.2.1 Projektumriss 1346.2.2 Konzept (mit Varianten) 1356.2.3 Realisation 1376.2.4 Systemtest 1386.2.5 Einführung und Betrieb 1386.3 Schlussfolgerungen aus Kapitel6 1387 Schlussbemerkungen 1397.1 Resultate 1397.2 Schlussfolgerungen aus dieser Arbeit 1407.3 Ausblick auf zukünftige Entwicklungen 1417.3.1 Einbezug der Semantik 1417.3.2 Weitere Kommunikationsarten 142Anhänge 143Anhang A: SGIS Referenz 144Anhang B: Ein Beispiel für ein IDLE-Programm: svi.idle 146Literaturverzeichnis 149

Um eine gute Leserlichkeit zu bewahren, steht bei Personenbezeichnungen die männliche Form für die Gesamtheit.

1 EINLEITUNG


1.1 Globale Nutzung von Mono-Informationssystemen

Mit der weltweiten Nutzung offener Datennetze verändert sich die Architektur von computergestützten Informationssystemen (IS) grundlegend. Bisher stand das einzelne IS, im folgenden Mono-IS genannt, und dessen interner Aufbau aus verschiedenen IS-Komponenten wie Hardware, Betriebssystem, Datenverwaltungssystem und Anwendungsprogrammen im Vordergrund. In Zukunft wird ein neues, globales IS vermehrt aus kompletten, bestehenden, heterogenen Mono-IS kombiniert. Diese Teilsysteme bleiben im allgemeinen - trotz ihrer Einbindung in ein globales IS - weiterhin selbständig in Betrieb; vor allem wird ihr Datenbestand normalerweise lokal nachgeführt. Die Nutzung der Daten ist aber zusätzlich global möglich, in Zusammenarbeit mit anderen Informationssystemen.

Diese Zusammenarbeit spielt sich in einem beliebig grossen Rahmen ab: Die Anzahl zusammenarbeitender Teilsysteme kann weltweit in die Tausende gehen. Diese Zusammenarbeit verlangt nach klar definierten, möglichst normierten Schnittstellen. Dazu zwei Beispiele aus verwandten Bereichen:

Im Software Engineering werden in modulorientierten Programmiersprachen sämtliche Kontakte zwischen verschiedenen Programmodulen (Aufruf, Parameter) in geeigneten Schnittstellen vollständig beschrieben.

In der Telekommunikation, die sich gezwungenermassen mit verschiedenen Teilsystemen befasst, ist die Bedeutung von Kommunikationsschnittstellen besonders gross.

Bei der globalen Nutzung von bestehenden Mono-IS lassen sich die notwendigen Schnittstellen nicht beliebig definieren. Im Normalfall setzt jedes beteiligte Informationssystem enge Rahmenbedingungen für die Schnittstellen. Diese Rahmenbedingungen führen meist nicht nur zur Definition einer Schnittstelle zwischen zwei Teilsystemen, sondern zu zwei: je eine für jedes der benachbarten Teilsysteme. Verbleibende Differenzen zwischen den beiden Schnittstellen müssen durch ein Gateway überbrückt werden.

Der Begriff Gateway ist nicht neu. In der Telekommunikation werden Netz-Gateways eingesetzt, um zwischen ansonsten inkompatiblen Netzprotokollen zu vermitteln.

In dieser Arbeit geht es um Gateways zwischen miteinander inkompatiblen Informationssystemen, IS-Gateways genannt. Ein IS-Gateway ist jedoch mehr als eine blosse Abbildung einer Schnittstellendefinitionen auf eine andere, es bietet erweiterte Funktionalität: Kommunikationsbarrieren werden überschritten und Daten werden aktiv in der Struktur transformiert. Diese Erweiterung findet sich in den verschiedensten Typen von IS-Gateways. Für die Kommunikationsvermittlung im IS-Gateway ist Wissen über die Zugriffsprotokolle der Teilsysteme verlangt, für die Datentransformation Wissen darüber, wo und wie Information zugänglich ist und wie die Daten strukturiert sind.

1.2 Ein alltägliches Problem

Das folgende Beispiel gibt eine anschauliche Einführung in die Problematik.

Bsp.: Verkaufsleiterin Melanie Müller möchte gerne von ihrem persönlichen Computer (PC) aus auf die Verkaufszahlen der letzten drei Monate zugreifen, um diese Zahlen mit Excel zu bearbeiten. Die interessierenden Verkaufszahlen sind in einem Mono-IS auf einem Grossrechner verfügbar. Bisher hat Frau Müller jeweils monatlich Auszüge auf Papier erhalten, auf spezielle Anfrage manchmal auch häufiger. Diese Daten liegen jedoch nicht in Form von Excel-Dateien vor. Auf die Daten des Mono-IS kann nur indirekt über ein Anwendungsprogramm zugegriffen werden und nicht direkt auf Dateien oder über ein Datenverwaltungssystem.



Bild 1.1 Frau Müllers Situation: Problem1.1 Frau Müllers Situation Problem

Zur Lösung dieses Problems bietet die Praxis mehrere Lösungsansätze an, die aber meist rasch an Grenzen stossen. So kann Excel über die Normschnittstelle ODBC (Open Database Connectivity) auf bestimmte Datenverwaltungssysteme zugreifen. Das hier eingesetzte Datenverwaltungssystem ist jedoch nicht ODBC-kompatibel. Frau Müllers Versuche sind daher trotz Einsatz einer Normschnittstelle vorläufig nicht von Erfolg gekrönt.

Die Informatikabteilung kann nun ein Hilfsprogramm, eben ein IS-Gateway, installieren, das auf das verwendete Mono-IS zugreift und anschliessend die gewünschten Daten dem Excel-Programm zur Verfügung stellt (Bild 1.2).



Bild 1.2 Frau Müllers Situation: Lösungsansatz1.2 Frau Müllers Situation Lösungsansatz

Dieses Gateway wird drei wichtige Komponenten haben: Eine ODBC-kompatible Komponente wird mit Excel kommunizieren, eine weitere Komponente wird mit dem Mono-IS kommunizieren. Die dritte Komponente wird die notwendigen Transformationen vornehmen. Die Kommunikationsvermittlung wird dabei zwischen der ODBC-Komponente und der Komponenten für den Zugriff auf das Mono-iS vermitteln. Im konkreten Beispiel wird die Datentransformation die vom Mono-IS über die Benutzerschnittstelle erhaltenen Daten in relationale Tabellen umformen.

Falls kein geeignetes IS-Gateway bereits verfügbar ist, muss die Informatikabteilung in umständlicher Kleinarbeit ein eigenes Hilfsprogramm entwickeln.

IS-Gateways werden offensichtlich häufig benötigt, allzu oft aber als Einmallösung verstanden und daher mehr oder weniger "billig" zusammengeflickt. Die Frage stellt sich nun, wie solche IS-Gateways systematisch realisiert werden können.

1.3 Problemstellung und Zielsetzung der Arbeit

Zur korrekten und effizienten Bereitstellung von IS-Gateways ist strukturiertes und formales Wissen über deren Entwicklung und Anwendung nötig. Dieses Wissen fehlt heute weitgehend sowohl in der Praxis als auch in der Forschung und Lehre. Diese Arbeit befasst sich deshalb mit der formalen Beschreibung, dem Entwurf, der Entwicklung und dem Einsatz von IS-Gateways. Es geht dabei nicht um die Neuentwicklung einer universalen Gatewaytheorie. Hingegen sollen ausgewählte und in Forschung und Praxis eingesetzte Ansätze analysiert, präzisiert, in wichtigen Bereichen erweitert und für den möglichst effizienten Einsatz beim Entwurf von IS-Gateways in der Praxis aufbereitet werden.

Im Zentrum dieser Arbeit stehen die Kommunikationsvermittlung und die Datentransformation. Bei der Kommunikationsvermittlung steht die Überbrückung von Heterogenität der Kommunikation im Vordergrund. Diese Heterogenität äussert sich durch asynchrone bzw. synchrone Kommunikation oder durch unterschiedliche Zustände der beteiligten Teilsysteme. Die Datentransformation betrifft allenfalls notwendige Veränderungen an der Datenstruktur. Nicht im Vordergrund stehen die Aspekte der Sicherheit. Auch Probleme wie verteilte Transaktionen oder Schemaintegration, wie sie bei Multidatenbanken auftreten, stehen hier eher im Hintergrund.

Folgende Fragen sind somit zu klären: Welche Methoden und Werkzeuge sind zu verwenden, um bestehende und neue Informationssysteme mit kleinstem Aufwand, möglichst ohne Änderungen an den bestehenden Systemen und ohne Eingriffe in die Autonomie der einzelnen Systembetreiber in ein neues, umfassendes Gesamtsystem einzubinden?

Die folgenden drei Hypothesen werden in dieser Arbeit überprüft:

1. Zur globalen Integration von Informationssystemen reicht die Definition präziser Schnittstellen alleine nicht aus. Im allgemeinen Falle sind zusätzliche Programme (IS-Gateways) notwendig, um die Lücken zu schliessen.

2. Durch den Einsatz von IS-Gateways ist prinzipiell jedes Informationssystem in ein globales Informationssystem integrierbar.

3. Bereits die Berücksichtigung einiger weniger systematischer Kriterien kann den Entwurf, die Entwicklung und den Einsatz von IS-Gateways stark erleichtern.

Im Ausbildungsbereich und auch in der Praxis herrscht oft die Meinung vor, zur Integration von Informationssystemen genüge die geeignete Definition von Schnittstellen. Die erste Hypothese widerspricht dieser landläufigen Meinung. Die zweite Hypothese postuliert, dass IS-Gateways eine der wichtigsten Grundlagen für die Beherrschung der immer komplexer werdenden Welt der Informationssysteme bilden. Trotzdem spielen IS-Gateways im wachsenden Forschungsgebiet der globalen IS eine bisher vernachlässigte Rolle. Auch existiert bis heute kaum eine Systematik im Zusammenhang mit IS-Gateways. Dies erschwert die entsprechende Ausbildung von Informatikern. Da diese Ausbildung, aber auch die Realisierung guter IS-Gateways aufgrund der beiden ersten Hypothesen durchaus erwünscht ist, sind formale Ansätze und Richtlinien gesucht. Die dritte Hypothese postuliert deren Existenz.

Die vorliegende Arbeit dokumentiert mehrere, teilweise überlappende Entwicklungsphasen auf dem Weg zu einer systematischeren Sicht von IS-Gateways. In einer ersten Phase standen systematisches und kritisches Literaturstudium und die Analyse von bestehenden IS-Gateways und von Produkten mit ähnlicher Funktionalität im Zentrum. Durch den konkreten Entwurf, die Realisation und die Evaluation von verschiedenen IS-Gateways wurden in einer zweiten Phase eigene Erfahrungen für die systematische Darstellung und die Entwicklung einer Entwurfsmethodik gesammelt. Fünf solche IS-Gateways sind in Kapitel 5 zusammengestellt. Das Resultat der Arbeit sind einerseits eine allgemeine Klassifikation und Architektur für IS-Gateways, andererseits auch Vorschläge zur Methodik bei der Entwicklung konkreter IS-Gateways. Die Arbeit ist somit ein Beitrag zur Realisation von globalen IS.

1.4 Übersicht über die Praxisbeispiele

Internet und das darauf basierende World Wide Web (W3) bilden heute eine flexible und praktisch nutzbare Grundlage für den Aufbau globaler IS. Es ist daher naheliegend, dass diese Grundlage für alle fünf im Rahmen dieser Arbeit realisierten IS-Gateways benützt wurde. Mit drei der fünf IS-Gateways werden bestehende Mono-IS neu in W3 eingebunden, mit den anderen zwei wird W3 für spezielle Gruppen von Endbenutzern in einer neuen Form zugänglich gemacht. Die meisten Überlegungen, die zu IS-Gateways entwickelt werden, beschränken sich aber nicht auf die W3-Welt.

W3 wurde aber auch als Studienobjekt gewählt, weil es einige sehr interessante Eigenschaften hat. Einerseits verschwinden im Rahmen von W3 die Unterschiede zwischen den heute noch häufig stark unterschiedlich behandelten Arten von Informationssystemen: Datenbanken, Information-Retrieval-Systeme, Experten- oder Wissensbasierte Systeme etc. Entscheidend sind damit nicht mehr die Unterschiede, sondern die Gemeinsamkeiten. Andererseits ist W3 ein Vorläufer jenes globalen IS, von dem in der Informatik (und in der Science Fiction) schon seit langer Zeit die Rede ist [Bush 45], [Engelbart 62].

Bild 1.3 gibt einen Überblick über das Umfeld der im Rahmen dieser Arbeit realisierten Praxisbeispiele. Im unteren Teil des Bildes sind zwei bestehende, Mono-IS aufgeführt: ETHICS und SVI-Kurs:

ETHICS ist ein seit 1980 entwickeltes, umfassendes Bibliothekssystem für grosse Bibliotheken, namentlich für die ETH-Bibliothek und die Zentralbibliothek Zürich. Es unterstützt die interaktive Katalogabfrage, die damit gekoppelte Ausleihe sowie weitere Funktionen. Der Zugriff auf ETHICS geschieht heute noch ausschliesslich über eine rein textbasierte Benutzerschnittstelle.

SVI-Kurs ist ein Kleinsystem im produktiven Betrieb; es enthält Angaben über Veranstaltungen der schweizerischen Informatikfachverbände. Dank einfacher Datenstruktur und kleinem Datenbestand eignete sich SVI-Kurs gut für verschiedene Experimente, die praktisch alle zu konkreten Verbesserungen führten.



Bild 1.3 Realisierte IS-Gateways 1.3 Realisierte IS-Gateways

Im oberen Teil von Bild 1.3 sind zwei spezielle Gruppen von W3-Endbenutzern aufgeführt: blinde Endbenutzer und Benutzer eines elektronischen Kiosks:

Blinde Endbenutzer haben Mühe mit dem grafisch orientierten W3. Sie haben spezielle Anforderungen an die Präsentation von Informationen.

Die Benutzer eines elektronischen Kiosks sollen mit einfachsten Mitteln, etwa mit einem berührungsempfindlichen Bildschirm und ohne Tastatur, auf W3 zugreifen können.

Die fünf Ovale in Bild 1.3 zeigen die fünf im Rahmen dieser Arbeit realisierten Praxisbeispiele.

Praxisbeispiele 1 und 2: TS/IDLE und LibAgent

Das Praxisbeispiel 1, TS/IDLE, ist ein Prototyp eines generischen IS-Gateways für den individuellen Zugriff für W3-Endbenutzer auf Mono-IS. Der Zugriff geschieht über deren Benutzerschnittstelle. Der Translation Server (TS) interpretiert dabei in IDLE (Interface Description LanguagE) geschriebene Beschreibungen der Benutzerschnittstelle. Als wichtigstes Demonstrationsobjekt dient die Beschreibung der Benutzerschnittstelle von ETHICS. Auch ein monolithisches Mono-IS, das ausser der Benutzerschnittstelle keine weiteren Schnittstellen anbietet, kann dadurch eingebunden werden. Mit TS/IDLE geschieht diese Einbindung auf generische Art.

Das Praxisbeispiel 2, LibAgent, nimmt Ideen aus TS/IDLE auf: Einerseits sollten erkannte Mängel des Translation Servers von TS/IDLE behoben werden, andererseits lag das Schwergewicht beim integrierenden Zugriff auf mehrere Teilsysteme. LibAgent dient vor allem als Illustration eines Multigateways, wie es in Abschnitt 3.7 beschrieben wird. LibAgent erlaubt dem W3-Endbenutzer das gleichzeitige Suchen von Information in mehreren Teilsystemen.

Praxisbeispiel 3: StD

Das Praxisbeispiel 3, StD, ist ein IS-Gateway für den Zugriff auf tabellarische Daten, das anstelle des Zugriffs über die Benutzerschnittstelle den direkten Zugriff auf die Daten in den Vordergrund stellt. Es wurde dazu ein generischer Mechanismus realisiert, der auf beliebige relationale Tabellen zugreifen kann. Dieses IS-Gateway soll zeigen, dass der direkte Zugriff auf Daten vieles vereinfacht. Trotzdem treten dabei immer noch verschiedene Probleme mit inkompatiblen Schnittstellen auf. Mit dem realisierten Prototyp von StD wurde das bestehende Mono-IS SVI-Kurs erfolgreich in W3 eingebunden und ein Jahr lang betrieben.

Praxisbeispiele 4 und 5: PubDINIS und WAB

Mit dem Praxisbeispiel 4, PubDINIS soll ein einfacher Auskunftsdienst (elektronischer Kiosk) unter Verwendung von auf W3 existierenden Informationsangeboten realisiert werden. Die Besonderheit liegt hier darin, dass die Endbenutzer nur einen berührungsempfindlichen Bildschirm und keine Maus oder Tastatur zur Verfügung haben. Die deshalb notwendigen Anpassungen an den Daten werden durch ein spezielles IS-Gateway realisiert.

Das Praxisbeispiel 5, WAB, (World Wide Web Access for Blind and Visually Impaired Computer Users) ist ebenfalls ein sehr spezielles IS-Gateway; es basiert technisch und methodisch auf Erfahrungen mit dem IS-Gateway von PubDINIS. Das Zielpublikum sind bei WAB blinde Computerbenutzer mit ihren speziellen Anforderungen an die Präsentation von Information.

1.5 Gliederung der Arbeit

Kapitel 2 definiert einige Begriffe und führt die grafische Notation SGIS zur Beschreibung von globalen IS ein. SGIS erlaubt die Darstellung statischer Konfigurationen und dynamischer Abläufe innerhalb dieser Konfigurationen. Im weiteren werden Gründe für den Einsatz von IS-Gateways im allgemeinen diskutiert. Kapitel 2 enthält ausserdem einen Überblick über die bisherigen Ansätze zur Einbindung von Teilsystemen in globale IS und zeigt deren Schwachstellen und Stärken auf.

Kapitel 3 erarbeitet theoretische Grundlagen für den Einsatz von IS-Gateways. Dabei wird versucht, bestehende theoretische Grundgerüste soweit möglich einzubeziehen um eine Klassifikation von verschiedenen IS-Gateways und eine Referenzarchitektur aufzubauen.

Kapitel 4 präsentiert die Schnittstellenbeschreibungssprache IDLE. Sie dient als Hilfsmittel für die schnelle Realisation von IS-Gateways. Mit IDLE lassen sich auch Benutzerschnittstellen effizient formal beschreiben, so dass anstelle des Endbenutzers ein Programm diese benutzen kann. Dies erlaubt anderen Programmen den Zugriff auf bestehende Informationssysteme über die Benutzerschnittstelle. Neben den grundlegenden Konzepten wird auch die Syntax und Semantik der Sprache beschrieben.

Kapitel 5 diskutiert die fünf Praxisbeispiele. Dabei wird versucht, die theoretischen Konzepte praxisnah aufzuarbeiten.

In Kapitel 6 folgen auf dieser Grundlage konkrete Hinweise für den Praxiseinsatz.

Kapitel 7 fasst die Resultate der Arbeit zusammen, bewertet sie kritisch und gibt einen Ausblick auf zukünftige Entwicklungen.

2 AUSGANGSLAGE


2.1 Grundlagen

In diesem Abschnitt wird, ausgehend vom selbständigen Mono-IS, ein Modell eines globalen IS aufgebaut.

2.1.1 Monoinformationssysteme

Als erstes werden in diesem Unterabschnitt einige Begriffe definiert. Information ist die "Antwort auf eine konkrete Frage", Daten sind gespeicherte Angaben. Informationen können oft aus geeigneten Daten hergeleitet werden.

Def.: Ein Informationssystem ist ein System, das dem Endbenutzer auf Anfrage Informationen bereitstellt.

Ein Informationssystem dient dem Endbenutzer zur Beantwortung von Fragen aufgrund der darin gespeicherten Daten. Diese Arbeit beschränkt sich dabei auf computergestützte Informationssysteme.

Def.: Ein Mono-IS ist ein Informationssysteme, das gezielt für die Lösung eines einzigen Problembereichs entworfen und entwickelt worden ist.

Mono-IS zeichnen sich durch folgende Eigenschaften aus:

Sämtliche Teile eines Mono-IS sind aufeinander abgestimmt.

Ein Mono-IS ist logisch kompakt, sämtliche Teile folgen einem zentralen Entwurf.

Ein Mono-IS ist auf den Problembereich beschränkt, für den es entworfen wurde.

Ein Mono-IS kann nur mit beträchtlichem Aufwand in seiner Funktionalität erweitert werden.

Die von Datenbanken bekannte Unterteilung (gemäss Bild 2.1) in Datenbestand, Datenverwaltungssystem und Anwendungsprogramme lässt sich auf Mono-IS verallgemeinern.



Bild 2.1 Aufbau eines Mono-IS2.1 Aufbau eines Mono-IS

Als unterste Schicht in einem Mono-IS existiert ein dauerhaft vorhandener Datenbestand. Die Beschreibung des Datenbestandes heisst Datenschema oder kurz Schema. Auf dem Datenbestand operiert ein Datenverwaltungssystem, das unter anderem Konsistenzsicherung, langfristige Verfügbarkeit, Deduktion etc. anbieten kann. Die oberste Schicht sind die Anwendungsprogramme, die typischerweise anwendungsbezogene Funktionalität zur Verfügung stellen.

Wichtig sind die durch die drei Schichten definierten Schnittstellen, einerseits die schon erwähnte Datenschnittstelle direkt auf die Daten, dann eine Systemschnittstelle zum Datenverwaltungssystem und die Benutzerschnittstelle. Je nach Art des Informationssystems sind nur einzelne dieser Schnittstellen explizit sichtbar.

Bsp.: Die Verkaufszahlen im Beispiel aus Abschnitt 1.2 sind in einem Mono-IS gespeichert, auf das nur über ein Anwendungsprogramm zugegriffen werden kann. Datenverwaltungssystem und Anwendungsprogramm bilden für den Anwender einen nicht weiter aufgegliederten Block; die Daten werden durch das Datenverwaltungssystem in optimierter Form so gespeichert, dass nicht direkt darauf zugegriffen werden kann.

2.1.2 Client-Server-Architektur bei Mono-IS

Bei den frühen Mono-IS waren sämtliche Schichten auf einem einzigen Computer integriert. Mehrplatzlösungen wurden als sogenannte Terminallösungen realisiert: Auf ein Mono-IS auf einem Grosscomputer wird von verschiedenen Terminals aus gleichzeitig zugegriffen; der Grosscomputer steuert dabei die gesamte Benutzerschnittstelle auf dem Terminal.

In den letzten Jahren wurden die Terminals nach und nach durch leistungsfähigere Kleincomputer ersetzt, welche namentlich die lokale Datenpräsentation selbständig besorgen. Diese Architektur wird als Client-Server-Architektur bezeichnet. Selbständige Programme auf dem Benutzercomputer übernehmen die Aufgaben der Benutzerschnittstelle und Datenpräsentation und greifen als Kunden (Clienten) auf den Grossrechner zu. Mindestens der Datenbestand und Teile des Datenverwaltungssystem bleiben auf dem zentralen (Gross­)Rechner. Letzteres übernimmt die Aufgabe des Servers.

Die Funktionalität des Datenverwaltungssystems und der Anwendungsprogramme wird je nach Aufgabe aufgeteilt. Bei stark integrierten Aufgaben werden die Anwendungsprogramme auf dem zentralen Rechner ausgeführt (server-lastig), bei kaum integrierten Lösungen vermehrt auf dem dezentralen Benutzerrechner (client-lastig). Bei stark client-lastigen Aufgaben bleibt auf dem Server oft nur noch ein Minimum an Funktionalität. Bild 2.2 zeigt vier mögliche Varianten dieser Aufgabenteilung auf. Für eine vertieftere Behandlung von Client-Server-Varianten bei Mono-IS sei auf [Niemann 95] verwiesen.



Bild 2.2 Varianten der Client-Server-Architektur bei Mono-IS2.2 Varianten der Client-Server-Architektur bei Mono-IS

2.1.3 Globale Informationssysteme

Def.: Ein globales Informationssystem ist ein System, das dem Endbenutzer auf Anfrage Informationen aus beliebig vielen, beliebig heterogenen Teilsystemen bereitstellt. Die einzelnen Teilsysteme müssen dazu nicht verändert werden.

Als Teilsysteme von globalen IS kommen komplette Mono-IS, Teile von Mono-IS sowie andere globale IS in Betracht. Da die Teilsysteme möglichst ohne Änderungen in ein globales IS eingebunden werden sollen, müssen bei vorerst inkompatiblen Teilsystemen Lösungen gefunden werden, um die Differenzen zu überbrücken.

Die bei den Mono-IS vorgestellte Unterteilung in Datenbestand, Datenverwaltungssystem und Anwendungsprogramme kann in zweierlei Hinsicht auf globale IS übertragen werden.

Einerseits kann das globale IS als ganzes in die oben erwähnten Komponenten gegliedert werden. Der Datenbestand ist dann verteilt auf die verschiedenen Teilsysteme. Sämtliche Programme der Teilsysteme (Datenverwaltungssystem und Anwenderprogramme) bilden das Datenverwaltungssystem des globalen IS. Die Rolle des Anwendungsprogramms übernimmt in globalen IS in vielen Fällen ein sogenannter Browser. Dieser kommuniziert mit dem Endbenutzer und übernimmt für diesen alle Aufgaben der Präsentation und der Koordination von Teilsystemen. Der Browser greift dabei auf die verschiedensten Teilsysteme zu.

Andererseits setzt sich das globale IS wiederum aus kompletten Mono-IS oder Teilen von Mono-IS zusammen. Innerhalb dieser Mono-IS besteht weiterhin die Unterteilung in Datenbestand, Datenverwaltungssystem und Anwendungsprogramme mit den dazwischenliegenden Schnittstellen.

Ein weiteres Charakteristikum unterscheidet globale Informationssysteme von Mono-IS: die Offenheit. Die Anzahl und Vielfalt der Teilsysteme sowie der Endbenutzer ist im allgemeinen nicht im voraus bekannt und kann beliebig gross werden. Grundsätzlich kann ein jederzeit ein zusätzliches Teilsystem in ein globales IS eingeführt werden. Dies kann zu sehr heterogenen globalen IS führen. Auch können einzelne Teilsysteme nicht immer oder nicht mehr verfügbar sein. Hinzufügen und Weglassen von Teilsystemen müssen während dem Betrieb des globalen IS geschehen. Mindestens die von den Änderungen nicht betroffenen Teile sollten dauernd ohne Unterbruch weiter funktionieren.

Bsp.: Bild 2.3 bietet ein Beispiel für ein (kleines) globales IS. Der Browser greift dabei auf drei Teilsysteme zu, im Bild 2.3 links auf ein Mono-IS, in der Mitte und rechts auf zwei Datenverwaltungssysteme. Das Datenverwaltungssystem rechts unten greift seinerseits für die Beantwortung der Browseranfrage auf ein weiteres Datenverwaltungssystem zu. Aufgrund der verschiedenartigen Schnittstellen ist der Zugriff nur in einem Fall problemlos möglich (Browser auf das System B). In den anderen Fällen müssen spezifische Lösungen gefunden werden.



Bild 2.3 Ein globales Informationssystem2.3 Ein globales Informationssystem

2.1.4 Verallgemeinerung der Client-Server-Architektur

Im Zusammenhang mit Client-Server-Architekturen bei Mono-IS wird der Begriff Client häufig als Synonym für Kleincomputer des Endbenutzers, der Begriff Server als Synonym für Gross- oder Abteilungscomputer verwendet. Technisch betrachtet sind jedoch Server und Client auch bei Mono-IS Programme und nicht Hardware. Die Aussage "Dieser Rechner ist unser Fileserver." ist eine Kurzform von "Auf diesem Rechner läuft unser Fileserver." Weil in dieser Arbeit vor allem die Funktionalität der verschiedenen Komponenten im Zentrum steht, sollen hier mit den Begriffen Client und Server die entsprechenden Programme bezeichnet werden. Die Aussage "Der Client greift auf den Server zu." ist somit eine Kurzform von "Ein Programm ‚Client' greift auf ein anderes Programm ‚Server' zu." Im folgenden wird auf die beiden Rollen eingegangen.

Programme, die als Server auftreten

Die eine Rolle in allgemeinen Client-Server-Architekturen ist diejenige des Server.

Def.: Der Begriff Server bezeichnet das nur als Partner auf Anruf aktive, zentrale Programm.

Server bieten typischerweise Dienste an, die von mehreren Programmen gemeinsam genutzt werden (z. B. das Drucken) oder die sehr anspruchsvoll sind (z. B. die langfristig stabile Datenhaltung).

Def.: Ein Dienst ist eine bestimmte Funktion oder Funktionspalette, die ein Programm anderen Programmen anbietet.

Die verschiedenen Kategorien von Programmen, die als Server in globalen IS auftreten, unterscheiden sich durch ihr Dienstangebot.

In Informationssystemen bilden Informationsquellen die weitaus wichtigste Serverkategorie .

Def.: Eine Informationsquelle (I-Quelle) ist ein Programm, das Daten speichert und anderen Programmen auf Anfrage zur Verfügung stellt.

Der Serverteil eines Mono-IS mit Client-Server-Architektur ist ein Beispiel für eine solche Informationsquelle. Ein weiteres ist ein Fileserver, d. h. ein Programm, das Daten in beliebig grossen Einheiten (Dateien oder Files) speichern und wieder bereitstellen kann.

Zu anderen Serverkategorien, auf die hier jedoch nicht weiter eingegangen wird, gehören etwa numerische Programme, die auf Anfragen von Clienten warten und im Bedarfsfalle Simulationen oder geometrische Berechnungen durchführen (z.B. [De Lorenzi 96]).

Tritt eine Informationsquelle als Server auf, wird sie oft auch als Informationsserver bezeichnet, um auf die Art des Dienstangebotes hinzuweisen.

Def.: Ein Informationsserver ist ein Server, der als Dienstleistung ausgewählte Daten anbietet.

Programme, die als Clienten auftreten

Die andere Rolle in allgemeinen Client-Server-Architekturen ist diejenige des Clienten.

Def.: Der Begriff Client bezeichnet das primär aktive Programm, das von einem anderen Programm - einem Server - einen Dienst anfordert.

In globalen Informationssystemen greifen Clienten vor allem auf Informationsserver zu. Die von einem Informationsserver gezielt bezogenen Daten werden durch den Clienten lokal entweder für die direkte Präsentation aufbereitet oder für eigene Operationen (Berechnungen, Analysen) verwendet.

In globalen IS treten verschiedene Kategorien von Programmen als Clienten auf. Sie unterscheiden sich durch die Art der Verwendung der erhaltenen Daten.

Die erste Kategorie von Clienten bilden die Browser, die in globalen IS eine derartige Bedeutung erhalten haben, dass oft kein Unterschied zwischen Client und Browser mehr gemacht wird.

Def.: Ein durch den Endbenutzer interaktiv gesteuertes Programm, das als Client bei Servern Daten bezieht und diese Daten für die Präsentation aufbereitet, heisst Browser.

Die Betonung liegt auf dem Begriff interaktiv. Er bedeutet, dass Browser primär für freie ad hoc Anfragen eingesetzt werden, im Gegensatz zu Anwendungsprogrammen, die meist spezialisierte, parametrisierte Anfragemöglichkeiten anbieten. In globalen IS treten Browser oft an die Stelle der Anwendungsprogramme in Mono-IS. Der Browser ist das einzige Programm des globalen IS, das der Endbenutzer direkt sieht.

Bsp.: Die wohl bekanntesten Beispiele eines Browsers sind die verschiedenen Programme, die verwendet werden, um auf W3 zuzugreifen: Netscape Navigator, Mosaic, Internet Explorer, etc.

Bsp.: Ein eher ungewohntes Beispiel eines Browsers ist das Tabellenkalkulationsprogramm Excel von Frau Müller (Abschnitt 1.2). Ungewohnt ist hier der Begriff "Browser", weil bisher eine Tabellenkalkulation wohl vor allem als eigenständige Anwendung eingesetzt wurde. Als Teil eines globalen IS kann sie aber durchaus als Client eingesetzt werden, der Daten von Informationsservern bezieht und diese darstellt. Excel kann daher in diesem Fall als Browser bezeichnet werden.

Eine zweite Kategorie von Clienten umfasst die sogenannten Agenten.

Def.: Ein Programm, das ohne direkten Benutzerauftrag selbständig mit Servern Kontakt aufnehmen und nach Informationen suchen kann, heisst Agent.

Beispiele dazu sind etwa Indexieragenten in globalen IS, Agenten für die Überwachung von Computersystemen oder Agenten für periodische Abfragen von laufend aktualisierten Messdaten.

Bsp.: Im Beispiel aus Abschnitt 1.2 wäre ein Agent denkbar, der jedesmal, wenn Frau Müller ihren PC einschaltet, selbständig die Verkaufszahlen aus dem Mono-IS bezieht, diese überprüft und Frau Müller beim Unterschreiten gewisser Werte benachrichtigt.

Eine dritte Kategorie von Clienten sind Programme, die in erster Linie als Server dienen, aber ihrerseits von einem weiteren Server einen Dienst anfordern und somit vorübergehend auch als Client auftreten können. So können insbesondere Informationsquellen auch als Clienten auf weitere Informationsquellen zugreifen.

Bsp.: Typische Beispiele finden sich bei Mono-IS in mehrstufigen Client-Server-Architekturen, wo ein erster Server für die Abwicklung von Geschäftsvorfällen zuständig ist und ein zweiter Server für die Datenhaltung. Der erste Server wird für die Datenhaltung die Dienste des zweiten Servers in Anspruch nehmen. Der Endbenutzer dagegen wird nur die Dienste des ersten Servers beanspruchen. Diese Architektur wird heute oft Three-Tier-Architecture genannt.

Bsp.: Ein anderes Beispiel ist das sog. Data Warehouse, wo Kopien von Daten aus operationellen Informationssystemen zusammengetragen werden. Diese Kopien werden in einem separaten Informationssystem, dem Data Warehouse, zwischengespeichert und dem Endbenutzer (z. B. Frau Müller im Beispiel in Abschnitt 1.2) in aussagekräftiger Form verfügbar gemacht. Während der Kommunikation mit den operationellen Informationssystemen handelt das Data Warehouse als Client, während der Kommunikation mit dem Browser als Server. Eine Übersicht über Data Warehouses gibt beispielsweise [Widom 95].

Eine Übersicht über weitere Programme mit Client­, Server­ oder wechselnden Rollen findet sich im I33-Projekt (Intelligent Integration of Information) [I3 95]. In dieser Arbeit wird für ein Programm, das die Rolle des Servers übernimmt, in der Regel eine allgemeine Informationsquelle als Beispiel verwendet. Als Client dient dann ein Browser. Diese Aussagen lassen sich auch auf die anderen Kategorien von Clienten oder Servern übertragen.

2.1.5 SGIS - Strukturbeschreibung globaler IS

In diesem Unterabschnitt wird zur einfachen Beschreibung komplexer Client-Server Architekturen die grafische Notation SGIS (Strukturbeschreibung globaler IS) eingeführt. Die Notation SGIS wird im Verlauf dieser Arbeit schrittweise entwickelt und erläutert. Eine Übersicht über die gesamte Notation ist im Anhang A zu finden.

In der grafischen Notation SGIS werden die beteiligten Programme durch Kästchen dargestellt und bei möglicher Zusammenarbeit mit einer Linie verbunden. In der statischen Darstellung (links in Bild 2.4) werden an den Endpunkten der Verbindungslinien ergänzende Angaben zur Schnittstelle, z. B. das verwendete Kommunikationsprotokoll oder das Datenformat, notiert. Die Indizes C und S stehen für die Rollen, welche die Programme bei der Zusammenarbeit übernehmen.




Bild 2.4 Einfache Client-Server-Architektur2.4 Einfache Client-Server-Architektur

Neben der statischen Struktur einer Client-Server-Architektur kann auch der dynamische Aspekt beschrieben werden.

Dynamische Aspekte werden in SGIS durch Kästchen für die Programme und Pfeile für die ausgetauschten Meldungen dargestellt (rechts in Bild 2.4). Der Client schickt eine Anfrage an den Server, dieser bearbeitet sie und schickt das Resultat zurück.


Mit dieser Notation können aber auch komplexere Situationen, etwa eine Three-Tier-Architecture in ihrem zeitlichen Ablauf dargestellt werden (Bild 2.5): Die I-Quelle A tritt dabei als Server wie auch als Client in Erscheinung. Die beiden Schnittstellen sind entsprechend gekennzeichnet.



Bild 2.5 Mehrstufige Client-Server-Architektur2.5 Mehrstufige Client-Server-Architektur

2.1.6 Interaktionskonstrukte

Die einfachste, einstufige Form einer Client-Server-Architektur (Bild 2.4) dient in der Folge als Konstrukt zur Beschreibung komplexer Client-Server-Architekturen.

Def.: Ein Interaktionskonstrukt beschreibt im wesentlichen zwei Programme, die Daten austauschen, für die Dauer dieser Zusammenarbeit. Dasjenige Programm, das Bedarf nach Datenaustausch äussert, übernimmt die Rolle des Clienten, das andere diejenige des Servers.

Wir werden zeigen, dass sich globale IS aus einer Vielzahl von einfachen Client-Server-Beziehungen zusammensetzen, die mit je einem Interaktionskonstrukt beschrieben werden. Durch die Reduktion von globalen IS auf einfache Interaktionskonstrukte werden erstere überschau­ und beschreibbar. Dieses Vorgehen erlaubt es, sämtliche Beziehungen und Vorgänge zwischen Komponenten vielteiliger Informationssysteme durch mehrfache Anwendung eines einfachen Konstrukts darzustellen. Ein Interaktionskonstrukt deckt dabei immer genau eine Interaktion ab. So kann zwar ein bestimmtes Programm gleichzeitig oder hintereinander in mehreren Interaktionskonstrukten aktiv sein, in einem bestimmten Interaktionskonstrukt sind jedoch genau ein Client und ein Server aktiv.

Eine Voraussetzung für die Interaktion innerhalb eines Interaktionskonstrukts sind übereinstimmende Schnittstellen von Client und Server. Nur eine direkte Eins-zu-eins-Übereinstimmung erlaubt eine problemlose Kommunikation und korrekten Datenaustausch. Alle anderen Fälle sind Untersuchungsgegenstand dieser Arbeit.

Die Kommunikation zwischen Client und Server geschieht durch Übertragung von Daten. In dieser Arbeit werden bezüglich dieser übertragenen Daten Steuerdaten, Metadaten und Nutzdaten unterschieden. Die Steuerdaten dienen der Kontrolle der Kommunikation, beispielsweise der gegenseitigen Identifikation von Client und Server sowie der Koordination und Synchronisation der Kommunikation. Die Metadaten enthalten die Beschreibung der Nutzdaten. Die Nutzdaten selber enthalten die Information, welche als Antwort auf eine konkrete Frage gesucht ist. Datenübertragung kann in beiden Richtungen stattfinden. Bei manchen Serverdienstleistungen wie etwa beim Drucken oder beim Speichern von Nutzdaten in einem Datenverwaltungssystem erfolgt die Nutzdatenübertragung vom Clienten zum Server. Bei anderen Dienstleistungen, namentlich beim Lesen aus einem Datenverwaltungssystem erfolgt die Lieferung von Nutzdaten vom Server an den Clienten.

Interaktionskonstrukte sind nicht symmetrisch. Auch bei zwei im allgemeinen vollständig gleichberechtigten Partnern innerhalb eines globalen IS wird im Einzelfall der Anstoss für die momentane Interaktion von einem Partner ausgehen. Dieser übernimmt für die aktuelle Interaktionsphase die Rolle des Clienten. Da das Interaktionskonstrukt nicht symmetrisch ist, wird dadurch eine Halbordnung der durch die aktuelle Zusammenarbeit betroffenen Teilsysteme innerhalb des globalen Informationssystems definiert. Das "oberste" Element dieser Halbordnung ist immer jener Client, von dem die ursprüngliche Anfrage ausging. Abhängig von dieser Anfrage werden dynamisch weitere Programme als Gateways oder Server eingeordnet. Diese können selber wieder als Clienten weitere Gateways und Server ansprechen.



Bild 2.6 Situation mit Rollenwechsel2.6 Situation mit Rollenwechsel

Die Rollen sind also nicht statisch zugeteilt. Ein Partner, der in einem bestimmten Interaktionskonstrukt als Server wirkt, kann alternativ in einem weiteren Interaktionskonstrukt als Client mit demselben (Bild 2.6) oder einem dritten Partner aktiv werden (Bild 2.5).

2.1.7 Vielfalt in globalen Informationssystemen

Die im Gegensatz zu Mono-IS grosse Vielfalt in globalen IS präsentiert sich auf vier Arten:

die Vielfalt der Benutzerschnittstellen,

die Vielfalt der Clienten,

die Vielfalt der Server und

die Vielfalt der Serverschnittstellen.

Vielfalt der Benutzerschnittstellen

Die erste Vielfalt tritt auf, wenn ein Endbenutzer nacheinander oder gleichzeitig auf mehrere heterogene Informationsquellen zugreifen will und dafür mehrere Browser einsetzen muss (Bild 2.7, Browser A, B und C). Diese Situation entspricht in den Grundzügen dem gleichzeitigem Zugriff auf mehrere Mono-IS. Statt mit verschiedenen Anwendungsprogrammen wird der Endbenutzer mit mehreren Browsern konfrontiert.

Bsp.: Frau Müller befindet sich in dieser unbefriedigenden Situation, solange sie sich neben Excel für den Zugriff auf das Mono-IS in dessen Benutzeroberfläche einarbeiten muss. Sie hat dann zwei verschiedene Programme auf Ihrem PC und muss die Verkaufszahlen umständlich aus einem Programm ins andere kopieren.

Als globales IS kann ein solches System nur dann bezeichnet werden, wenn eine Zusammenarbeit der verschiedenen Komponenten sichtbar ist, beispielsweise durch eine Koordination zwischen den Browsern oder den Informationsquellen (In Bild 2.7 nicht eingezeichnet).



Bild 2.7 Vielfalt der Benutzerschnittstellen2.7 Vielfalt der Benutzerschnittstellen

Ein globales IS mit mehreren Browsern bringt wenig Vorteile für den Endbenutzer. Er wird weiterhin mit verschiedenen Benutzerschnittstellen konfrontiert, was einen erheblichen Lernaufwand erfordert. Erst deren Reduktion führt einen Schritt weiter in Richtung praktikabler Lösungen.

Vielfalt der Clienten

Eine weitere Vielfalt entsteht dann, wenn auf eine Informationsquelle mehrere homogene Browser gleichzeitig zugreifen. Diese Situation ist bereits aus der klassischen Datenbankwelt und somit auch bei Mono-IS bekannt.

Bsp.: Dieses Problem ist in der Informatikabteilung aus Frau Müllers Firma schon lange bekannt. Frau Müller wird ja nicht als einzige auf das Mono-IS mit den Verkaufszahlen zugreifen, sondern zusammen mit anderen Endbenutzern.

Ein Kernproblem bildet dabei die Serialisierung der Aktivitäten der verschiedenen Endbenutzer. Diese Probleme sind in der Datenbankliteratur ausführlich beschrieben und werden deshalb hier nicht weiter diskutiert (eine Einführung gibt z. B. [Date 95]). Im Unterschied zu Mono-IS kann aber bei globalen IS die Anzahl der Endbenutzer und damit der Clienten beliebig gross werden. Diese Erweiterung hat durchaus gewisse Konsequenzen, etwa bei der Verrechnung von Leistungen, auf die aber an dieser Stelle ebenfalls nicht weiter eingegangen wird.



Bild 2.8 Vielfalt der Clienten2.8 Vielfalt der Clienten

In SGIS wird die gleichzeitige Zugriffsmöglichkeit von mehreren Clienten auf einen Server durch eine Querlinie zu den Verbindungen beschrieben.


Vielfalt der Server

Die nächste Vielfalt geht davon aus, dass der Endbenutzer mit einem Browser nacheinander oder gleichzeitig auf mehrere homogene Informationsquellen mit unterschiedlichen Inhalten zugreifen kann (Bild 2.9).

Bsp.: Die Tabellenkalkulation Excel von Frau Müller kann über ODBC auf kompatible Informationsquellen zugreifen. Excel unterstützt dabei auch den Zugriff auf mehrere Informationsquellen. Frau Müller kann damit in ihren Tabellen Daten aus verschiedenen Informationsquellen kombinieren.

Dabei stellt sich das Problem der Kombination von Daten aus verschiedenen Quellen. Dieses klassische Problem der Datenpräsentation ist eine Aufgabe des Browsers, der sämtliche Daten ordnet und für den Endbenutzer aufbereitet. Diese Aufgabe ist nur am Rand Gegenstand der vorliegenden Arbeit, die sich mit IS-Gateways befasst.



Bild 2.9 Vielfalt der Server2.9 Vielfalt der Server

In SGIS wird die gleichzeitige Zugriffsmöglichkeit eines Clienten auf mehrere Server durch eine Querlinie zu den Verbindungen beschrieben.


Vielfalt der Systemschnittstellen

Die vierte Vielfalt präsentiert sich aus zwei verschiedenen Blickrichtungen: aus der Sicht des Browsers zu den Informationsquellen und umgekehrt. Aus der Sicht des Endbenutzers mit seinem Browser sind möglicherweise die von den Informationsquellen angebotenen Systemschnittstellen unzugänglich, wenn sie von seinem Browser nicht unterstützt werden (links in Bild 2.10).

Bsp.: Dies ist genau Frau Müllers Situation, die aber mit einem IS-Gateway gelöst werden kann. Sie kann ohne dieses zwar auf alle ODBC-kompatiblen Informationsquellen zugreifen, aber nicht auf die Informationsquelle mit den Verkaufsdaten. Diese hat eine andere Schnittstelle.

Aus der Sichtweise des Servers möchten mehrere heterogene Browser auf eine Informationsquelle zugreifen, die nicht alle Clienten unterstützt (rechts in Bild 2.10).

Bsp.: Für die Informatikabteilung in Frau Müllers Firma stellt sich das Problem aus dieser Sichtweise. Mit klassischen Terminals konnten alle Endbenutzer auf das Mono-IS mit den Verkaufszahlen zugreifen. Nun möchte Frau Müller einen eigenen Browser (das Tabellenkalkulationsprogramm Excel) einsetzen, um auf dasselbe Mono-IS zuzugreifen.

In der Regel treten beide Varianten kombiniert auf. Diese Probleme bilden den Kern der vorliegenden Arbeit; als Lösung werden in solchen Situationen IS-Gateways eingesetzt.



Bild 2.10 Vielfalt der Systemschnittstellen;
Darstellung aller Zusammenarbeitsbedürfnisse und deren Kompatibilitätszustand2.10 Vielfalt der Systemschnittstellen

In SGIS wird durch eine gestrichelte Linie dargestellt, wenn ein Client und ein Server, die zusammenarbeiten sollen, inkompatibel sind.


2.2 IS-Gateways

Wenn Programme nicht direkt miteinander kommunizieren können, weil ihre Schnittstellen nicht übereinstimmen, übernimmt ein IS-Gateway die notwendige Schnittstellenabbildung (im folgenden Vermittlung genannt) (Bild 2.11).

Def.: Ein IS-Gateways ist ein selbständiges Programm, das die Zusammenarbeit von Informationssystemen oder Teilen von Informationssystemen sicherstellen kann.

Gateways sind Programme, die ausschliesslich zur Schnittstellenabbildung entwickelt werden. Sie müssen gleichzeitig als Client und als Server auftreten können und werden zwischen zwei existierende Programme geschoben



Bild 2.11 Einfügen eines Gateways2.11 Einfügen eines Gateways

Statisch werden IS-Gateways in SGIS als Kästchen mit abgerundeten Ecken dargestellt.


Die Schnittstelle des IS-Gateways zum Clienten wird clientseitige Schnittstelle des IS-Gateways genannt (AS in Bild 2.11), diejenige zum Server serverseitige Schnittstelle (BC in Bild 2.11). Die serverseitige Schnittstelle übernimmt also in der Zusammenarbeit mit anderen Programmen die Rolle des Clienten.

Ein IS-Gateway kann mehrere Aufgaben übernehmen: Es vermittelt einerseits zwischen unterschiedlichen Kommunikationsprotokollen und nimmt bei Bedarf Änderungen an der Struktur der übertragenen Daten vor. Der sachliche Inhalt (die Bedeutung) der transformierten Daten bleibt dabei soweit wie möglich unverändert. Andererseits passt es die Struktur der übermittelten Daten an die Anforderungen des jeweiligen Empfängers an. Diese Strukturänderung im IS-Gateway wird Transformation genannt. Dafür muss das IS-Gateway allenfalls minimale Angaben über die Struktur der transformierten Daten verwalten. Ein IS-Gateway ist jedoch kein selbständiges Informationssystem. Es verwaltet keine eigenen Nutzdaten, sondern leitet solche nur weiter.

Bsp.: Das für Frau Müller entwickelte IS-Gateway speichert keine Daten, sondern leitet nur die Daten des Mono-IS weiter.

Oft werden mehrere IS-Gateways hintereinander eingesetzt, z. B. wenn bestehende IS-Gateways wiederverwendet werden können. Damit ergibt sich eine Kaskade von IS-Gateways, die jedoch systematisch in Interaktionskonstrukte zerlegt werden kann. In Bild 2.12 mit zwei IS-Gateways A und B übernimmt das IS-Gateway A die Rolle des Clienten gegenüber IS-Gateway B. Umgekehrt spielt IS-Gateway B die Rolle eines Servers für das IS-Gateway A.



Bild 2.12 Kaskade von IS-Gateways2.12 Kaskade von IS-Gateways

In globalen IS gibt es zwischen der Benutzerschnittstelle und den Datenbeständen grundsätzlich mehrere Stellen, wo ein IS-Gateway eingebunden werden kann. Dies entspricht den verschiedenen Varianten von Client-Server-Architekturen bei Mono-IS (z. B. [Niemann 95]). Für globale IS ergibt sich somit die Situation, dass IS-Gateways an den verschiedensten Orten auftreten können: zwischen Informationsquellen, zwischen Browsern und Informationsquellen und als Kaskade, d. h. mehrere IS-Gateways nacheinander.

Diese Position eines IS-Gateways hat Auswirkungen auf die Aufgaben des IS-Gateways. Je nach Position steht die Kommunikationsvermittlung oder die Datentransformation mehr im Vordergrund. Zwischen Datenverwaltungssystemen geht es typischerweise um Änderungen des Datenformats, weil diese Systeme bezüglich Kommunikation sehr homogen sind. Zwischen Browsern und Mono-IS geht es vermehrt um Vermittlung, da dort grosse Unterschiede zwischen Benutzerschnittstellen von Mono-IS und Browsern liegen.

Bsp.: Wird das globale IS von Bild 2.3 mit den notwendigen IS-Gateways ergänzt, so präsentiert es sich statisch in SGIS wie folgt (Bild 2.13): Für das Datenverwaltungssystem C sowie für den Zugriff auf das Informationssystem A wird ein IS-Gateway benötigt, ebenso für die Zusammenarbeit der beiden Datenverwaltungssysteme C und D.



Bild 2.13 Ein globales Informationssystem mit IS-Gateways2.13 Ein globales Informationssystem mit IS-Gateways

2.3 Gründe für den IS-Gatewayeinsatz

2.3.1 Technische Inkompatibilitäten und andere Gründe

Die Hypothese 1 in Abschnitt 1.3 behauptet, dass aus verschiedenen Gründen ein IS-Gateway zwischen Programmen nötig sein kann. Der technische Hauptgrund für den Einsatz von IS-Gateways ist die fehlende Kompatibilität zwischen den Schnittstellen. Die wichtigsten Ausprägungen dieser Inkompatibilität sind:

unterschiedliche Synchronisation der Kommunikation,

unterschiedliche Zustände in Client und Server,

unterschiedliche Befehlssyntax und ­semantik sowie

unterschiedliche Datenstrukturen.

Diese technischen Aspekte werden in Kapitel 3 ausführlich diskutiert.

Neben den technischen Gründen, die in dieser Arbeit im Vordergrund stehen und die im Einzelfall den Einsatz eines IS-Gateways nahelegen, gibt es auch ökonomische und organisatorische Gründe für den breiten Einsatz von IS-Gateways.

2.3.2 Kosten durch die Vielfalt der Benutzerschnittstellen

Für diesen Unterabschnitt betrachten wir den entstehenden Aufwand aus der Sicht des Informationsanbieters und des Endbenutzers: Der Informationsanbieter ist Betreiber einer Informationsquelle, und der Endbenutzer der Betreiber eines Browsers. Auf Seite des Informationsanbieters wird nicht weiter unterschieden zwischen technischem Personal, das die Informationsquelle betreibt, und dem Lieferanten der Informationen, der für die Inhalte zuständig ist.

In einem globalen IS, in dem viele Endbenutzer von vielen Informationsanbietern Informationen beziehen, stellt sich die Frage nach den globalen Kosten für die Verbreitung und den Bezug dieser Information. In diese Gesamtgrösse fliessen zudem die Kosten für die Bereitstellung und den Betrieb von Benutzerschnittstellen sowie die Kosten für die Ausbildung der Endbenutzer ein. Die Kostenentwicklung für die Benützung eines einzigen Mono-IS durch mehrere Endbenutzer mit unterschiedlichen Schnittstellen ist in Bild 2.14 dargestellt. Die Unterstützung mehrerer Benutzerschnittstellen verursacht dem Informationsanbieter Kosten, die für jede weitere Benutzerschnittstelle ansteigen (durchgezogene Kurve in Bild 2.14). Umgekehrt sinkt dadurch der Lernaufwand für den erfahrenen Endbenutzer (gestrichelte Kurve in Bild 2.14), weil er eher eine ihm schon bekannte Schnittstelle benützen kann.

Bsp.: Im Beispiel aus Abschnitt 1.2 beherrscht Frau Müller zwar die Benutzerschnittstelle von Excel, nicht aber jene des Mono-IS mit den Verkaufszahlen, die sie interessieren. Sie müsste sich also in eine weitere Schnittstelle einarbeiten, um auf die Verkaufszahlen zugreifen zu können, solange diese nicht Excel-kompatibel angeboten werden.



Bild 2.14 Kosten für Verbreitung und Bezug von Information (qualitativ)2.14 Kosten für Verbreitung und Bezug von Information

Auf der Benutzerseite dürfte das Bedienen von mehreren verschiedenen Schnittstellen häufig unzumutbare Verwirrung hervorrufen. Durch die Einführung einer zusätzlichen Schicht zwischen der Informationsquelle und dem Browser wird für Informationsanbieter und Endbenutzer der Aufwand verringert. Ein oder mehrere IS-Gateways vermitteln dabei zwischen den verschiedenen Schnittstellen.

Heute kommt dazu, dass oft neue Benutzerschnittstellen schneller entwickelt als alte Benutzerschnittstellen angepasst werden können.

Bsp.: Frau Müller kann dank dem IS-Gateway mit Excel auf die Verkaufsdaten zuzugreifen. Sobald W3 in der Firma eingeführt wird, entsteht bei ihr der Wunsch, auch aus ihrem W3-Browser auf das Mono-IS zuzugreifen. Da auf das Mono-IS schon über ein IS-Gateway zugegriffen wird, kann auch durch eine einfache Änderung am IS-Gateway (und ohne Änderungen am Mono-IS selbst) aus W3 auf das Mono-IS zugegriffen werden.

2.3.3 Softwarewartung

Ein weiterer Grund für den Einsatz von IS-Gateways sind erhoffte Einsparungen bei der Softwarewartung. Die Kosten der Softwarewartung betragen bis zu 85% der gesamten Softwarekosten in der Industrie [Coleman et al. 94]. Diese Kosten erwachsen aus Fehlerkorrekturen, notwendigen Änderungen aufgrund von veränderten Anwenderwünschen oder externen Rahmenbedingungen (z. B. neue Gesetze) sowie durch Änderungen der zur Verfügung stehenden Ressourcen. Ein Grund für diesen im Vergleich zu anderen Technologien hohen Anteil an Wartungskosten ist paradoxerweise gerade die relativ hohe Anpassungsfähigkeit der Software. Andere technische Produkte (wie Hardware oder Autos) werden typischerweise im ursprünglichen Funktionszustand gehalten und notfalls ersetzt, von Software wird jedoch eine dauernde Erweiterung und Anpassung der Funktionalität erwartet.

Der Einsatz von globalen IS verschärft das Wartungsproblem zusätzlich. Wenn in einem System mit mehreren Informationsquellen und mehreren Browsern aufgrund neuer Anforderungen an einen einzelnen Browser ein Teilssystem Browser/I-Quelle geändert wird, so kann durch die anderen Browser im allgemeinen nicht mehr auf diese I-Quelle zugegriffen werden (Browser B und I­Quelle D in Bild 2.15). Ebenso kann der geänderte Browser nicht mehr auf die anderen I-Quellen zugreifen.



Bild 2.15 Änderung eines Teilsystems führt zu Inkompatibilitäten2.15 Änderung eines Teilsystems führt zu Inkompatibilitäten

Um die ursprünglichen Zugriffsmöglichkeiten wieder herzustellen, müssen somit bei jeder Änderung von Teilssystemen alle Programme überprüft und allenfalls nachgeführt werden.

Die Verfügbarkeit eines IS-Gateways zwischen Informationsquelle und Browser vereinfacht diese Anpassung. Zusammen mit der erfolgten Änderung an der Informationsquelle muss nur das bestehende IS-Gateway an die neue Situation angepasst werden, die anderen Clienten bleiben unbeeinflusst [Wiederhold 95]. Für eine Übergangszeit können sogar zwei verschiedene IS-Gateways in Betrieb bleiben, so dass die notwendigen Anpassungen in den Informationsbezügern nach und nach durchgeführt werden können. Häufig lohnt es sich deshalb, anstelle einer gemeinsamen Schnittstelle ein oder mehrere spezielle IS-Gateways einzusetzen, auch wenn eine Definition der Schnittstelle reichen würde.



Bild 2.16 Auffangen der Folgen von Änderungen mittels IS-Gateway2.16 Auffangen der Folgen von Änderungen mittels IS-Gateway

Bsp.: Zur Lösung des Anschlussproblems von Frau Müller könnte theoretisch (und mit kaum bezahlbarem Aufwand) ein neues Anwendungsprogramm entwickelt werden, das ähnlich oder gleich wie Excel zu bedienen ist, aber mit dem bestehenden Mono-IS zusammenarbeiten kann. Sobald jedoch etwas an dem Mono-IS geändert wird, muss auch dieses neue Anwendungsprogramm wieder geändert werden. Bei der Lösung mit einem IS-Gateway muss ausschliesslich das IS-Gateway angepasst werden. Ausserdem kann Frau Müller weiterhin ihre Standardsoftware Excel einsetzen.

2.3.4 Migration von Informationssystemen

Ein dritter Grund für den Einsatz von IS-Gateways wurde erst in den letzten Jahren aktuell. Dabei geht es um den temporären Einsatz von IS-Gateways bei Systemmigrationen. Unter Migration von Informationssystemen versteht man den Übergang von einem alten Informationssystem (Altsystem, Legacy IS) auf ein neues Informationssystem. Falls dabei ein inkrementeller Ansatz (z. B. [Brodie, Stonebraker 95]) gewählt wird, bilden das alte und das neue Informationssystem für die Übergangszeit gemeinsam ein verteiltes System.

Ein inkrementeller Übergang mit IS-Gateways ist deshalb ein sinnvoller Migrationsansatz, weil häufig Informationssysteme im Kernbereich von Unternehmen angesiedelt sind und nicht so lange ausgeschaltet werden können, dass die ganze Migration auf einmal durchgeführt werden kann.



Bild 2.17 Inkrementeller Ersatz von Altsystemen durch Einsatz von Reverse- und Forward-IS-Gateways2.17 Einsatz von Reverse- und Forward-IS-Gateways

Grössere Unterschiede zwischen altem und neuem System werden dabei durch IS-Gateways überbrückt (Bild 2.17). Zu unterscheiden sind dabei Reverse- und Forward-IS-Gateways je nachdem, ob das neue auf das alte System zugreift, oder das alte System auf das neue. Entsprechend wird das IS-Gateway vor oder nach der endgültigen Nutzdatenübernahme eingesetzt.

Der Gatewayeinsatz bei der Migration von Informationssystemen steht in dieser Arbeit nicht im Vordergrund. Die hier diskutierten Lösungen lassen sich jedoch auch auf Anwendungen dieser Art übertragen. Zur Datenmigration siehe [Aebi 96].

2.3.5 Alterung von Schnittstellen

Bisher kaum beachtete Einsatzmöglichkeiten von IS-Gateways gibt es im Zusammenhang mit der technischen Alterung von Teilsystemen und Schnittstellen: Die Alterung von Schnittstellen zwischen Systemen ist unabhängig von der Alterung der beteiligten Systeme. Ein wesentlicher Grund für die Definition von Schnittstellen zwischen Systemen liegt ja gerade darin, dass die Systeme dadurch technisch entkoppelt werden und unabhängig voneinander ersetzt werden können. Schnittstellen müssen dazu so definiert werden, dass sie sich möglichst nicht verändern. Mit fortgeschrittenem Alter genügen aber auch sie den veränderten Rahmenbedingungen nicht mehr. Müssen Schnittstellen schliesslich ersetzt, d. h. neu definiert werden, bedingt dies Änderungen an allen beteiligten Komponenten. Solche Änderungen können wiederum zeitlich gestaffelt werden, wenn vorübergehend mit IS-Gateways gearbeitet wird. So kann ein Teilsystem (B in Bild 2.18) während einer längeren Phase schon eine neue Schnittstelle (SS2) anbieten, während ein anderes (A) immer noch auf der alten Schnittstelle (SS1) basiert. Sobald die Umstellung auf die neue Schnittstelle überall erfolgt ist, kann das IS-Gateway entfernt werden.



Bild 2.18 Inkrementeller Ersatz von Schnittstellen dank IS-Gateways2.18 Inkrementeller Ersatz von Schnittstellen dank IS-Gateways

Bsp.: Im Falle von Frau Müller wird vielleicht das Mono-IS mit den Verkaufszahlen bis auf weiteres ohne eigene ODBC-Schnittstelle in Betrieb bleiben. Eine ODBC-kompatible Schnittstelle wird aber durch ein zusätzliches IS-Gateway angeboten, so dass Frau Müller ab sofort auf das Mono-IS zugreifen kann.

Der Gatewayeinsatz beim Ersetzen von Schnittstellen steht bei dieser Arbeit nicht im Vordergrund. Die vorgeschlagenen Lösungen lassen sich jedoch auch auf solche Anwendung übertragen.

2.3.6 Änderungen in der Informatikinfrastruktur

Ein weiteres wirtschaftlich motiviertes Einsatzgebiet für IS-Gateways beruht auf der Zunahme der Informatiksysteme weltweit und wird daher weiter an Bedeutung gewinnen. Durch die stürmischen Entwicklungen im Informatik- und namentlich im Netzbereich ist die Informatik-Infrastruktur in den meisten Betrieben sehr unübersichtlich und heterogen geworden. Neben Grossrechnern werden meist unzählige Personalcomputer für Spezialaufgaben eingesetzt. Trotzdem sollten die verschiedenen Teilsysteme miteinander kommunizieren können.

So vergrössert sich der Bestand an einzubindenden Informationssystemen laufend. Schon heute gibt es eine Vielzahl von eigenständigen Computersystemen, die früher oder später mit anderen Informationssystemen kommunizieren werden (Bordcomputer in Firmenautos, Sensoren in Getränkeautomaten etc.). Die zunehmende Vernetzung und Computerisierung des Alltags wird das Ihre dazu beitragen. Dies erfordert vermehrt IS-Gateways, die sich generisch und dynamisch an neue oder veränderte Informationssysteme anpassen können. Die Anzahl (kommerzieller) Informationsserver ist etwa im Finanzbereich bereits so gewaltig, dass gar keine direkte Koordination mehr möglich ist. IS-Gateways bieten hier die nötige Flexibilität und erlauben schrittweise die gemeinsame Nutzung von immer mehr Informationsservern, ohne die Autonomie der einzelnen Server zu beeinträchtigen.

Dieser Autonomieaspekt ist nicht zu unterschätzen. Gewisse Teilsysteme müssen ihre eigenen Daten notwendigerweise selber unterhalten. Es ist daher unwahrscheinlich, dass sie ihre internen oder nach aussen sichtbaren Funktionen, Datenstrukturen und Daten den Bedürfnissen des übergeordneten Systems anpassen werden. Bestenfalls steht eine Beschreibung des Inhalts und der Schnittstelle zur Verfügung. Dies ist genau die Situation die für die Praxisbeispiele im Bereich World Wide Web bereits heute gilt.

2.4 Grenzen von IS-Gateways

2.4.1 Effizienzeinbussen

Der Haupteinwand gegen die Verwendung von IS-Gateways kommt von Integralisten, die sich gegen jede Aufteilung als solche wehren, da die Aufteilung eines grossen Systems in verschiedene Teilsysteme normalerweise zu Effizienzeinbussen führt. Dies gilt umso mehr, wenn statt einfacher Schnittstellen ganze Umsetzungsprogramme, eben IS-Gateways, eingesetzt werden.

Es ist kaum zu bestreiten, dass ein IS-Gateway zur Laufzeit zusätzliche Ressourcen (Speicher, Rechenzeit, …) benötigt. Demgegenüber stehen die verhinderte Systemkomplexität und Einsparungen, die durch einfachere Programme erzielt werden. Beim heutigen Verhältnis der Kosten für Computerhardware einerseits und für die Entwicklung und Wartung von Programmen andererseits fallen jedoch Einsparungen bei der Entwicklung und Wartung wesentlich stärker ins Gewicht. In allen in dieser Arbeit diskutierten Fällen ergibt sich deshalb eine echte Einsparung beim Einsatz von IS-Gateways.

2.4.2 Auch IS-Gateways müssen angepasst werden

Selbstverständlich müssen auch IS-Gateways periodisch an veränderte Rahmenbedingungen angepasst werden. Anpassungen an geänderte Schnittstellen einer Informationsquelle sind jedoch einfacher in einem IS-Gateway durchzuführen als in unzähligen Programmen, die als Clienten direkt auf eine Informationsquelle zugreifen. Im Falle einer nach aussen wirksamen Änderung am IS-Gateway selbst können altes und neues IS-Gateway nebeneinander betrieben werden. Dies ist möglich, weil ein IS-Gateway keine eigenen Nutzdaten unterhält und damit keine Konsistenzprobleme auftreten. So können nach der Installation eines neuen IS-Gateways alle betroffenen Programme nach und nach geändert und getestet werden. Die Migration auf ein neues IS-Gateway ist also zeitlich unkritisch.

2.5 Andere Ansätze mit Bedeutung für globale Informationssysteme

Im folgenden werden einige verwandte kommerzielle Angebote und Forschungsprojekte diskutiert. Dabei steht nicht die Auflistung der einzelnen Projekte im Vordergrund, sondern die Diskussion von Problemkreisen und substantiellen Beiträgen aus diesen Projekten. Für die Beschreibung der einzelnen Projekte wird soweit als möglich auf bestehende Literatur verwiesen. In diesem Zusammenhang stellt sich allerdings ein praktisches Problem: Viele Arbeiten in diesem Bereich, d. h. in konkreten Anwendungen, sind nie öffentlich dokumentiert oder gar publiziert worden. An Arbeiten mit kommerziellem Hintergrund ist schwer heranzukommen, weil gerade in Integrationsprojekten viel kommerziell wertvolles Wissen steckt.

Die diskutierten Projekte werden im folgenden nach der Art des Beitrages für die Realisierung globaler Informationssysteme gruppiert.

2.5.1 Kommunikation mit dem Server

Der erste Beitrag bestehender Ansätze zur Realisierung globaler IS betrifft ganz allgemein die Extraktion von Daten aus Teilsystemen. Das primäre Ziel ist dabei, die Daten aus einer bestehenden Informationsquelle herauszuholen, vorerst ohne Berücksichtigung von später durchzuführenden Änderungen in der Struktur.

Bsp.: Im Beispiel der Frau Müller aus Abschnitt 1.2 geht es vorerst darum, dass die Verkaufszahlen aus dem Mono-IS herausgeholt werden können. Dazu muss das entsprechende Programm mit dem Mono-IS zusammenarbeiten können und sich daran anpassen. Erst in einer zweiten Stufe werden dann die erhaltenen Daten analysiert und transformiert.

In globalen IS sollen sich die vorhandenen Teilsysteme nicht an andere Komponenten anpassen müssen. Wird ein IS-Gateway eingeführt, muss sich dieses vollständig an die Vorgaben des Servers anpassen. Gemäss Abschnitt 2.1 existieren bei der Kommunikation mit dem Server drei Zugriffsmöglichkeiten: Zugriff auf die Datenschnittstelle, Zugriff über eine Systemschnittstelle oder Zugriff über die Benutzerschnittstelle.

Für die Ziele dieser Arbeit sind die Systemschnittstellen der Teilsysteme besonders wichtig. Nur diese verbinden bereits innerhalb des Teilsystems Programme miteinander. Die Datenschnittstelle des Teilsystems verbindet ein Programm mit einem Datenbestand, die Benutzerschnittstelle verbindet den Menschen mit den Anwendungsprogrammen. Die Systemschnittstellen der Teilsysteme sind deshalb auch am besten dazu geeignet, weiteren Programmen Zugriff auf gespeicherte Daten zu ermöglichen. In globalen IS wird deshalb versucht, soweit als möglich auf Systemschnittstellen zuzugreifen.

Nur notfalls wird direkt auf die Datenschnittstelle zugegriffen. Diese Schnittstelle hat den wichtigen Nachteil, dass die Funktionen des Datenverwaltungssystems umgangen werden.

Bei der Einbindung von bestehenden Informationssystemen zeigt sich allerdings, dass oft gar keine System- oder Datenschnittstellen verfügbar sind. Steht auf dem Server lediglich eine Benutzerschnittstelle zur Verfügung, muss durch das IS-Gateway gegenüber dem Server das Verhalten des Endbenutzers simuliert werden.

Praktisch alle bisherigen Arbeiten betrachten den Fall des Zugriffs auf eine Systemschnittstelle. Der Zugriff auf die Benutzerschnittstelle kommt ebenfalls vor, wurde bisher jedoch immer spezifisch für ein einziges Mono-IS realisiert. Beispiele dafür geben [Papakonstantinou et al. 94] [Ronchetti et al. 95], [Barta, Hauswirth 95] und [Balestra, Ferucci 94]. Ein generischer, für mehrere Benutzerschnittstellen konfigurierbarer Ansatz konnte bisher in der Forschungsliteratur nicht gefunden werden. Das Praxisbeispiel 1, TS/IDLE, behandelt erstmals ein generisches IS-Gateway für den Zugriff auf verschiedene Benutzerschnittstellen.

Heute sind bereits käufliche Produkte verfügbar, die auf Benutzerschnittstellen aufsetzen. Diese beschränken sich jedoch auf das sogenannte "Face-Lifting", die formale Neugestaltung einer Benutzerschnittstelle. So werden etwa Funktionstasten eines herkömmlichen Terminals neu grafisch dargestellt und können so mit der Maus bedient werden. Diese Produkte stellen aber keine weitergehende Funktionalität zur Verfügung und können daher für die globale Datennutzung nicht eingesetzt werden.

2.5.2 Spezielle Datenbeschreibungssprachen

Einen weiteren Beitrag zur Realisierung von globalen Informationssystemen liefern spezielle Datenbeschreibungssprachen. Höhere, deskriptive Datendefinitionssprachen wie SQL oder Entitätenmodelle sind hier zuwenig präzise. Dagegen enthalten IM, ein Prototyp eines globalen IS [Levy et al. 95], und SIMS [Arens et al. 94] konkrete, durch Programme interpretierbare Serverbeschreibungssprachen, worin die einzelnen Systeme samt ihren Datenbeständen formal beschrieben werden können. In IM stehen sämtliche Beschreibungen in Relation zu einer globalen, für alle Teilnehmer gemeinsamen Sicht.

Müssen Datenbeschreibungen nachträglich entwickelt werden, helfen allenfalls Reverse-Engineering Methoden [Aebi 96]. Auf diese Problematik wird hier aber nicht weiter eingegangen.

2.5.3 Referenzarchitekturen

In beschränktem Rahmen bieten sogenannte Unternehmensarchitekturen gute Voraussetzungen für den Aufbau globaler IS [Tibbetts 95]. Diese sind vor allem für Softwarehersteller ein Untersuchungsthema. Beispiele wäre etwa Open Blueprint von IBM [IBM 95] oder Open Enterprise Computing von Hewlett-Packard [HP 95]. Diese Unternehmensarchitekturen reichen von den Anwendungsprogrammen bis zur Hardware und empfehlen auf allen Stufen konkrete Produkte. Typischerweise orientieren sich Unternehmensarchitekturen an den vom Hersteller angebotenen Produkten. Lücken im Angebot (z.B. Inkompatibilitäten mit Normen) werden häufig diskret umgangen.

Die akademische Forschung geht hier neue Wege: Anstelle einer Unternehmensarchitektur definiert sie eine Referenzarchitektur für globale IS. Referenzarchitekturen basieren losgelöst von existierenden Produkten primär auf Funktionen. Wo in Open Blueprint "Data Access Services" mit relationalen, hierarchischen und objektorientierten (IBM-)Datenverwaltungssystemen auftreten, nennt I33 (Intelligent Integration of Information) [I3 95] diese verallgemeinernd Informationsquellen, dafür mit durch ihre Funktionalität beschriebenen Verpackungsdiensten. Um welche Art von Informationsquelle es sich dabei handelt, interessiert in I3 nicht. Verpackungsdienste passen die Informationsserver an interne oder externe Normen an. Diese Normen können die Schnittstellen oder auch das Verhalten der Teilsysteme betreffen. Die wichtigsten Verpackungsdienste umfassen die Kommunikationsprotokolle und die Datenstruktur. Daneben definiert I3 weitere Funktionsgruppen für die Einbindung von Teilsystemen wie die Funktionserweiterungsdienste. Durch die Funktionserweiterungsdienste werden die zur Verfügung stehenden Informationsserver funktional erweitert. Beispiele dafür sind aktive Dienste, Versionenverwaltung, Objektorientiertheit und Persistenz. Ein aktiver Dienst kann automatisch das Eintreten von gewissen Bedingungen (wie Änderungen eines Datenwerts) melden, auch wenn der Informationsserver dies selber nicht tun kann. Damit kann die Konsistenz von Daten über verschiedene Informationsserver hinweg gesichert werden.

Ein Mittelding zwischen akademischer Referenzarchitektur und konkreter industrieller Unternehmensarchitektur sind die von einem Konsortium entwickelten "National Industrial Information Infrastructure Protocols" (NIIIP), eine Referenzarchitektur für unternehmensübergreifende Zusammenarbeit im Fertigungsbereich [NIIIP 96].

Auch für die vertiefte theoretische Behandlung von verteilten Datenbanken existieren verschiedene Referenzarchitekturen, die hier nur der Vollständigkeit halber angeführt werden. Die wichtigste ist wohl das 5-Schichten-Schema [Sheth, Larson 90]. Dort sind unter dem Begriff "(Transforming) Processor" Komponenten mit IS-Gatewayfunktionalität vorgesehen. Zwischen allen Stufen des Schemas befinden sich sogenannte "Prozessoren", welche die an dieser Stelle anfallenden Aufgaben wie Schematransformationen, Schema- und Datenfilterung sowie Schemaintegration besorgen. Ein Prozessor besteht aus einem Command Translator und einem Data Converter. Von besonderem Interesse erscheint den Autoren die Transformation von prozeduralen zu nichtprozeduralen Abfragesprachen. In der vorliegenden Arbeit spielt jedoch dieser Unterschied nur eine untergeordnete Rolle.

2.5.4 Normen

Einen wichtigen Bestandteil von Referenzarchitekturen bilden die darin identifizierten Schnittstellen zwischen den einzelnen Komponenten und die Definition von Normen für diese Schnittstellen. Die Verwendung von internationalen Normen dient denn sowohl der unternehmensübergreifenden Zusammenarbeit wie auch dem Aufbau von globalen IS. Die Referenzarchitektur NIIIP basiert beispielsweise auf CORBA [OMG 91] und STEP/EXPRESS [ISO 10303:1994]. STEP/EXPRESS ist eine von der ISO geförderte Norm im Bereich der Produktdaten. CORBA (Common Object Ressource Broker) definiert eine Norm für Schnittstellen und deren Beschreibung. Zur Definition der CORBA-Schnittstellen wurde eigens die normierte Schnittstellendefinitionssprache IDL (Interface Description Language) entwickelt. EDIFACT [ISO 9735:1988] ist eine weitere Norm, spezialisiert auf den Bereich der Handelsdaten.

Ein bekanntes Beispiel für Normen im Umfeld dieser Arbeit ist etwa SQL für Datenbankzugriffe. Trotz der SQL-Normierung gibt es jedoch immer noch wesentliche Unterschiede zwischen verschiedenen SQL-Dialekten, da die Normierung noch nicht alle Datenverwaltungsbereiche abdeckt. Ausserdem unterstützt auch nicht jedes sogenannt SQL-kompatible Datenverwaltungssystem alle normierten Features: Binary Large Objects (BLOB) und andere neue Datentypen, Stored Procedures und Systemtabellen sind Beispiele dafür. Trotz starker Verbreitung im Kernbereich Datenbanken bleibt SQL als Universalmittel für die Integration von beliebigen Teilsystemen in globalen IS ungeeignet, weil SQL zu stark auf das relationale Modell ausgerichtet ist. Für andere auf dem relationalen Modell basierende Vorschläge wie ODBC (Microsoft), DRDA (IBM) oder DBA (Siemens-Nixdorf) gilt dasselbe.

Ein weiterer Ansatz einer Norm für die Integration von Informationssystemen stellt nicht die Gesamtarchitektur ins Zentrum, sondern die einzelnen Dokumente (beziehungsweise Objekte). OpenDoc (IBM, Apple, …) ist eine solche Verarbeitungstechnik für verbundene Dokumente. Damit können verteilte Systeme auf der Basis von kommunizierenden Objekten implementiert werden. Auch OLE [Kindel 95] von Microsoft enthält eine entsprechende Norm für verbundene Dokumente, analog zu OpenDoc.

Falls Client und Server derselben Norm genügen, ist kein spezielles IS-Gateway notwendig. Das langfristige Ziel sind somit globale IS mit genormten Schnittstellen. Es sind jedoch alle diskutierten Normen "externe" Normen, d. h. sie dienen nur zum Austausch von Information zwischen zwei Teilsystemen. Die interne Implementierung von Teilsystemen ist dadurch nicht betroffen. In einem gewissen Sinne ist somit in jedem normgerechten Teilsystem IS-Gatewayfunktionalität anzutreffen, dort nämlich, wo die systeminternen Strukturen und Funktionen in eine externe Norm transformiert werden.

2.5.5 Schemaintegration

Ein Problem, das auch Normen wie CORBA oder SQL nicht lösen können, ist dasjenige der Schemaintegration. Dabei geht es um die Abstimmung der Metadaten, nicht der Nutzdaten. In I33 übernehmen sogenannte semantische Dienste die notwendigen semantischen Veränderungen der Daten. Dies umfasst neben der eigentlichen Schemaintegration auch die Verwaltung von kontextspezifischen Wörterbüchern und die automatischen Übersetzungen von Anfragen zwischen verschiedenen Kontexten; es verlangt aber auch den Umgang mit unterschiedlichen Vorstellungen über das Wesen von Transaktionen.

Ein sehr theoretischer Lösungsansatz in Richtung automatische Schemaintegration [Sheth, Kashyap 92] hat bisher nicht überzeugen können. Zu einfach sind die demonstrierten Beispiele. Der wissensbasierte Ansatz von Carnot [Colet et al. 91] erlaubt eine globale Sicht auf die Datenbestände durch einen Wissensdatenbestand und Artikulationsaxiome. Die Artikulationsaxiome definieren dabei übereinstimmende Elemente der globalen und der lokalen Sicht. Darauf basiert die automatische Schemaintegration.

Mehr Erfolg dürften Speziallösungen wie STEP/EXPRESS haben, bei welchen nicht nur die Datenbeschreibungssprache, sondern auch die Datenbeschreibung selbst, d. h. das Schema, normiert wird. Obwohl sich STEP/EXPRESS ausschliesslich auf Produktdaten beschränkt, ist der Normierungsaufand beträchtlich. Dieser Ansatz dürfte deshalb im allgemeinen nicht zum Ziel führen. Als Konsequenz werden IS-Gateways auch in Zukunft mit unterschiedlichen Datenbeschreibungen umgehen müssen.

2.5.6 Offenheit / Anpassungsfähigkeit

Ein allgemein wichtiger Punkt bei Integrationsansätzen ist die Offenheit gegenüber bestehenden Systemen und neuen Entwicklungen. Referenzarchitekturen wie I3 sind in dieser Hinsicht problemlos, Unternehmensarchitekturen von Softwareherstellern sind normalerweise eingeschränkter. Open Blueprint von IBM setzt beispielsweise breit auf Normen wie CORBA auf. OLE von Microsoft ist vorwiegend proprietär.

Neue objektorientierte Ansätze könnten hier einiges zu offenen Lösungen beitragen. Durch die Einführung von Objekten soll namentlich die Wiederverwendbarkeit gefördert werden. Die Zusammenarbeit zwischen verschiedenen Objekten basiert dabei auf standardisierten Schnittstellen. Konkret wird jedoch durch die Speicherung von Objekten, bestehend aus Programmen und Daten anstelle reiner Daten, teilweise vom Prinzip der Datenunabhängigkeit abgewichen. Sobald die Schnittstellen an neue Anforderungen angepasst werden, müssen für alle Objekte die Methoden individuell überprüft und gegebenenfalls an die neue Schnittstelle angepasst werden. Dabei ist zu beachten, dass die Anzahl heterogener Objekte sehr gross werden kann.

2.5.7 IS-Gateway-ähnliche Ansätze

In verschiedenen Arbeiten wurden bereits IS-Gateways implizit oder explizit beschrieben, ohne dass der Begriff Gateway allgemein oder gar einheitlich verwendet wird. Der in dieser Arbeit verwendete Gatewaybegriff deckt neben den Verpackungsdiensten (Wrapper) von I3 auch Teile der funktionalen Erweiterungsdienste ab. Der Begriff Gateway existiert in I3 nicht, aber es wurden im Rahmen verschiedener I3-Projekte Wrapper entwickelt, namentlich im TSIMMIS-Projekt [Papakonstantinou et al. 94]. Weitere Beispiele für IS-Gateways finden sich in [Ronchetti 95], [Lin, Chung 95] und [Barta, Hauswirth 95].

Um bestehende Informationssysteme in CORBA einzubinden, sind auf jeden Fall IS-Gateways nötig. Diese IS-Gateways müssen die interne Repräsentation in die durch IDL definierte Darstellung umsetzten.

Über die Funktionalität der hier diskutierten IS-Gateways hinaus, können ARCHON-Agenten (ARchitecture for Cooperative Heterogeneous ON-line systems) [Jennings 94], [Wittig et al. 94] auch autonom handeln. Ein Agent kann beispielsweise selbständig Informationen von anderen Agenten anfordern oder sogar spontan relevante Informationen an andere Agenten schicken. In ihrer passiven Aufgabe entsprechen sie jedoch durchaus dem IS-Gatewaybegriff dieser Arbeit. Die Teilsysteme müssen sich jedoch sehr stark an die Erfordernisse der Agenten anpassen.

Bestandteil kommerzieller Unternehmensarchitekturen ist heute häufig sogenannte Middleware. Im allgemeinen bezeichnet "Middleware" ein ganzes Feld von vorwiegend kommerziell erhältlichen Produkten zur Einbindung von Teilsystemen. Der Begriff Middleware umfasst als typisches "Gummischlagwort" auch weitere, für diese Arbeit weniger interessante Elemente wie CASE-Tools, die verwendeten Transportprotokolle, Leistungen, die normalerweise durch Betriebssysteme erbracht werden wie Verzeichnisdienste oder Sicherheitsmechanismen (z. B. Backups) oder Transaktionsmonitore (CICS von IBM, Tuxedo von Novell, Encina von Transac). Ein kommerziell erhältliches Produkt ist beispielsweise das Informix Gateway with DRDA, andere sind DBA von Siemens Nixdorf oder alle ODBC-Treiber. Letztere sind nichts anderes als IS-Gateways zwischen ODBC und einem Datenverwaltungssystem. Diese Funktionen der Middleware liegen sehr nahe beim IS-Gatewaybegriff dieser Arbeit.

2.5.8 Bewertung der bisherigen Arbeiten

Für Multidatenbanken sind, basierend auf Referenzarchitekturen wie dem 5-Schichten-Schema [Sheth, Larson 90] beachtliche Erfolge erzielt worden. Mit kommerziellen Produkten wie EDA/SQL lassen sich heute über 50 verschiedene DBMS einheitlich integrieren. Damit wird im Bereich verteilter oder Multidatenbanken viel erreicht. Trotzdem gibt es zu beachten, dass für die Integration stark einschränkende Annahmen getroffen werden: Die Teilsysteme sind echte, homogene Datenverwaltungssysteme (z. B. alles relationale Systeme), die Datenschemas aller Teilsysteme sind bekannt, etc. Die Datenbankforschung konzentriert sich damit typischerweise auf physisch verteilte Datenbanken (mit einheitlichem Datenschema) und allenfalls auf föderative Systeme (mit einem übergreifenden, "unternehmensweiten Datenschema" [Zehnder 96]). Unter dem Oberbegriff "Schemaintegration" wird heute versucht, die obigen Erfolge auf verbundene Datenbanken auszuweiten. Verbundene Datenbanken sollen automatisch (oder eventuell mit manueller Unterstützung) in ein "globales Datenschema" eingeordnet werden, um dann die bekannten Techniken der föderierten Datenbanken anwenden zu können [Sheth 91], [Sheth, Kashyap 92], [Levy et al. 95], [Arens et al. 94].

Für heterogene Systeme wurden bisher in Einzelfällen Erfolge erzielt. Allgemein erfolgreiche Lösungen wurden jedoch noch nicht präsentiert.

2.6 Schlussfolgerungen aus Kapitel 2

Die erste der drei Hypothesen in Abschnitt 1.3 lautete:

Hypothese 1:
Zur globalen Integration von Informationssystemen reicht die Definition präziser Schnittstellen alleine nicht aus. Im allgemeinen Falle sind zusätzliche Programme (IS-Gateways) notwendig, um die Lücken zu schliessen.

Im Abschnitt 2.3 wurden technische Gründe angeführt, weshalb es bei der Einbindung von bestehenden Informationssystemen nicht immer möglich ist, eine gemeinsame Schnittstelle zwischen zwei Systemen zu definieren. Diese werden im nächsten Kapitel vertieft behandelt. In den Kernbereichen Extraktion und Integration wurde in praktisch allen verwandten Arbeiten die Einführung von zusätzlichen IS-Gateways mit aktiv vermittelndem Charakter notwendig. Weiter wurde in Abschnitt 2.3 gezeigt, dass eine gemeinsame Schnittstelle zwischen Systemen in gewissen Fällen aus wirtschaftlichen Gründen gar nicht erwünscht ist. Insofern wird die erste Hypothese bestätigt. IS-Gateways werden benötigt, weil Schnittstellen aus technischen und wirtschaftlichen Gründen nicht ausreichen. In verschiedenen Zusammenhängen wurden deshalb bis anhin problemspezifische Lösungen realisiert.

Eine Übersicht über solche Ansätze bildete den Rest dieses Kapitels. Sie veranschaulicht, dass das Problem (mindestens Teilprobleme) bekannt ist und auch breit diskutiert wird. Es existieren einige Referenzarchitekturen, die aufzeigen, wie Teilsysteme zusammenarbeiten können. Für die dadurch identifizierten Schnittstellen wurden beziehungsweise werden Normen definiert. Wie aber ausserhalb der Norm liegende Teilkomponenten eingefügt werden können, wird nicht immer angegeben. Meist beschränkt sich die Diskussion auf die Ebene des Einfügens von Kästchen in der Architektur. Es existiert deshalb noch kein genügend breiter und systematischer Ansatz, wie diese Kästchen konkret implementiert werden sollen.

3 THEORETISCHE GRUNDLAGEN VON IS-GATEWAYS


3.1 Einleitung

Zwischen Teilsystemen eines globalen IS können verschiedenartige Inkompatibilitäten existieren. Ein Beispiel ist die im vorangehenden Kapitel unter dem Stichwort Schemaintegration diskutierte Inkompatibilität der Datenschemas. Weitere wichtige Inkompatibilitäten liegen im Bereich der Kommunikation zwischen den Teilsystemen. In dieser Arbeit stehen die folgenden vier Inkompatibilitäten im Vordergrund:

unterschiedliche Synchronisation der Kommunikation,

unterschiedliche Zustände in Client und Server,

unterschiedliche Befehlssyntax und ­semantik sowie

unterschiedliche Datenstrukturen.

Diese werden für die Klassifikation von IS-Gateways nach ihrer Funktionalität verwendet und in Abschnitt 3.2 beschrieben. In diesem Kapitel werden drei verschiedene Hauptkriterien vorgestellt, um IS-Gateways zu klassifizieren: nach der Spezialisierung, nach der Funktionalität und nach Entwurfsvarianten. Einen weiteren Schwerpunkt dieses Kapitels bildet der Vorschlag für eine Referenzarchitektur für IS-Gateways.

3.2 Grundlegende Klassifikationsmerkmale

Eine erste, grundlegende Klassifikation dient zur raschen Einordnung von IS-Gateways. Dadurch ist relativ schnell und ohne grosse Abklärungen auch eine erste Bewertung von IS-Gateways möglich. Diese grundlegende Klassifikation geschieht nach drei voneinander unabhängigen Dimensionen (Bild 3.1). Die serverseitige Flexibilität und die clientseitige Flexibilität betreffen die Allgemeinheit von IS-Gateways (3.2.1), die Funktionalität den Umfang von Transformation und Vermittlung (3.2.2).

3.2.1 Flexibilität IS-Gateways

Für die ersten beiden Dimensionen ist der Unterschied zwischen generischen und spezifischen IS-Gateways relevant. Für beide Schnittstellen ist je eine Dimension vorgesehen. In Bild 3.1 spannen diese beiden Dimensionen die horizontale Ebene auf. Generische IS-Gateways können äusserst einfach an verschiedene oder geänderte client- bzw. serverseitige Schnittstellen angepasst werden. Die notwendigen schnittstellenspezifischen Daten sind nicht innerhalb des IS-Gateways in Form von Programmzeilen gespeichert, sondern in speziellen Datenbeständen, den Beschreibungen der beteiligten Partner. Ein eingesetztes IS-Gateway wird immer zwischen genau einer Server- und einer Clientschnittstelle vermitteln. Dies gilt ebenfalls für ein generisches IS-Gateway. Allerdings ist ein generisches IS-Gateway leicht an eine andere client- oder serverseitige Schnittstelle anpassbar. Um ein spezifisches IS-Gateway zu ändern, sind dagegen Änderungen im Programmcode oder gar im Design notwendig.



Bild 3.1 Die grundlegenden Klassifikationsdimensionen bei IS-Gateways3.1 Die grundlegenden Klassifikationsdimensionen bei IS-Gateways

Aus einer konzeptionellen Sicht ist die Implementation von generischen IS-Gateways vorzuziehen. Spätere Änderungen und Portierungen können so einfach durchgeführt werden. In konkreten Beispielen werden jedoch häufig spezifische IS-Gateways implementiert ([Ronchetti 95], [Barta, Hauswirth 95]). Als Grund wird oft angegeben, dass die Situation jedesmal anders sei. Dieser Argumentation muss jedoch widersprochen werden: Es gibt in den meisten Fällen genügend Gemeinsamkeiten, die eine Realisierung von generischen IS-Gateways nahelegen. Wenn im Einzelfall ein spezifisches IS-Gateway besser geeignet ist, lohnt sich mindestens während der Entwurfsphase die Verfolgung der hier vorgestellten Prinzipien. Im TSIMMIS-Projekt wird ein ähnlicher Ansatz verfolgt. Zwar werden spezifische IS-Gateways implementiert, die gemeinsamen Teile werden jedoch durch die Bereitstellung einer Programmbibliothek nur einmal implementiert [Papakonstantinou et al. 94].

Bsp.: Um Frau Müllers Problem zu lösen (Beispiel aus Abschnitt 1.2) wird die Informatikabteilung erst abklären, ob ein fertiges Produkt eingesetzt werden kann. Ein solches wird entweder genau auf die Situation (Excel, Mono-IS mit Datenzugang nur über die Benutzerschnittstelle) zugeschnitten sein (spezifisches IS-Gateway) oder muss zuerst an die spezielle Situation angepasst werden (generisches IS-Gateway). Falls kein Produkt verfügbar ist, wird ein Ingenieur wahrscheinlich möglichst schnell ein spezifisches (und daher unsystematisches) IS-Gateway entwickeln. Sobald das Problem aber firmenweit öfters in ähnlicher Form auftaucht, wird ein generischer Ansatz interessant.

3.2.2 Funktionalitätsumfang von Transformation und Vermittlung

Die dritte Dimension aus Bild 3.1 wird durch den Funktionalitätsumfang von Transformation und Vermittlung aufgespannt. Das IS-Gateway kann nämlich dem Clienten

die Funktion des angesprochenen Servers möglichst unverändert zur Verfügung stellen (verbindendes IS-Gateway),

die Serverfunktionen teilweise auf den Clienten ausrichten (Mischlösung) oder

nur normierte, clientorientierte Serverfunktionen anbieten (integrierendes IS-Gateway)


Bild 3.2 Funktionalitätsumfang von Transformation und Vermittlung3.2 Funktionalitätsumfang von Transformation und Vermittlung

Mit einem integrierenden IS-Gateway erscheint der Server aus der Sicht des Clienten als homogen und direkt auf den Clienten zugeschnitten. Alternativ sind IS-Gateways realisiert worden, welche die Unterschiede zum Server nicht vollständig verdecken. So müssen in letzterem Fall Aufträge an den Server in der Befehlssyntax des Servers formuliert werden. Das IS-Gateway übernimmt nur rudimentäre, syntaktische Konvertierungen. Das Ziel dabei ist, dem Clienten die volle Funktionalität des Servers zugänglich zu machen. Diese Art von IS-Gateways wird verbindende IS-Gateways genannt. Der Extremfall eines verbindenden IS-Gateways ist ein IS-Gateway, das sämtliche Kommunikation unverändert weitervermittelt. Solche IS-Gateways werden beispielsweise zum Überbrücken von Firewalls (3.3.6) eingesetzt. Dort wird nur zwischen erlaubter und unerlaubter Kommunikation an sich unterschieden.

Verbindende IS-Gateways befinden sich in der Bild 3.1 in der waagerechten Koordinatenebene, während integrierende IS-Gateways irgendwo im Raum darüber einzuordnen sind.

Sobald ein IS-Gateway Transformationen vornimmt, gehen allenfalls gewisse Serverfunktionen im IS-Gateway verloren. Andererseits können neue Funktionen dazukommen. Im allgemeinen werden dem Clienten nur Teile der ursprünglichen Funktionalität zur Verfügung stehen, in anderen Fällen jedoch auch neue Funktionen. Ein integrierendes IS-Gateway kann also im Funktionsumfang von einer Teilmenge bis zu einer Obermenge der Funktionen des Servers gehen.

Aufgrund der Definition eines IS-Gateways ist jedoch die Palette an zusätzlichen Funktionen eingeschränkt. Sobald ein Programm lokal auch Daten speichert, um beispielsweise benutzerspezifische Änderungen durchzuführen, handelt es sich nicht mehr um ein reines IS-Gateway, sondern um einen Agenten oder ein selbständiges Teilsystem.

3.3 Klassifikation nach IS-Gatewayfunktionalität

Bisher wurde der Funktionalitätsumfang von IS-Gateways sehr allgemein betrachtet, unabhängig davon, welche konkrete Aufgabe ein IS-Gateway übernimmt. In diesem Abschnitt werden IS-Gateways konkret nach ihrer Funktionalität klassifiziert. Die ersten drei Funktionen Synchronisations-, Zustands- und Befehlsvermittlung werden in der Folge unter dem Begriff Kommunikationsvermittlung zusammengefasst.

3.3.1 Synchronisationsvermittlung

Ein wichtiger Grund für den Einsatz von IS-Gateways ist die Vermittlung zwischen synchroner und asynchroner Kommunikation: Als synchrone Kommunikation wird im folgenden eine Kommunikation bezeichnet, bei welcher der Client empfangsbereit auf das Resultat einer Anfrage wartet. Entscheidend für die Synchronität ist dabei, dass der Kommunikationskanal zwischen Client und Server während der Anfrage offen bleibt, nicht aber, ob der Client in der Zwischenzeit etwas anderes tun kann (z. B. dem Endbenutzer den Abbruch ermöglichen). Das bekannte Beispiel für synchrone Kommunikation zwischen Menschen ist das Telefon. Bei asynchroner Kommunikation wird der Client die Verbindung zum Server nach dem Abschicken der Anfrage unterbrechen. Das entsprechende Beispiel dafür ist der Telefax. Nach dem Bearbeiten der Anfrage im Server wird dieser die Verbindung zum Clienten neu aufbauen und die Resultate übermitteln. Diese wichtige Eigenschaft - synchron oder asynchron - wird in SGIS wie folgt dargestellt:



Bild 3.3 Synchrone (1) und asynchrone (2) Kommunikation3.3

Eine ständig offene Verbindung wird im dynamischen Teil von SGIS durch ein durchlaufendes Band quer zu den einzelnen Meldungen dargestellt.


Die drei Hauptkommunikationsparadigmen, meldungsorientierte Kommunikation (asynchron), entfernte Prozeduraufrufe (synchron) und dialogbasierte Kommunikation (synchron), vertreten somit nicht einheitliche Kommunikationsarten. Die Vermittlung zwischen diesen verschiedenen Paradigmen der Kommunikation bildet eine Kernaufgabe für IS-Gateways.

Meldungsorientierte Kommunikation

In meldungsorientierten Systemen kommunizieren zwei Partner miteinander, indem sie sich Meldungen zukommen lassen. Die Mitteilungen werden beim Empfänger in Meldeschlangen zwischengespeichert, damit der Sender nicht auf die Antwort warten muss sondern weiterarbeiten kann. Sobald eine Meldung übertragen ist, wird die Verbindung unterbrochen (rechts in Bild 3.3). Die Kommunikation ist demnach asynchron und auch für sehr lose verbundene Systeme gut geeignet. Ein Spezialfall von meldungsorientierter Kommunikation ist die Object Request Broker Technologie (z. B. in CORBA). Die durch den Object Request Broker vermittelten Meldungen sind in diesem Fall nicht Meldungen im allgemeinen Sinne, sondern im objektorientierten Sinn, Aufrufe von Methoden von Objekten.


Bild 3.4 Meldungsorientierte Kommunikation3.4

Entfernte Prozeduraufrufe (RPC)

Entfernte Prozeduraufrufe (Remote Procedure Calls, RPC) kommen seit über einem Jahrzehnt in den meisten Datenverwaltungssystemen zum Einsatz. So verwundert es denn kaum, dass diese Technik für die Zusammenarbeit zwischen Teilsystemen sehr häufig verwendet wird. Bei der Kommunikation mit RPC wird für eine Interaktion (d. h. einen Prozeduraufruf) eine Verbindung durch den Clienten aufgebaut. Diese bleibt offen, bis der Server geantwortet hat (d. h. bis die Prozedur abgearbeitet ist). Danach wird die Verbindung durch den Server abgebrochen. Die Kommunikation erfolgt für jeden Prozeduraufruf synchron, deshalb ist die Anwendung auf eng verbundene Teilsysteme beschränkt.


Bild 3.5 Entfernte Prozeduraufrufe3.5

Bsp.: Die ODBC-Schnittstelle des Beispiels aus Abschnitt 1.2 ist ein typisches Beispiel für RPC. In ODBC stellt ein Client eine SQL-Anfrage an einen Server und wartet direkt auf die Antwort.

Dialogorientierte Kommunikation

Beim zweiten synchronen Verfahren, der dialogorientierten Kommunikation, geschieht die Kommunikation über einen fortlaufenden, direkten Dialog zwischen den Kommunikationspartnern. Der Verbindungskanal der beiden Partner bleibt dabei dauernd offen. Solche Dialoge werden beispielsweise durch die Verwendung von Pipes realisiert. Dies sind Kanäle, in die der eine Partner fortwährend hineinschreibt und aus denen der andere laufend liest. Für zweiseitige (bidirektionale) Kommunikation werden zwei Pipes benötigt. Die Gesprächssynchronisation muss durch die Partner explizit vorgenommen werden.



Bild 3.6 Dialogorientierte Kommunikation3.6 D

Bsp.: Im Beispiel aus Abschnitt 1.2 kann über eine Terminalemulation auf das Mono-IS zugegriffen werden. Eine solche Terminalemulation ist ein wichtiger Spezialfall dialogbasierter Kommunikation. Der Endbenutzer führt dabei den Dialog mit dem Server über seine Terminalemulation. Die gesamte Synchronisation wird durch den Server gesteuert. Solange der Endbenutzer nichts eingeben darf, ist das Terminal gesperrt, bzw. werden Endbenutzereingaben ignoriert.

3.3.2 Zustandsvermittlung

Neben der Synchronisationsvermittlung bildet die unterschiedliche Verwendung von Zustandsinformationen bei Client und Server einen zweiten wichtigen Grund für den Einsatz von IS-Gateways zwischen Informationssystemen.

Def.: Zustandsinformationen sind Daten, die ein Client oder Server über die aktuell stattfindende Kommunikation mit Partnern speichert.

Def.: Der Zustand ist die Menge aller gespeicherten Zustandsinformationen.

Ein Programm kommuniziert zustandsorientiert oder zustandslos, je nachdem, ob die Kommunikationsgestaltung von Zustandsinformationen über seine Partner abhängt oder nicht.



Bild 3.7 Zustandsorientierte und zustandslose Kommunikation3.7 Zustandsorientierte und zustandslose Kommunikation

Der Zusammenhang einzelner Meldungen wird im dynamischen Teil von SGIS durch Punkte dargestellt, die bei zustandsorientierter Kommunikation durch eine Linie verbunden sind, bei zustandsloser Kommunikation nicht.


Bsp.: Ein anschauliches Beispiel für unterschiedliche Zustandsorientierung bietet eine Fernschachpartie: Bei zustandsorientierter Kommunikation führen beide Spieler ein eigenes Schachbrett, übermittelt wird jeweils der neue Zug. Die Zustandsinformation ist auf dem Schachbrett gespeichert. Die Bedeutung (sogar die Korrektheit) eines Zuges ist abhängig vom momentanen Zustand des Schachbretts und somit von vorangegangenen Zügen. Bei zustandsloser Kommunikation wird jeweils die Stellung aller Figuren übermittelt. Der aktuelle Stand der Partie ist vollständig aus der neuesten Meldung ersichtlich, frühere Meldungen sind irrelevant.

In der folgenden Behandlung der Arbeitszustände wird nur der Server betrachtet; die Definitionen sind jedoch symmetrisch auch auf den Clienten übertragbar.

Def.: Ein Server, der keine Zustandsinformationen über die aktuell stattfindenen Sitzungen verwendet, heisst zustandsloser Server.

Ein zustandsloser Server hat (nach aussen) immer den gleichen Arbeitszustand. Er benützt für die Abarbeitung eines Arbeitsschritts keine Angaben über die Geschichte der bisherigen Kommunikation und reagiert auf eine gleiche Anfrage immer gleich. Ein zustandsloser Server kommuniziert somit immer zustandslos. (Intern kann der Server trotzdem Zustandsinformation speichern, z.B. Logs für spätere Analysen.)

Def.: Ein Server, der für die Kommunikationsgestaltung Zustandsinformationen aus vorangegangenen Arbeitsschritten speichert, heisst zustandsorientierter Server.

Der Serverzustand spiegelt somit immer die Geschichte der bisherigen Kommunikation. Die Reaktion auf eine neue Anfrage ist eine Funktion von Anfrage und aktuellem Zustand. Ein zustandsorientierter Server ändert auf Grund von Anfragen des Clienten seinen Zustand.

Diese Zustandsabhängigkeit ist bei Mono-IS mit aufeinander abgestimmten Informationssystemen und koordinierten Zuständen auf Server und Client unkritisch. In globalen IS mit ursprünglich nicht für die Zusammenarbeit entwickelten Teilsystemen fehlt jedoch diese Koordination. Die entsprechende zuverlässige und effiziente Abstimmung stellt hohe Anforderungen an die Konzeption eines IS-Gateways. Wenn Zustandsinformationen fehlen, muss das IS-Gateway eine genaue Kontrolle über den momentanen Zustand von Client und Server führen und auch in der Lage sein, diese Zustände nach Bedarf zu ändern.

Zustandsvermittelnde IS-Gateways kommen zwischen zustandsorientierten und zustandslosen Kommunikationsprotokollen zum Einsatz. Dies ist eine der schwierigsten Aufgaben für ein IS-Gateway.

Zustandsorientierter Client / zustandsloser Server

Im einfacheren Fall, mit zustandsorientiertem Protokoll auf der Clientseite und zustandslosem Protokoll auf der Serverseite, werden die Kommunikationsbedürfnisse durch den Clienten über ein zustandsorientiertes Protokoll angefordert. Das IS-Gateway verhält sich dabei gegenüber dem Clienten wie ein zustandsorientierter Server, d. h. es speichert Zustandsinformation über die aktuellen Kommunikationsbedürfnisse. Der Übergang in einen neuen Zustand des IS-Gateways geschieht durch eine einzige, zustandslose Anfrage an den Server. Diese ist definitionsgemäss unabhängig von früheren Anfragen und kann deshalb einfach formuliert werden. Das Resultat definiert den für den Client neu sichtbaren Zustand des IS-Gateways.

Zustandsloser Client / zustandsorientierter Server

Kritisch ist vor allem der Fall mit zustandsorientiertem Protokoll auf der Serverseite und zustandslosem Protokoll auf der Clientseite. Der Grund für diese Schwierigkeit liegt darin, dass die Kommunikation jeweils durch den Clienten initialisiert wird.

In diesem Fall werden die Kommunikationsbedürfnisse durch den Clienten über ein zustandsloses Protokoll angefordert. Das IS-Gateway wird nun eine zustandsorientierte Kommunikation mit dem Server aufbauen und die Anfrage des Clienten entsprechend weiterleiten. Aufgrund der vom Server erhaltenen Resultate wird das IS-Gateway eine Antwort an den Clienten zurückschicken. Problematisch wird es, wenn der Client aufgrund dieser Resultate eine neue Anfrage an den Server schicken will. Diese neue Anfrage ist, was die zustandslose Kommunikation zwischen Client und IS-Gateway betrifft, wiederum vollständig zustandslos. Der Server hat aber durch die erste Anfrage oder sogar in der verstrichenen Zeit seit der ersten Antwort den Zustand gewechselt. Da die Reaktion des zustandsorientierten Servers auf jede Anfrage von Anfrage und Serverzustand abhängt, muss notfalls die Anfrage des Clienten an den neuen Serverzustand angepasst werden, um das gewünschte Ziel zu erreichen. Dieses Problem ist nicht nur theoretischer Natur. So kann beispielsweise durch eine Zwischenspeicherung aller Anfragen und Resultate beim Clienten durch diesen plötzlich eine weitere Anfrage aufgrund "alter" Resultate erfolgen. Das IS-Gateway muss in diesem Fall den Server wieder in den "alten" (oder einen äquivalenten) Zustand zurückbringen.

3.3.3 Befehlsvermittlung

Auch bei Schnittstellen, die bezüglich der bisher diskutierten Kommunikationsmerkmale homogen sind, besteht immer noch die Heterogenität im Kommunikationsprotokoll. Um eine Kommunikation zwischen Client und Server zu ermöglichen, müssen auch die Steuerdaten transformiert werden. Einzelne Steuerbefehle mögen unterschiedlich heissen oder auf dem anderen System nicht existieren. In diesem Fall muss das IS-Gateway eine Umsetzung vornehmen und allenfalls einzelne Anweisungen des Clienten durch eine Serie von Anweisungen an den Server ersetzen. Diese Art Umsetzung kommt beispielsweise zwischen verschiedenen relationalen Datenverwaltungssystemen zum Zuge, falls diese nicht denselben SQL-Dialekt sprechen.



Bild  3.8 Beispiel für Befehlsvermittlung3.8 Beispiel für Befehlsvermittlung

3.3.4 Datenstrukturtransformation

Neben den bisher vorgestellten Aufgaben der Kommunikationsvermittlung gibt es eine weitere wichtige Funktion von IS-Gateways: die Transformation von Datenstrukturen. Der sachliche Inhalt (die Bedeutung) der transformierten Daten bleibt dabei soweit als möglich unverändert.

Einfache Datenstrukturtransformationen betreffen nur leichte Formatänderungen, wie beispielsweise das Anpassen von Tabellen an ein anderes Tabellenformat. Die nächste Stufe umfasst Transformationen zwischen abstrakten Datenstrukturen wie etwa derjenigen von Bäumen zu Listen und umgekehrt. Algorithmen, die solche Transformationen vornehmen, sind bereits häufig zweckmässig und gut beschrieben. Aufwendig wird die Transformation, wenn die Daten des Servers nicht in einer einfach strukturierten Form vorliegen.

Bsp.: Frau Müllers Excel (Abschnitt 1.2) erwartet die Verkaufszahlen in relationalen Tabellen. Die Daten des Mono-IS sind möglicherweise nicht in erster Normalform vorhanden und enthalten Repetitionsgruppen. Diese müssen erst durch das IS-Gateway in eine relationale Struktur gebracht werden.

Im Idealfall sind für beide Schnittstellen die Datenstrukturen detailliert definiert und dokumentiert. Einen Spezialfall bilden IS-Gateways, die serverseitig auf eine Benutzerschnittstelle zugreifen (Unterabschnitt 3.4.3). Im Gegensatz zu Programmschnittstellen sind bei Benutzerschnittstellen im allgemeinen keine präzisen Datenstrukturen definiert. Bei zeichenorientierten Benutzerschnittstellen bestehen die vom Server übermittelten Daten aus einer Folge von Bildschirmsteuerzeichen und Nutzdaten. Dieser String muss vom IS-Gateway analysiert werden, und es müssen Datenstrukturen erst aufgebaut werden.

Viele Datenstrukturtransformationen können durch ein IS-Gateway ohne Kenntnis des Inhalts durchgeführt werden. Schwieriger wird es, wenn die einzelnen Datenwerte detailliert analysiert werden müssen. Oft spielt die Struktur eines einzelnen Datenwerts, oder gar das Zeichenformat, in dem er kodiert ist, eine Rolle. Bei diesen Transformationen generisch Hilfe zu leisten ist verhältnismässig aufwendig, deshalb wird der situationsangepasste Teil eines IS-Gateways gerade in dieser Hinsicht leicht sehr umfangreich.

3.3.5 Realisation von zusätzlicher Funktionalität

IS-Gateways werden auch eingesetzt, um Dienste aus Servern auszulagern oder zusätzliche Dienste auf Servern aufzusetzen. Im letzteren Fall kann ohne Änderung am Server selbst dessen Dienstleistungsangebot erweitert werden. Wird dabei die Semantik der transformierten Daten beeinflusst, handelt es sich jedoch nicht mehr um ein IS-Gateway, sondern um eine mehrstufige Client-Server-Architektur. Beispiele für semantische Bedeutungsänderungen sind die Realisation von relationalen Joins über verschiedene Informationsserver oder von "Anwendungslogik" wie die Sicherstellung von referentieller Integrität durch Löschen von Informationen auf dem Informationsserver ("cascading Deletes").

Beispiele für in IS-Gateways ausgelagerte Dienstleistungen sind Concurrency Control oder die Realisation von zusätzlichen Datentypen (z. B. Binary Large Objects, BLOBS). Als Beispiel sei auf die Realisation einer Transaktionsverwaltung für einen Informationsserver verwiesen, der selber nicht über die dazu notwendigen Konzepte verfügt [Wunderli 96]. Dabei geht es um die Kooperation von CAD-Programmen (Computer Aided Design), Teiledatenbanken und weiteren Programmen, die im Rahmen eines CIM-Projekts (Computer Integrated Manufacturing) zusammenarbeiten müssen.

Bsp.: Ein Beispiel von zusätzlicher Funktionalität ist beispielsweise das "Rückwärtsblättern" auf einem Datenbestand, dessen Datenverwaltungssystem nur cursororientierte Abfragen unterstützt. Das IS-Gateway kann dabei die gewünschte Funktion für den Clienten unsichtbar durch jeweiliges erneutes Lesen der Datensätze bis zum vorhergehenden Datensatz simulieren.



Bild 3.9 "Rückwärtsblättern" durch das Gateway3.9 "Rückwärtsblättern" durch das Gateway

3.3.6 Sicherheit

Voraussetzung für jede Kommunikation zwischen Client und Server ist ein Datennetz, es sei denn, die beiden Programme laufen bereits auf demselben Computer. Die zunehmende Verbreitung von öffentlichen Datennetzen machen deren Benutzung auch für nichtöffentliche Zwecke immer attraktiver. Dabei können IS-Gateways für Abgrenzungs- und Prüffunktionen eingesetzt werden. So können beispielsweise zwei IS-Gateways je am Ende des öffentlichen Teils der Übertragungsleitung die übertragenen Daten auf hoher Abstraktionsstufe verschlüsseln beziehungsweise entschlüsseln.



Bild
 3.10 Verschlüsselung durch Gateways3.10 Verschlüsselung durch Gateways

Um ein internes Datennetz gegenüber öffentlichen Datennetzen abzuschirmen, werden sogenannte Firewalls als Schranken am Übergang der beiden Netze errichtet. Der direkte Zugriff von einem Netz auf ein anderes kann durch einen Firewall unterbunden werden. Um beispielsweise externen Kunden einer Firma den Zugriff auf firmeninterne Informationsserver zu ermöglichen, kann auf dem Firewall ein IS-Gateway installiert werden. Die Kunden greifen dann auf das IS-Gateway zu, welches ausschliesslich kontrollierte Zugriffsmöglichkeiten bietet.

Obiges Beispiel weist auf eine weitere Verwendung von IS-Gateways hin: die Benutzeridentifikation. Diese wird im allgemeinen auch über das IS-Gateway abgewickelt. Somit "weiss" das IS-Gateway, wie sich ein Client bei einem Server identifiziert. Das kann bei einfacheren Identifikationsverfahren (z. B. ein gleichbleibendes Passwort) ein Sicherheitsproblem darstellen. Diese Problematik wird im Rahmen dieser Arbeit nicht weiter behandelt. Bei der Implementation eines konkreten IS-Gateways muss sie jedoch allenfalls berücksichtigt werden.

3.3.7 Zwischenspeicherung

Ausserhalb der bisherigen IS-Gateway-Definition kann eine Art "erweitertes IS-Gateway" mit Cache-Funktion realisiert werden. Antworten von Informationsservern werden dann nicht nur an den Clienten weitergeleitet, sondern gleichzeitig lokal beim IS-Gateway zwischengespeichert. Falls dieselbe Anfrage zu einem späteren Zeitpunkt nochmals auftritt, wird anstelle einer erneuten Anfrage an den Server die zwischengespeicherte Antwort verwendet. Ein solches IS-Gateway kann sowohl die Belastung des Servers als auch des Netzes zwischen IS-Gateway und Server senken. Andererseits entstehen bei dieser Zwischenspeicherung völlig neue Probleme (Redundanz, Mutationsanomalien). Dieses Anwendungsgebiet wird hier nicht mehr weiter behandelt.

3.4 Klassifikation nach Entwurfsvarianten

Die folgenden Klassifikationskriterien hängen weniger mit der Flexibilität oder Funktionalität des IS-Gateways zusammen als mit Alternativen in der technischen Realisierung. Dabei geht es nicht um Details wie die verwendete Programmiersprache, sondern beispielsweise darum, ob ein Gateway zustandsorientiert arbeitet.

3.4.1 Zustandsorientierung im IS-Gateway

Wie ein Server oder ein Client kann auch ein IS-Gateway zustandsorientiert oder zustandslos arbeiten. Da ein IS-Gateway sich in einem globalen IS an die existierenden Clienten und Server anpassen muss, ist die Ausprägung dieses Kriteriums abhängig von den jeweiligen Rahmenbedingungen. So erzwingt ein zustandsorientiertes Kommunikationsprotokoll auf der Clientseite ein zustandsorientiertes IS-Gateway, weil das IS-Gateway auch die notwendigen Zustandsinformationen speichern muss. Umgekehrt verlangt ein zustandsorientiertes Protokoll auf der Serverseite nicht unbedingt ein zustandsorientiertes IS-Gateway. Dies liegt daran, dass das IS-Gateway die gesamte Zustandsinformation aus der Kommunikation mit dem Server zum Clienten schicken kann, der sie speichert und im Bedarfsfall mit seiner nächsten Meldung wieder zurückschickt. Der tiefere Grund für diese Asymmetrie liegt wiederum darin, dass die Kommunikation durch den Client initiiert und kontrolliert wird.

3.4.2 Beständigkeit von IS-Gateways

Ein wichtiges Klassifikationsmerkmal von IS-Gateways ist die Beständigkeit des Programms. Beständige IS-Gateways laufen über längere Zeit, flüchtige IS-Gateways werden nur zur Abarbeitung einer einzelnen Anfrage gestartet.


Bild 3.11 Beständigkeit bei IS-Gateways3.11 Beständigkeit bei IS-Gateways

Wie das Zustandskriterium ist auch die Beständigkeit abhängig von gewissen Randbedingungen: Sobald das IS-Gateway lokal Angaben (insbesondere Zustandsinformationen) speichern muss, kommt ein flüchtiges IS-Gateway nicht mehr in Frage. Ein zustandsorientiertes IS-Gateway erzwingt somit ein beständiges IS-Gateway. Die Zusammenhänge zwischen zustandsorientierten, bzw. zustandslosen Clientprotokollen und IS-Gateways sowie der Beständigkeit zeigt Bild 3.12
Clientprotokoll
IS-Gateway
Zustände
Beständigkeit
zustandslos
flüchtig
zustandslos
beständig
zustandsorientiert
beständig
zustandsorientiert
zustandsorientiert
beständig

Bild 3.12 Zustandsorientierung und Beständigkeit
zwischen Client und IS-Gateway im Überblick3.12 Zustandsorientierung und Beständigkeit zwischen Client und IS-Gateway

3.4.3 Verwendete Serverschnittstelle

Ein IS-Gateway in einem globalen IS soll auf einen Server zugreifen können, ohne dass an diesem Änderungen notwendig sind. Als Schnittstelle zum Server ergeben sich prinzipiell verschiedene Möglichkeiten: Benutzer-, System- oder Datenschnittstelle. Nicht immer sind alle verfügbar. Bei bestehenden Systemen besteht oft nur eine einzige Möglichkeit eines Ansatzpunkts für das IS-Gateway. Im folgenden werden nun verschiedene Variationen aus der Sicht des IS-Gateways diskutiert. Eine vertiefte Betrachtung der verschiedenen Möglichkeiten im Spezialfall von W3-Browsern als Clienten enthält [Perrochon 95c].

Daten-Gateways

Daten-Gateways greifen direkt auf die Daten des Informationsservers zu (Bild 3.13). Dies ist nur dann möglich, wenn die Struktur dieser Daten bekannt ist und direkt auf die Daten zugegriffen werden darf. Das Praxisbeispiel 3 eines IS-Gateways, StD, liefert ein Beispiel für den Entwurf, die Entwicklung und den Einsatz eines Daten-Gateways.


Bild 3.13 Daten-Gateway3.13 Daten-Gateway
Systemschnittstellen-Gateways

Wenn der Informationsserver ein Datenverwaltungssystem enthält, erfolgen korrekterweise alle Datenzugriffe über das Datenverwaltungssystem. Dieser Ansatz, dargestellt in Bild 3.14, entspricht der Idee der Trennung von Datenhaltung und Anwendungsprogrammen. Das neu dazukommende IS-Gateway verhält sich in diesem Fall wie ein weiteres Anwendungsprogramm. Beispiele für Systemschnittstellen-Gateways liefern alle Hersteller von Datenverwaltungssystemen, die auf solche anderer Hersteller zugreifen können.


Bild 3.14 Systemschnittstellen-Gateway3.14 Systemschnittstellen-Gateway
Benutzerschnittstellen-Gateways

Falls ein monolithischer Informationsserver von aussen einzig über eine Benutzerschnittstelle zugänglich ist, muss ein IS-Gateway direkt auf diese zugreifen und dabei das Verhalten eines Endbenutzers simulieren (Bild 3.15).

Das Praxisbeispiel 1 eines IS-Gateways, TS/IDLE, liefert ein Beispiel für den Entwurf und die Entwicklung eines generischen Benutzerschnittstellen-Gateways. Dabei wird die Benutzerschnittstelle in der formalen Sprache IDLE beschrieben [Perrochon, Fischer 95]. Aufgrund dieser Beschreibung greift das IS-Gateway dann auf den Informationsserver zu. Auch [Ronchetti 95], [Lin, Chung 95], [Barta, Hauswirth 95] beschreiben spezifische Benutzerschnittstellen-Gateways, die aber ohne den Zwischenschritt einer formalen Beschreibung realisiert wurden.



Bild 3.15 Benutzerschnittstellen-Gateway3.15 Benutzerschnittstellen-Gateway

3.5 Die Rolle der Semantik in IS-Gateways

Die Definition des IS-Gateways schliesst Änderungen in der Semantik der transformierten Daten durch ein IS-Gateway ausdrücklich aus. Trotzdem können strukturelle Änderungen an Daten Auswirkungen auf die Semantik dieser Daten haben. Schon eine Strukturänderung von einem Baum zu einer verketteten Liste kann auf verschiedene Arten geschehen (je nachdem in welcher Reihenfolge die Blätter des Baumes angesprochen werden). Handelt es sich nun dabei bereits um eine unzulässige Bedeutungsänderung? Ist nur der Inhalt der Blätter gesucht, so spielt die Struktur für die Bedeutung keine Rolle. Eine reine Zeichencodeänderung wie die Transformation zwischen HTML-Code (z. B. ü=ü) und ISO Latin-1 Code (ü=0xFC) kann aber semantisch bereits bedeutsam werden, sobald nicht alle Zeichen abbildbar sind. Änderungen in der Semantik müssen deshalb immer im Kontext gesehen werden und sind innerhalb eines IS-Gateways zuzulassen, solange sie im Rahmen des Verwendungszwecks keine relevanten Bedeutungsänderungen zur Folge haben.

Eine andere Rolle spielt die Bedeutung der Daten für die Durchführung der Transformation selbst. Prinzipiell sollte das IS-Gateway unabhängig von der Bedeutung der Daten arbeiten. Gerade weil aber die Transformation semantikerhaltend sein soll, muss die Bedeutung der Daten trotzdem oft bekannt sein. Allgemein wird eine Transformation, die völlig ohne Rücksicht auf die konkrete Bedeutung der Daten durchgeführt wird, nur ansatzweise möglich sein. Auf die Bedeutung der Semantik wird nicht näher eingegangen. Verwiesen sei aber etwa auf [Sheth 91], [Sheth, Kashyap 92] und [Wiederhold 94].

3.6 Komponenten eines IS-Gateways

3.6.1 Die IS-Gateway Referenzarchitektur

In diesem Abschnitt wird eine Referenzarchitektur für den Aufbau eines generischen IS-Gateways definiert. Sie ist schematisch in Bild 3.16 dargestellt. Die Referenzarchitektur beschreibt ein IS-Gateway durch grundlegende Elemente, die dazwischenliegenden Schnittstellen und dem Zusammenwirken der Elemente. Dadurch wird keine physische Implementation vorweggenommen. Im konkreten Einzelfall werden eventuell nicht alle Elemente benötigt oder einzelne Elemente zusammengelegt. Die Elemente der Referenzarchitektur sind Programm-Module und Datenbestände:

Die Programm-Module erbringen die Funktionalität,

die statischen Datenbestände beschreiben jeweils die Eigenheiten von Client und Server sowie die notwendigen Transformationen, und

die dynamischen Datenbestände speichern die aktuellen Zustandsinformationen über IS-Gateways und Kommunikation.

Idealerweise kann ein universelles generisches IS-Gateway implementiert werden, das mit einer passenden Beschreibung zwischen beliebigen Clienten und Servern vermitteln kann. Dieses hochgesteckte Ziel ist jedoch höchstens mit unverhältnismässigem Aufwand zu erreichen. Zu gross sind die Unterschiede zwischen beliebigen Servern. Generische IS-Gateways, die auf gewisse Klassen von Clienten und Servern beschränkt sind, können jedoch mit vertretbarem Aufwand implementiert werden. Dies zeigten die Erfahrungen bei den im Rahmen dieser Arbeit realisierten IS-Gateways. "Teure" Aspekte in der Realisation von IS-Gateways - wie die integrierte Behandlung von zustandslosen und zustandsorientierten Servern - werden hier nicht durch eine umfangreiche Serverbeschreibung und ein komplexes universelles IS-Gateway realisiert, sondern werden durch die Verwendung eines spezialisierten IS-Gateways aufgefangen. Die Beschreibung von Client und Server beschränkt sich somit im wesentlichen auf die client- und serverspezifischen Steuerbefehle und deren Befehlssyntax. Des weiteren gehören Kontrollsignale für die Steuerung der Kommunikation und Vorschriften für die Transformation dazu.

Im folgenden werden die einzelnen Elemente der Referenzarchitektur beschrieben. Die Funktionsweise wird am Beispiel einer Clientanfrage an den Server beschrieben. Für die Antwort des Servers gelten dieselben Betrachtungen.



Bild 3.16 Referenzarchitektur für IS-Gateways3.16 Referenzarchitektur für IS-Gateways

Transformationsvorschrift (TV)

Die TV ist das Kernstück jedes IS-Gateways. Sie definiert einerseits, wie die Nutzdatenstrukturen von Server und Client aufeinander abgebildet werden, und andererseits, wie die Steuerbefehle des Clienten auf dem Server auszuführen sind. Die TV ist statisch, sie ändert sich also zur Laufzeit nicht.

Bsp.: Im Beispiel aus Abschnitt 1.2 gibt die TV an, wie eine ODBC-Anfrage durch das IS-Gateway zu interpretieren ist, damit die entsprechenden Daten in einer Folge von simulierten Endbenutzerbefehlen aus dem Mono-IS geholt werden können.

Konzeptionell wichtig für ein generisches IS-Gateway ist, dass die Transformationsvorschrift austauschbar und vom Programmcode des IS-Gateways unabhängig ist. In vielen Fällen wird die Transformationsvorschrift direkt ins Programm kodiert. Eine fehlende Trennung von Programmen und Daten innerhalb des IS-Gateways rächt sich bei notwendigen Anpassungen der TV. Die Programmiersprache IDLE [Perrochon, Fischer 95] ist ein Beispiel für eine systemunabhängige Sprache zur Definition einer beliebigen TV. Die in IDLE definierte TV wird dann durch das IS-Gateway interpretiert. Die beiden IS-Gateways StD und WAB enthalten weitere Beispiele.

Beschreibung des Clienten (BC) und Servers (BS)

Diese Beschreibungen umfassen die Spezifikationen der client- und serverseitigen Schnittstellen. Diese Angaben sind statisch und ändern sich während der Laufzeit des IS-Gateways nicht. In die Beschreibung ist alles eingeschlossen, was für eine erfolgreiche Kommunikation mit dem Clienten oder dem Server notwendig ist Sie erfolgt jedoch in einer allgemeinen Form, die gemäss den dynamisch zur Laufzeit erwachsenden Anforderungen parametrisiert werden kann. In einer gelungenen IS-Gateway-Implementation kann die Beschreibung des Servers ausgetauscht und mit demselben IS-Gateway auf einen ähnlichen Server zugegriffen werden.

Bsp.: Das IS-Gateway zur Lösung von Frau Müllers Problem (Abschnitt 1.2) wird clientseitig ein auf ODBC spezialisiertes IS-Gateway aufweisen, BC ist demnach relativ einfach. BS enthält die Angaben für die Kommunikation mit dem Mono-IS, also die zur Simulation des Verhaltens des Endbenutzers notwendigen Befehle in geeigneter Form.

Kommunikation mit Client (KC) und Server (KS)

KC und KS sind die zwei Programm-Module, welche die Kommunikation mit dem Clienten und dem Server basierend auf den Angaben in BC bzw. BS realisieren. Sie sorgen nötigenfalls für die Pufferung von Datenströmen, liefern aber prinzipiell den gesamten Datenstrom unverändert weiter. Diese beiden Module kapseln auch alle Details der verwendeten Protokolle vom Transformer-Modul ab (Netzadressen, Datenüberprüfung, etc.). Soweit möglich ist dabei auf den zur Verfügung stehenden Protokollen aufzubauen.

Zustandsinformationen über Client (ZC) und Server (ZS)

Sofern auf der einen oder anderen Seite zustandsorientierte Kommunikation notwendig ist, müssen die entsprechenden Zustandsvariablen im IS-Gateway nachgeführt werden. Häufig geschieht dies implizit in Form von Programmzuständen. Konzeptionell werden die Zustände in ZC und ZS gespeichert. Diese Daten sind dynamisch und widerspiegeln jederzeit den aktuellen Stand der Kommunikation mit dem Clienten bzw. dem Server.

Transformer

Der Transformer analysiert basierend auf den Beschreibungen BC bzw. BS die von KC bzw. KS erhaltenen Datenströme und filtert die Steuerdaten heraus. Diejenigen Teile des Datenstroms, die Metadaten oder Nutzdaten enthalten, werden aufgrund der Beschreibungen BC bzw. BS weiter analysiert. Der Transformer baut dabei mit Hilfe allenfalls vorhandener Metadaten eine Nutzdatenstruktur auf. Diese Struktur wird gemäss der Transformationsvorschrift (TV) in die vom Server verlangte Nutzdatenstruktur transformiert.$Letztere wird anschliessend gemäss den Beschreibungen BS bzw. BC abgebaut und an den Server geschickt.

3.6.2 Das Zustandsdiagramm eines IS-Gateways

Ein IS-Gateway nach obiger Referenzarchitektur kann als endlicher Automat mit einem internen Zustandsdiagramm wie auf Bild 3.17 aufgefasst werden. Die Zustände (weisse Kästchen in Bild 3.17) stellen interne Zustände des IS-Gateways dar. Sie haben keinen direkten Zusammenhang mit den extern sichtbaren Zuständen aus der obigen Diskussion über (extern) zustandsorientierte/-lose IS-Gateways oder Kommunikation. In jedem Zustandskästchen sind in der untersten Zeile die benötigten Datenbestände des IS-Gateways angegeben. Die drei waagerechten Blöcke in Bild 3.17 stimmen mit den drei Komponenten KC, Transformer und KS überein.

Die verschiedenen Entwurfsvarianten aus Abschnitt 3.4 führen zu folgendem Unterschied im Zustandsdiagramm der verschiedenen Varianten von IS-Gateways (vgl. auch Bild 3.12):

Fall 1: Ein flüchtiges (und damit gemäss Bild 3.12 extern zustandsloses) IS-Gateway terminiert nach dem letzten Zustand eines jeden Zyklus ("Daten senden"). Die nächste Anfrage von einem Clienten startet eine neue Instanz des IS-Gateways.

Fall 2: Ein beständiges und extern zustandsloses IS-Gateway kehrt nach dem letzten Zustand des Zyklus' ("Daten senden") wieder in den Startzustand zurück und wartet auf die nächste Anfrage.

Fall 3: Ein beständiges und extern zustandsorientiertes IS-Gateway kehrt nach einem Zyklus nicht wieder in denselben internen Startzustand zurück, sondern in einen ähnlichen, der sich vom internen Startzustand nur um die externe Zustandsänderung unterscheidet. Danach wird ein analoger Zyklus durchlaufen, dabei werden die gleichen (internen) Zustände jedoch mit unterschiedlicher externer Zustandsinformation durchlaufen.



Bild 3.17 Zyklisches Zustandsdiagramm eines IS-Gateways3.17 Zyklisches Zustandsdiagramm eines IS-Gateways

Im folgenden werden die internen Zustände auf der linken Seite des Zustandsdiagramms einzeln beschrieben. Für die Zustände auf der rechten Seite gelten analoge Beschreibungen mit Vertauschen von Client und Server.

Daten empfangen

In diesem internen Zustand liest die KC-Komponente Daten vom Client ein, dekodiert sie nach der Beschreibung BC und leitet die Daten weiter an den Transformer. Falls aufgrund der Erkenntnisse des Transformers für eine korrekte Anfrage noch Daten fehlen, können Nachfragen an den Client gesendet werden, um fehlende Information zu beschaffen.

Strukturaufbau

In diesem internen Zustand wird durch den Transformer eine Nutzdatenstruktur der Beschreibung BC aufgebaut. Wenn nicht genügend Daten für den Aufbau der erwarteten Datenstruktur vorhanden sind, werden weitere Daten vom Clienten über KC angefordert.

Transformation

Der Transformer wandelt nun die Nutzdatenstruktur gemäss den Einträgen in der TV um. Weitere Angaben werden falls nötig aus BC oder BS bezogen.

Strukturabbau

Hier wird die Nutzdatenstruktur durch den Transformer gemäss der Beschreibung BS wieder aufgebaut und für die Übermittlung zum Server vorbereitet.

Daten senden

In diesem internen Zustand werden die Daten des Transformers an den Server übermittelt.

3.7 Multigateways

Der Wunsch, auf mehrere Datenbanken gleichzeitig zuzugreifen ist alt. Er führte unter anderem zu verteilten, föderierten oder Multidatenbanken. Dieser Wunsch bildet auch die Motivation zur Einführung von Multigateways. Wie aber schon beim einfachen IS-Gateway steht beim Multigateway die Überbrückung von Kommunikationsbarrieren zwischen Clienten und Servern im Vordergrund und nicht die Realisation von grundlegenden Datenzugriffsfunktionen, wie sie von Datenverwaltungssystemen angeboten werden.

Def.: Ein Multigateway ist ein IS-Gateway zwischen einem Clienten und mehreren Servern.

Multigateways treten also gleichzeitig mehreren Servern gegenüber als Client auf (Bild 3.18). Für den Clienten ist dabei nicht sichtbar, dass er auf mehrere Server zugreift. Für ihn funktioniert alles gleich wie beim Zugriff auf einen Server beziehungsweise auf ein normales IS-Gateway. Er kommuniziert ausschliesslich mit dem Multigateway, das die Kommunikation mit den einzelnen Servern übernimmt.


Bild 3.18 Multigateway3.18 Multigateway

Multigateways erlauben es einem Clienten, ohne Änderungen gleichzeitig und integriert auf mehrere Server zuzugreifen. Es handelt sich dabei jedoch nicht einfach um mehrere unabhängige IS-Gateways, welche an denselben Clienten angebunden sind. Ein Beispiel für ein solches Multigateway ist das Praxisbeispiel 1 LibAgent [Müller 96].

Wenn der Client eine Anfrage an einen Server stellt, wird diese vom Multigateway an die einzelnen Informationsserver weitergeleitet. Die Informationsserver geben die Antwort an das Multigateway zurück. Dieses führt die Antworten zusammen und gibt sie an den Clienten weiter.

Eine besondere Schwierigkeit bei Multigateways bildet die systematische Integration der verschiedenen Server. Diese Aufgabe wird innerhalb des Multigateways in einen Integrationsteil und einen Transformationsteil aufgeteilt. Wie Bild 3.19 illustriert, bestehen Multigateways aus einem Gatewaymanager und mehreren Subgateways. Der Gatewaymanager übernimmt alle Aufgaben der Integration und Kontrolle der einzelnen Subgateways. Die Subgateways sind normale IS-Gateways, wie sie in den vorhergehenden Abschnitten diskutiert wurden. An der Stelle des Clienten steht der Gatewaymanager. Serverseitig greift je ein Subgateway auf einen der Server des Multigateways zu. Es ist denkbar, dass Subgateways mit völlig unterschiedlichen Servern verbunden sind. Beispielsweise kann ein Subgateway mit einem zustandsorientierten und ein anderes gleichzeitig mit einem zustandslosen Server verbunden sein.


Bild 3.19 Multigateway-Architektur3.19 Multigateway-Architektur

Der Gatewaymanager empfängt eine Anfrage des Clienten und leitet sie unverändert an alle angeschlossenen Subgateways weiter. Nach der Behandlung der Anfrage durch den Server werden die Teilantworten im Multigateway zu einer Antwort an den Client zusammengestellt. Dazu werden zunächst alle Teilantworten von den Subgateways in eine einheitliche Form gebracht. Dann werden die Antworten vom Gatewaymanager gesammelt, zusammengestellt und an den Clienten weitergeleitet.


Bild 3.20 Architektur des Gatewaymanagers3.20 Architektur des Gatewaymanagers

Obige Architektur eines Gatewaymanagers gleicht auf der linken Seite der Referenzarchitektur für IS-Gateways. Die Komponenten KC, BC und ZC entsprechen genau ihren Pendants in Bild 3.16. Neu ist eine Datenkomponente "Integrationsvorschrift" (IV), welche die Vorschriften zur Integration von Antworten enthält, und ein Programmodul "Resultatintegration". Einfache Integrationsverfahren sind beispielsweise das unbesehene Weiterleiten der Antworten an den Clienten oder die Beschränkung auf das Aussortieren von Duplikaten. Kompliziertere Verfahren versuchen, die verschiedenen Resultate nach inhaltlichen Kriterien zu ordnen. Welche Variante gewählt wird, hängt von der jeweiligen Situation und dem Verwendungszweck der Antwort ab.

In globalen IS wie W3 ist ein gelegentlicher Ausfall von einzelnen Servern sehr wahrscheinlich. Multigateways sollten deshalb in dieser Hinsicht robust arbeiten. Insbesondere darf das Funktionieren des Multigateways durch den Ausfall eines einzelnen Servers nicht gefährdet sein.

3.8 Schlussfolgerungen aus Kapitel 3

Im Zusammenhang mit der zweiten der drei Hypothesen aus Abschnitt 1.3 ist der Unterabschnitt 3.4.3 interessant: Die Hypothese lautete:

Hypothese 2:
Durch den Einsatz von IS-Gateways ist prinzipiell jedes Informationssystem in ein globales Informationssystem integrierbar.

In Unterabschnitt 3.4.3 wurden verschiedene Varianten diskutiert, wie ein Mono-IS als Server in ein globales IS eingebunden werden kann. Dafür wurden im wesentlichen drei Angriffspunkte unterschieden:

Direktzugriff auf die Daten,

Zugriff über eine Systemschnittstelle oder

Zugriff über eine Benutzerschnittstelle.

Jedes Mono-IS verfügt mindestens über eine Schnittstelle, da ansonsten die darin gespeicherte Information dem Endbenutzer nicht zugänglich wäre. Das Praxisbeispiel 1 TS/IDLE, zeigt auf, wie generische IS-Gateways auf Benutzerschnittstellen realisierbar sind. Somit ist ein globales IS, das auf beliebige bestehende Informationssysteme aufbaut, zumindest bezüglich der hier behandelten Punkte realisierbar. Offen bleiben Fragen bezüglich der Organisation und der Semantik.

Heute kommerziell erhältliche Produkte stellen relativ hohe formale Anforderungen an die zu integrierenden Informationssysteme. So werden relativ moderne Systemschnittstellen vorausgesetzt, die oft auf SQL basieren. Auch sind kaum kommerzielle Produkte für die Integration von älteren, selbstentwickelten Mono-IS verfügbar.

4 DIE SPRACHE IDLE


4.1 Zweck

IDLE (Interface Description LanguagE) ist eine formale Sprache für die Beschreibung von Benutzerschnittstellen von Mono-IS. Diese formale Beschreibung ist namentlich dann wichtig, wenn von einem Clienten aus ein Mono-IS als Server benützt werden soll und dazu die Benutzerschnittstelle verwendet werden muss. Das entsprechende IS-Gateway muss dann serverseitig das Verhalten eines Endbenutzers simulieren, was mit IDLE direkt möglich ist. [Perrochon, Fischer 95].


Bild
 4.1 Das IDLE-Programm simuliert einen Endbenutzer4.1 Das IDLE-Programm simuliert einen Endbenutzer

4.2 IDLE-Konzepte

4.2.1 Kapselung der Kommunikation mit Client und Server

IDLE ist für den IS-Gateway-Entwickler deshalb interessant, weil die Einzelheiten der Kommunikation soweit als möglich im IS-Gateway gekapselt werden. So können sowohl die IDLE-Programme als auch die IS-Gateways wiederverwendet werden:

Ein einzelnes IDLE-Programm kann durch unterschiedliche IS-Gateways verschieden umgesetzt werden.

Bsp.: In einem IDLE-Programm werden clientseitig Masken für Benutzereingaben clientunabhängig definiert. Ein IS-Gateway kann diese Masken einem W3-Browser in Form eines HTML-Dokuments zustellen. Ein anderes IS-Gateway könnte dasselbe IDLE-Programm abarbeiten und die Eingabemasken in Sprache umwandeln und dem Clienten die mündliche Anfrage zum Abspielen schicken. So kann ein einziges IDLE-Programm in verschiedenen IS-Gateways für verschiedene Clienten eingesetzt werden.

Ein einzelnes Gateway kann verschiedene IDLE-Programme interpretieren.

Bsp.: Das Praxisbeispiel 1, TS/IDLE, kann beliebige IDLE-Programme interpretieren. So wurden IDLE-Programme für verschiedene Mono-IS entwickelt, die alle auf der durch TS/IDLE bereitgestellten Funktionalität basieren.

Zur Kommunikation mit dem Clienten genügt die abstrakte Darstellung der gefundenen Informationen und die Spezifikation der benötigten Eingaben des Endbenutzers. Der IDLE-Interpreter kann diese Angaben dann in die für den Clienten geeignete Form transformieren und sie übermitteln.

Zur Kommunikation mit dem Server wird auf das Konzept des "Streams" zurückgegriffen. Ein IDLE-Programm braucht einen solchen Stream nur zu öffnen und kann dann Zeichen durch einfach Lese- und Schreiboperationen an den Server übertragen.

IDLE ist prinzipiell eine offene Sprache. Häufig erfolgt jedoch die Kommunikation über Benutzerschnittstellen zustands- und dialogorientiert. Clientseitig werden in globalen Informationssystemen heute meist zustandslose, RPC-artige Protokolle eingesetzt. IDLE wurde deshalb für den Einsatz in IS-Gateways optimiert, die zwischen zustandsloser, RPC-artiger Kommunikation auf der Clientseite und zustands- sowie dialogorientierter Kommunikation auf der Serverseite vermitteln. Ein solcher IDLE-Interpreter wurde im IS-Gateways TS/IDLE realisiert.

4.2.2 Phasen

Die IDLE-Beschreibung einer Benutzerschnittstelle entspricht einem Programm, das sowohl den Zugriff auf diese Benutzerschnittstelle als auch die Umsetzung und Aufbereitung von Daten für den Clienten formal beschreibt. Ein IDLE-Programm gliedert sich in verschiedene Phasen. Die Phasen entsprechen dabei den Prozeduren in blockorientierten Programmiersprachen. Diese Phasen werden in zwei Gruppen eingeteilt, je nachdem ob sie mit dem Clienten oder mit dem Server zusammenarbeiten.

Jede Phase in IDLE ist entweder eine BACKPHASE oder eine FRONTPHASE. In den BACKPHASEN wird die Zusammenarbeit mit dem Server abgewickelt, während in den FRONTPHASEN die Zusammenarbeit mit dem Clienten stattfindet. Die Transformation der Daten kann entweder in der FRONTPHASE oder in der BACKPHASE stattfinden. In der Programmausführung folgt jeder BACKPHASE eine FRONTPHASE und umgekehrt.

Der Programmlauf beginnt mit einer BACKPHASE namens START. Diese wird aufgerufen, sobald eine Anfrage eines Clienten eintrifft. Beendet wird die Verarbeitung des IDLE-Programms, wenn in einer Phase keine nächste Phase aufgerufen wird. Der Aufruf einer nächsten Phase ist dabei nicht gleichzusetzen mit einem Prozedur- oder Unterprogrammaufruf. Bei einem FRONT- oder BACK-Statement wird die aktuelle Phase beendet und die nächste Phase gestartet. Nach der Abarbeitung einer Phase wird nicht in die vorangegangene Phase zurückgesprungen.

Jeder Pfeil in Bild 4.2 stellt einen Interaktionsschritt eines längeren Dialogs zwischen Client und Server dar. Die einzelnen Schritte haben die folgenden Bedeutungen:

1. Der Endbenutzer aktiviert in seinem Browser einen Befehl und verlangt einen Dienst, welcher über ein IDLE-basiertes IS-Gateway zugänglich ist. Der Browser schickt die entsprechende Anfrage an das IS-Gateway. Dies wird als Erstanfrage bezeichnet. Darauf lädt das IS-Gateway die Beschreibung der Benutzerschnittstelle des verlangten Dienstes (ein IDLE-Programm), analysiert dieses und führt es aus.


Bild 4.2 Phasen in IDLE4.2 Phasen in IDLE

2. Anschliessend wird die BACKPHASE START aufgerufen. Dabei wird Kontakt mit dem Informationsserver aufgenommen und erste Daten werden vom Informationsserver bezogen. Nun erfolgt der Wechsel zur ersten FRONTPHASE.

3. Wenn das IS-Gateway in der FRONTPHASE auf einen Aus-/Eingabebefehl (PAGE) stösst, erzeugt das Gateway aus den erhaltenen Daten des Informationsserver die Antwort für den Browser. Diese Antwort wird durch das IS-Gateway an den Browser übermittelt. Das IDLE-Programm wird innerhalb des PAGE-Befehls angehalten. Der Browser präsentiert die erhaltenen Daten dem Endbenutzer. Das IS-Gateway wartet nun auf eine Antwort. Erfolgt innerhalb eines vordefinierten Zeitrahmens keine solche, erfolgt ein Time-Out; auf dessen Behandlung wird weiter unten eingegangen.

4. Der Endbenutzer erteilt nun weitere Befehle. Jede solche Anfrage heisst Folgeanfrage. Das IDLE-Programm kann nun den PAGE Befehl zu Ende bearbeiten. Das IS-Gateway stellt fest, dass es sich um eine Folgeanfrage handelt und startet deshalb keine neue Verbindung mit dem Server, sondern übermittelt die erhaltenen Daten zum wartenden Server und fordert weitere Daten an.
Sobald alle Daten zusammengetragen sind, wird das IDLE-Programm erneut einen PAGE-Befehl ausführen, um sie an den Browser zu senden.

Bsp.: In diesem Kapitel wird als Beispiel die IDLE-Beschreibung des Informationssystems SVI-Kurs in der ursprünglichen Form auf ezInfo präsentiert. Bild 4.3 zeigt einen Bildschirmausdruck der entsprechenden zeichenbasierten Benutzerschnittstelle (links Bild 4.3) sowie das Resultat der Transformation nach W3 (rechts in Bild 4.3). In W3 sind die unterstrichenen Wörter Hyperlinks. Wenn der Benutzer auf einen Eintrag in der Liste klickt, erhält er Detailinformationen zur entsprechenden Veranstaltung.

Die IDLE-Beschreibung von SVI-Kurs ist vollständig im Anhang B zu finden. Zeilennummern in den folgenden Programmauszügen im Text verweisen auf die entsprechenden Zeilen im Anhang B.

Bild 4.3 SVI-Kurs auf ezInfo (links) und W3 (rechts)4.3 SVI-Kurs auf ezInfo und W3

Bsp.: Das Beispiel SVI-Kurs gliedert sich in die folgenden Phasen: BACKPHASE START, FRONTPHASE Auswahl, BACKPHASE Detail, FRONTPHASE ZeigeDetail und BACKPHASE dummy. Die letzte Phase ist dabei notwendig, damit nach der FRONTPHASE ZeigeDetail ohne eine weitere BACKPHASE direkt wieder die FRONTPHASE Auswahl aufgerufen werden kann.

4.2.3 Variablen

Es gibt in IDLE nur einen Typ von Variablen: String-Listen. Aus diesem Grund müssen Variablen nicht deklariert werden.

Neben den String-Listen gibt es zusätzlich das implizite Konstrukt des Single-Strings, den gewisse Funktionen als Argument verlangen. Ein einzelner String kann mit FIRST und LAST aus einem Ausdruck (expr) von String-Listen erzeugt werden. Auch eine Text-Konstante ist ein Single-String. Single-Strings existieren nur als Textkonstanten und während der Evaluation von Ausdrücken.

Folgende Funktionen sind auf String-Listen definiert:

var := expr
Dies ist die Zuweisung. Wenn unter dem Namen var noch keine Variable existiert, wird eine neue angelegt. Sonst wird der bisherige Wert der Variable var überschrieben. Die Variable var enthält nach der Zuweisung eine Kopie der Liste expr.
Im folgenden Beispiel wird die Text-Konstante "mehr" der Variablen vorw zugewiesen. Diese enthält danach eine String-Liste mit einem einzigen Element.

16.	vorw := "mehr";

var := ADD(e1,e2)
Kopien zweier String-Listen werden aneinandergehängt und zurückgegeben. Es wird kein Test auf Duplikate durchgeführt.
Im folgenden Beispiel werden die Strings aus item an die String-Liste list angehängt.

49.			list := ADD (list, item);

var := DEL(e1,e2)
Die Strings in e2 werden für diese Operation als Suchmuster aufgefasst. DEL löscht in einer Kopie der Liste e1 alle Strings, auf die ein Muster aus e2 passt. Das Resultat wird als Liste zurückgegeben.
Im folgenden Beispiel werden die Strings aus item aus der String-Liste list gelöscht. (Dieses Beispiel stammt nicht aus svi.idle.)

				list := DEL (list, item);

var := CONCAT(e,s)
Der String s wird an jeden einzelnen String in e angehängt. s muss ein Single-String sein.
Im folgenden Beispiel wird die Text-Konstante "v" an alle Strings in id angehängt.

26.			id := CONCAT (id, "v");

var := LEFTOF(e,s)
Es werden alle Strings in e nach s durchsucht. Wird das Suchmuster in einem String gefunden, wird ein String aus allen Zeichen links des Suchmusters zurückgegeben. Wird das Suchmuster in mehreren Strings gefunden, werden entsprechend mehrere Strings zurückgegeben. Falls das Muster in keinem String gefunden wird, wird nichts zurückgegeben.
Im folgenden Beispiel werden alle Strings in item nach ESC durchsucht ("\27" ist die Darstellung für das nichtdruckbare Zeichen "ESC"). Kommt ESC in einem String vor, werden alle Zeichen links davon als neuer String in das Resultat übernommen. Die resultierende String-Liste wird item wieder zugewiesen.

44.			item := LEFTOF (item, "\27");

var := RIGHTOF(e,s)
Es werden alle Strings aus e nach s durchsucht. Wird das Suchmuster in einem String gefunden, wird ein String aus allen Zeichen links des Suchmusters zurückgegeben. Wird das Suchmuster in mehreren Strings gefunden, werden entsprechende mehrere Strings zurückgegeben. Falls das Muster in keinem String gefunden wird, wird nichts zurückgegeben.
Im folgenden Beispiel werden alle Strings in item nach "!" durchsucht. Kommt "!" in einem String vor, werden alle Zeichen rechts davon als neuer String in das Resultat übernommen. Die resultierende String-Liste wird id zugewiesen.

64.			id   := RIGHTOF(item, "!");

var := BETWEEN(e,s,s)
Wie RIGHTOF und LEFTOF, aber es werden stringweise allfällige Zeichen zwischen den beiden Suchmustern zurückgegeben.
Im folgenden Beispiel werden score alle Zeichen aus x zwischen "   " (drei Leerschläge) und "  [a-zA-Z]" (zwei Leerschläge, gefolgt von einem beliebigen Buchstaben) zugewiesen. (Dieses Beispiel stammt nicht aus svi.idle.)

				score := BETWEEN (x, "   ", "  [a-zA-Z]");

var := FIRST(expr)
Gibt den ersten String aus expr zurück. Ist expr leer, so wird ein leerer String zurückgegeben.
Im folgenden Beispiel wird der erste String aus id an item angehängt.

46.			item := CONCAT (item, FIRST (id));

var := LAST(expr)
Gibt den letzten String aus expr zurück. Ist expr leer, so wird ein leerer String zurückgegeben.
Im folgenden Beispiel wird der erste String aus id an item angehängt. (Dieses Beispiel stammt nicht aus svi.idle.)

				item := CONCAT (item, LAST (id));

Bsp.: Der folgende Auszug aus der BACKPHASE Detail zeigt anhand des Einlesens des Titels einer Veranstaltung den Umgang mit String-Listen. Zuerst werden die Daten des Servers bis zur Folge "ESC[5;14H" ("\27" ist die Darstellung für das nichtdruckbare Zeichen "ESC") gelesen. Diese Folge bereitet im regulären Einsatz das Terminalprogramm des Endbenutzers auf die Ausgabe des Titels vor. Danach wird in Zeile 89 der Titel der Veranstaltung in die Variable title eingelesen und in Zeile 90 das letzte Zeichen (ESC) abgetrennt. Die folgenden Zeilen 91-94 zeigen wie das IDLE-Programm herausfindet, ob der Titel eine zweite Zeile hat. Falls ja, wird dieser in Zeile 96 an title angehängt. Zeile 144 aus der FRONTPHASE ZeigeDetail enthält dann die entsprechende Weitergabe an den Clienten.

88.	READ UPTO "\27\[5;14H";   (* Start of title *)
89.	READ UPTO "\27" INTO title;
90.	title := LEFTOF (title, "\27");
91.	READ UPTO "\27\[6;";
92.	READ COUNT 1 INTO tmp;
93.	READ UPTO "H";
94.	IF tmp = "1" THEN         (* Title has 2nd line *)
95.		READ UPTO "\27" INTO title2;
96.		title := ADD (title, LEFTOF (title2, "\27"));
97.	END;
		...
144.		OUTPUT HEADER 1 title;

4.3 Syntax von IDLE

Die EBNF-Beschreibung von IDLE in Bild 4.4 beschreibt die IDLE-Syntax vollständig. Die Einschränkungen, die in der Syntax nicht ausgedrückt werden können, werden in Abschnitt 4.4 diskutiert.


InterfaceDescription = [ errorphase ]



{ (BACKPHASE | FRONTPHASE) name


BEGIN stmseq END }.

stmseq = stm { ";" stm }.

stm = var ":=" expr |

OPEN [ fileid ]

(FILE string | PORT string num) |

CLOSE [ fileid ] |

WRITE [ fileid ] (expr | NULLBYTE) |

READ [ fileid ]

( COUNT num | UPTO expr )

[ INTO var ] |

IF condition THEN stmseq

[ ELSE stmseq ] END |

FOREACH var IN expr DO stmseq END |

WHILE condition DO stmseq END |

PAGE stmseq END |

OUTPUT [outcontrol] expr |

INPUT incontrol argpairs INTO var |

PRINT expr |

BACK name |

FRONT name |

RESUME.

outcontrol = TITLE | HEADER ["1"-"6"] | PREDEFINED.

incontrol = STRING | PASSWORD | MENU | CHECK |

RADIO | REF.

errorphase = ERRORPHASE errorseq BEGIN stmseq END.

errorseq = errorstm { ";" errorstm }.

errorstm = TIMEOUT (FRONT | BACK) "(" num "," string ")" |

ERROR (READ | OPEN) argpairs.

condition = expr relation expr | expr CONTAINS string.

relation = "=" | "#".

expr = var | string | function.

function = (ADD | DEL) arg2e |

(CONCAT | RIGHTOF | LEFTOF) arg2s |

BETWEEN arg3.

string = text | ( ( FIRST | LAST ) arg1 ).

arg1 = "(" expr ")".

arg2e = "(" expr "," expr ")".

arg2s = "(" expr "," string ")".

arg3 = "(" expr "," string "," string ")".

argpairs = "(" string "," string { "," string "," string } ")".

fileid = num.

var = name.

name = "a"-"Z" | "_" { "a"-"Z" | "0"-"9" | "_" }.

num = { "0"-"9" }

text = '"' { character } '"'.

comment = "(*" { character } "*)".



Zeichenerklärung:


[…] Eingeschlossener Teil ist optional


{…} Eingeschlossener Teil kann beliebig oft wiederholt werden (0 bis n).

A | B Entweder A oder B


"a"-"Z" Auswahl aus Bereich: "a" | "b" | … | "Z"


Bild 4.4 Syntax von IDLE4.4 Syntax von IDLE

Die EBNF-Definition spiegelt den grundsätzlichen Aufbau eines IDLE-Programms in Phasen. In der EBNF-Definition aus Bild 4.4 bedeutet "character" ein beliebiges Zeichen des Zeichensatzes. Mit "\mnn" (mit m>0), "\0kkk" (k ein Oktalzeichen) oder "\xhh" (h ein Hexadezimalzeichen) können in IDLE auch Zeichen spezifiziert werden, die sonst nicht eingegeben werden können (z.B. ESC) oder innerhalb eines Programms keine oder eine andere Bedeutung haben (z.B. Zeilenumbruch).

4.4 Semantische Bedeutung der IDLE-Befehle

In diesem Abschnitt wird auf die Bedeutung der IDLE-Befehle eingegangen.

4.4.1 Kontrollstrukturen

In IDLE existieren nur wenige Strukturen zur Kontrolle des Programmablaufs. Es sind dies IF zur bedingten Durchführung, FOREACH als Iterator über String-Listen, und WHILE für sonstige Programmschleifen.

Bedingt durch das einfache Variablenkonzept sind für den Vergleich innerhalb der Kontrollstrukturen nur drei Vergleichsoperatoren notwendig:

var1 = var2
Die beiden Variablen werden auf vollständige Gleichheit aller Strings der String-Listen überprüft (inklusive Reihenfolge der Strings). Wird kein Unterschied gefunden, wird die Bedingung WAHR.
Das folgende Beispiel führt einen Vergleich der einelementigen Liste nr mit der Text-Konstante "V" durch.

23.		IF nr = "V" THEN

var1 # var2
Die beiden Variablen werden auf vollständige Gleichheit aller Strings der String-Liste überprüft (inklusive Reihenfolge der Strings). Wird ein Unterschied gefunden, wird die Bedingung WAHR.
Das folgende Beispiel führt einen Vergleich der einelementigen Liste wahl mit der Text-Konstante "stop" durch.

69.	IF wahl # "stop" THEN

var CONTAINS string
Wenn einer der Strings der String-Liste var auf das Suchmuster string passt, wird die Bedingung WAHR. Wenn das Suchmuster string leer ist, wird die Bedingung FALSCH.
Die WHILE-Schleife im folgenden Beispiel wird so oft durchlaufen wie "v" in pages vorkommt, weil in jedem Durchlauf ein Vorkommen von "v" aus pages entfernt wird.

78.	WHILE pages CONTAINS "v" DO
			...
81.		pages := RIGHTOF (pages, "v");
82.	END;

IF cond THEN stmseq1 [ ELSE stmseq2 ] END

Die Befehlsfolge stmseq1 wird nur ausgeführt, wenn cond WAHR ist. Ansonsten wird (sofern vorhanden) stmseq2 ausgeführt. Bsp.

29.				IF weiter = "1" THEN
30.					weiter := "0";
31.				ELSE
32.					vorw := "";
33.				END;

FOREACH var IN expr DO stmseq END

FOREACH ist ein Iterator über String-Listen. Der Ausdruck expr wird ausgewertet und die stmseq wird für jeden String, den der Ausdruck enthält, einmal ausgeführt. Die Variable var dient als Schleifenvariable und enthält jeweils den aktuellen String (und nur diesen). Ein früherer Wert von var wird überschrieben und nach der Schleife behält var den letzten Wert. Im folgenden wird die FOREACH-Schleife für jeden String in list einmal ausgeführt. Jeder dieser Strings wird item zugewiesen und innerhalb der Schleife in zwei weitere Variablen zerlegt.

62.		FOREACH item IN list DO
63.			text := LEFTOF (item, "!");
64.			id   := RIGHTOF(item, "!");
65.			INPUT REF (FIRST (text), FIRST (id)) INTO wahl;
66.		END;

WHILE cond DO stmseq END

Die Befehle im Körper einer WHILE-Schleife werden solange ausgeführt, bis die Bedingung im WHILE-Kopf nicht mehr erfüllt ist. Endlosschleifen werden durch den IDLE-Interpreter nicht erkannt. Im folgenden Beispiel wird die WHILE-Schleife solange ausgeführt, als vorw aus einem einzigen String "mehr" besteht..

20.	WHILE vorw = "mehr" DO
     	...
51.	END;

4.4.2 Umgang mit Streams

Ein Stream ist ein abstrakter Datentyp für eine fortlaufende, prinzipiell unbegrenzte Folge von Zeichen. Ein Stream ermöglicht, dass Zeichen in derselben Reihenfolge gelesen werden, wie sie in den Stream geschrieben werden. Wird versucht, mehr Zeichen zu lesen als geschrieben worden sind, tritt ein Fehler auf (vgl. 4.4 Fehlerbehandlung). Streams in IDLE dienen primär der Kommunikation mit dem Server, aber auch Lesen und Schreiben von lokalen Dateien erfolgen über Streams. Einige wenige Befehle erlauben ein einfaches Streamhandling.

OPEN/CLOSE

Mit OPEN PORT wird ein Stream als Verbindung zum Server geöffnet, auf welchen dann geschrieben und von dem gelesen werden kann.
Mit OPEN FILE wird eine lokale Datei für Schreib- und Lesezugriff geöffnet. Existiert unter dem angegebenen Namen keine Datei, so wird eine neue erzeugt.

READ

READ liest von einem Stream; dabei muss angegeben werden, wie weit gelesen werden soll. Dies kann entweder über die Anzahl zu lesender Bytes geschehen (COUNT), oder über ein Suchmuster, bei dessen Auftreten gestoppt wird (UPTO). Der Lesevorgang wird dabei erst nach dem Lesen des Suchmusters beendet; beim nächsten Lesevorgang wird das erste Zeichen nach dem gefundenen Suchmuster gelesen.

WRITE

WRITE schreibt auf einen Stream, bis entweder alle Zeichen geschrieben sind oder ein Fehler auftritt (z. B. weil die Verbindung unterbrochen wurde oder das Speichermedium voll ist).

WRITE NULLBYTE muss verwendet werden, um das Zeichen "\0" auf einen Stream zu schreiben. ("\0" kann nicht innerhalb eines Strings verwendet werden, weil es das Ende des Strings bezeichnet).

Bsp.: Nachdem in Zeile 4 des folgenden Ausschnitts eine Verbindung mit dem Mono-IS ezInfo aufgebaut wurde, folgt der Anmeldeprozess. Dieser wird in einem gegenseitigem Dialog durchgeführt. Dabei müssen der Benutzername und der Terminaltyp angegeben werden. Anschliessend liest das IDLE-Programm bis zur Eingabeaufforderung "ezInfo>". "EXT SVI" startet nun SVI-Kurs. ">" ist die Eingabeaufforderung von SVI-Kurs. Mit dem Befehl "4" wird dann die Liste aller Veranstaltungen angefordert.

4.	OPEN PORT "ezinfo.ethz.ch" 23;
5.	WRITE "\r\n";
6.	READ UPTO "Username: ";
7.	WRITE "GAST\r\n";
8.	READ UPTO "\27\[c";		(* Query device attributes *)
9.	WRITE "\27[?1;2c";		(* Complete vt100 *)
10.	READ UPTO "ezInfo>";
11.	WRITE "EXT SVI\r\n";
12.	READ COUNT 100;
13.	READ UPTO ">";
14.	WRITE "4";

4.4.3 Kommunikation mit dem Clienten

Die Kommunikation mit dem Clienten geschieht über die drei IDLE-Befehle PAGE, INPUT und OUTPUT. Sie erlauben eine sehr abstrakte Präsentation transformierter Daten und die Darstellung von Eingabemasken. Die konkrete Transformation in ein bestimmtes clientseitiges Datenformat (z.B. HTML) geschieht durch das IS-Gateway.

PAGE

Der PAGE-Befehl wirkt wie ein Puffer: Die Argumente aller OUTPUT- und INPUT-Befehle innerhalb eines PAGE-Befehls werden "gesammelt", damit sie dem Clienten zusammen übergeben werden können. Der PAGE Befehl ist nur in FRONTPHASEN erlaubt. Die stmseq zwischen PAGE und END wird als PAGE-Block bezeichnet. Enthält die PAGE-Beschreibung kein INPUT-Statement, wird keine Reaktion des Endbenutzers abgewartet; das IDLE-Programm wird sofort weiter abgearbeitet.

INPUT

INPUT definiert Elemente, die den Endbenutzer zur Eingabe auffordern. INPUT ist nur innerhalb von PAGE-Blöcken zugelassen. In einem INPUT-Befehl können mehrere Einträge (Felder) definiert werden. Ein INPUT-Feld vom Typ RADIO mit mehreren Einträgen verhält sich wie ein Block von sich gegenseitig ausschliessenden RADIO-Buttons. Jedes INPUT Element erwartet die Argumente in Paaren. In jedem Argumentenpaar ist das erste Argument ein Text, der das INPUT Feld beschreibt (Eingabeaufforderung); das zweite Argument bezeichnet den Rückgabewert des Feldes.

Bsp.: Bei den Eingabeelementen rechts in Bild 4.3 handelt es sich um Hyperlinks, die durch den Endbenutzer angesprochen werden können. Sie können mit folgenden IDLE-Befehlen erzeugt werden.

INPUT REF ("19.01.95 : Workgroup und Workflow", "1",
           "25.01.95 : Geo-Information in der Schweiz", "2",
           "25.01.95 : Digitaler Druck", "3",
           "01.02.95 : Programmation Windows", "4",
           "09.02.95 : Brush Up für Informatikleiter", "5")
			INTO wahl;

Dabei wird als erstes Argument jeweils der Text für den Hyperlink angegeben, als zweites Argument der Wert, der zurückgegeben wird, falls der Endbenutzer den betreffenden Hyperlink anspricht.

Folgende Feldtypen stehen in IDLE zur Verfügung:

STRING
Der Endbenutzer wird zur Eingabe einer Zeichenkette aufgefordert.

PASSWORD
Funktioniert wie STRING, aber die Zeichen werden bei der Eingabe nicht angezeigt. Dieser Feldtyp wird beispielsweise für Passworte verwendet.

MENU
Die jeweils ersten Strings der Argumentenpaare werden in einem Menü dargestellt. Wird ein Punkt dieses Menüs gewählt, wird der zugehörige Bezeichner zurückgegeben.

CHECK
Die jeweils ersten Strings der Argumentenpaare sind die Beschreibungen der CHECK-Boxen. Die zugehörigen Bezeichner aller gewählten CHECK-Boxen werden als Liste zurückgegeben.

RADIO
Die jeweils ersten Strings der Argumentenpaare sind die Bezeichnungen der RADIO-Buttons. Der zugehörige Bezeichner des gewählten RADIO-Buttons wird zurückgegeben.

REF
Die jeweils ersten Strings der Argumentenpaare werden als Hyperlink auf weitere Informationen angezeigt. Falls der Endbenutzer einen dieser Hyperlinks anwählt, wird der zugehörige Bezeichner zurückgegeben.

Durch diese Semantik der INPUT-Felder ist es möglich, die Resultate aller INPUT-Felder der gleichen Variablen zuzuweisen. Sofern alle Bezeichner voneinander verschieden sind, kann nach der Bearbeitung der PAGE einfach festgestellt werden, was gewählt wurde.

OUTPUT

OUTPUT ist ebenfalls nur innerhalb von PAGE-Blöcken zugelassen. Der OUTPUT-Befehl dient dazu, Text oder Information aus der BACKPHASE zum Clienten zu übertragen. Der Text (bzw. die aus der expr resultierenden Strings) wird als Fliesstext in die Seite eingebunden. Mit einem optionalen Kontrolltyp kann das Aussehen eines solchen Blockes beeinflusst werden. Die Kürzel haben dabei die folgenden Bedeutungen:

TITLE
Der Text wird als Titel der Seite angezeigt.

HEADER 1-6
Der Text wird als Überschrift in sechs wählbaren Stufen ausgegeben.

PREDEFINED
Der Text wird nicht formatiert und in einer Nichtproportionalschrift ausgegeben.

Die resultierende Darstellung der Information beim Endbenutzer hängt stark von den Möglichkeiten des Clienten und der Implementation des IDLE-Interpreters ab.

Bsp.: Der untenstehende PAGE-Block ergibt eine Liste wie sie rechts in Bild 4.3 dargestellt ist. Der Titel wird von einem W3-Browser in der Titelzeile des Fensters dargestellt. Darauf folgt ein Titel 1. Stufe und eine Liste mit Referenzen auf weitere Seiten. Diese Referenzen bestehen aus den Titeln der entsprechenden Veranstaltungen.

59.	PAGE
60.		OUTPUT TITLE "SVI-Kurs";
61.		OUTPUT HEADER 1 "List of All Events";
62.		FOREACH item IN list DO
63.			text := LEFTOF (item, "!");
64.			id   := RIGHTOF(item, "!");
65.			INPUT REF (FIRST (text), FIRST (id)) INTO wahl;
66.		END;
67.		INPUT REF ("Stop the svi-script.", "stop") INTO wahl;
68.	END;
69.	IF wahl # "stop" THEN
70.		BACK Detail;
71.	END;

4.4.4 Fehlerbehandlung

ERRORPHASE

Die ERRORPAHSE dient ausschliesslich der Fehlerbehandlung. Diese spezielle Phase besteht aus zwei Teilen, dem Initialteil und dem Reaktionsteil. Der Initialteil umfasst eine Folge von speziellen Fehlerbefehlen (errorseq) vor BEGIN, der Reaktionsteil eine Folge von normalen IDLE-Befehlen (stmseq) zwischen BEGIN und END. Ein IDLE-Programm kann (muss aber nicht) mit einer ERRORPHASE beginnen.

Bevor die erste reguläre Phase abgearbeitet wird (FRONTPHASE START), wird geprüft, ob eine ERRORPHASE vorhanden ist. Falls dem so ist, wird zuerst der Initialteil abgearbeitet. Danach folgt die Phase START. Der Reaktionsteil wird erst aufgerufen, wenn ein Fehler auftritt.

In IDLE sind die folgenden ERROPHASE-Befehle vorgesehen:

TIMEOUT FRONT / BACK

Diese Befehle definieren, wie lange auf eine Antwort gewartet werden soll. Der Parameter string ist ein Bezeichner, der bei Eintreten eines Timeouts in die vordefinierte Variable IDLE_ERROR abgelegt wird. Diese Variable kann dann im Reaktionsteil abgefragt werden.

ERROR READ / OPEN

Damit können Paare der Form {fehlersymptom, id} angegeben werden. Bei jedem READ und OPEN wird dann laufend überprüft, ob eines der Fehlersymptome aufgetreten ist. Falls dies der Fall ist, so wird die Bearbeitung der aktuellen Phase unterbrochen, die vordefinierte Variable IDLE_ERROR erhält die passende id und der Reaktionsteil wird abgearbeitet.

RESUME

Der RESUME-Befehl ist nur im Reaktionsteil einer ERRORPHASE zugelassen. Kommt RESUME zur Anwendung, so wird die Bearbeitung der ERRORPHASE beendet und die dadurch unterbrochene Phase wird weiter bearbeitet.

4.4.5 Verschiedenes

Kommentare

Kommentare sind nur zwischen Statements erlaubt. Sämtliche Zeichen in Kommentaren werden ignoriert und haben keine Auswirkung auf das IDLE-Programm. Kommentare können auch innerhalb von anderen Kommentaren stehen.

1.	(* Demonstration of IDLE: A Description of SVI-Kurs *)

2.	BACKPHASE START
3.	BEGIN (* Open the service (* Let's go *) *)

PRINT expr

PRINT gibt die aus der expr resultierenden Strings lokal auf dem Gatewayrechner aus und erlaubt ein einfaches Protokollieren von Ereignissen.

5 PRAXISBEISPIELE


5.1 Umfeld der Praxisbeispiele, W3

Nach den allgemeiner gefassten theoretischen Grundlagen werden in Kapitel 5 ausgewählte konkrete Implementationen von IS-Gateways vorgestellt. In allen Fällen ging es darum, konkrete Informationsbedürfnisse mit verfügbaren Systemkomponenten (Mono-IS oder Teilen von Mono-IS) abzudecken und mittels IS-Gateways in World Wide Web (W3) einzubinden [Berners-Lee et al. 94], [Perrochon 95a]. Für Kommunikationsaspekte wird deshalb die Terminologie von Internet verwendet.

5.1.1 W3 als globales Informationssystem

Die Gründe für die Wahl von W3 wurden schon in Abschnitt 1.4 diskutiert und werden hier nicht mehr wiederholt. Einige für den allgemeinen Erfolg von W3 wichtige Punkte sind aber auch hier nochmals zu erwähnen:

World Wide Web basiert ausschliesslich auf flachen Dateien, die durch das Betriebssystem verwaltet werden. Schutzmassnahmen wie Transaktionsverwaltung und Konsistenzprüfungen, die jedes moderne Datenverwaltungssystem zur Verfügung stellt, sind nicht vorhanden. Die Beschränkung auf Dateien führt zu einem statischen Informationsangebot.

Auf alle Daten wird physisch über die Speicheradresse und nicht logisch über einen Namen zugegriffen. Dafür wurden sogenannte Universal Resource Locators (URL) eingeführt. Diese definieren durch Zugriffsprotokoll, Serveradresse und weitere auf den Server bezogene, lokale Adressangaben jedes Dokument in W3 eindeutig.

Die gespeicherten Daten sind nicht wie in Datenbanksystemen strukturiert. Jedes Dokument in W3 kann einen anderen Aufbau haben. Die Beschreibung der Daten wird deshalb in jedem Dokument zusammen mit den Daten selbst gespeichert. Dies wird weiter unten noch ausführlicher diskutiert.

Nun gibt es gute Gründe, Daten mittels Datenverwaltungssystemen zu speichern. Daten sind normalerweise sehr wartungsintensiv, und der gleichzeitige Zugriff von mehreren Endbenutzern kann zu Konsistenzproblemen führen. So ist es sinnvoll, klassische Datenbanken, die selber Mono-IS sind, als Server in W3 einzubinden. Dadurch kann die gesamte bisherige Funktionalität konsistenzerhaltender Datenverwaltungssysteme aufrecht erhalten werden; gleichzeitig können die Daten aber über eine moderne, weltweit und auf allen Rechnerplattformen verfügbare Benutzerschnittstelle zur Verfügung gestellt werden. Für die notwendigen Transformationen werden IS-Gateways eingesetzt.

Entstehung und stürmische Entwicklung machen es schwierig, W3 eine Theorie oder ein mathematisches Modell zugrunde zu legen. W3 basiert aber auf eigenen und auf in anderem Zusammenhang erfolgreichen Konzepten. Im folgenden wird kurz auf die wichtigsten Konzepte eingegangen.

5.1.2 Client-Server-Architektur

In W3 betreibt der Endbenutzer lokal auf seinem Rechner einen Browser. Dieser übernimmt die Interaktion mit dem Endbenutzer und baut nur bei Bedarf kurzfristig eine Verbindung zu einem W3-Server auf. Die Programme, die bisher als W3-Server auftreten, sind normalerweise speziell für W3 entwickelt worden.

Der Browser hat die Möglichkeit, wahlweise auf beliebige W3-Server zuzugreifen. Er wählt aufgrund der Suchfrage denjenigen W3-Server aus, der die verlangten Dokumente speichert, eröffnet eine Verbindung zu diesem W3-Server, verlangt eine Kopie des gewünschten Dokuments und wartet. Der Server wird das Dokument übertragen und die Verbindung abbrechen. Für diese Kommunikation zwischen Client und Server wurde für W3 ein neues zustandsloses Kommunikationsprotokoll entwickelt, das Hypertext Transfer Protocol (HTTP). Diese Art der Kommunikation entspricht den entfernten Prozeduraufrufen (RPC).

5.1.3 Datenbeschreibungen in W3

Grundidee der Datenspeicherung in W3 ist, dass jedes Dokument nebst den Nutzdaten (Texte, Bilder, usw.) auch die zu deren Verständnis notwendigen Beschreibungen enthält. Dazu dient in W3 die Sprache HTML (Hypertext Markup Language). In HTML-Dokumenten wird jede Zeichenfolge der Nutzdaten von einem Label begleitet, das die Bedeutung der Zeichenfolge beschreibt. So ist beispielsweise der Titel eines Dokuments durch <TITLE> markiert. Ein separates, übergeordnetes, starres Datenschema ist somit unnötig. Jedes Dokument enthält direkt sein eigenes Schema. Labels übernehmen die Rolle der Attributnamen. Zur Beschreibung vieler, gleichartig strukturierter Daten, wie sie in Datenbanken vorkommen, ist HTML allerdings ungeeignet.

Aufgrund dieses Konzepts kann ein Dokument aus seinem Inhalt bereits vollständig verstanden werden. Darüber hinaus besteht eine Vernetzungsmöglichkeit zwischen verschiedenen Dokumenten. Diese wird durch Hyperlinks realisiert, die in W3 die Rolle der Fremdschlüssel im Relationenmodell übernehmen. Eine referenzielle Integrität wird jedoch durch W3 in keiner Weise sichergestellt.

Die Gemeinsamkeiten der verschiedenen "Objekte" beschränken sich auf Ähnlichkeit in den Strukturen. Beispielsweise muss das <TITLE>-Attribut innerhalb des <HEADER>-Attributs auftreten. Neben einer solchen Schachtelung von Attributen sind auch Wiederholungen von einzelnen Attributen möglich.

Eine solche Datenorganisation eignet sich besonders gut für reine Leseoperationen. W3 ermöglicht jedoch nicht nur Lesezugriffe, sondern auch Informationsflüsse vom Clienten zum Server. HTML stellt dafür Elemente zur Verfügung, mit denen Eingabemasken systemunabhängig definiert werden können.

5.1.4 Gateways in W3

In W3 wurde von Anfang an versucht, neben Dokumenten, wie sie in 5.1.3 beschrieben wurden, auch andersartige, aber von den Endbenutzern gefragte Informationsdienste nutzbar zu machen. 'bullet', 'button', 'logo', 'icon', 'image', 'Images' So kann in einem HTML-Dokument ein Verweis auf ein inkompatibles System, z. B. ETHICS, stehen. Nach dem Anwählen wird ein weiteres Programm gestartet, in diesem Falle eine Terminalemulation, die mit ETHICS kommuniziert. Obwohl diese Art der Behandlung bestehender Dienste oft "Integration" genannt wird, erscheint dieser Begriff für eine solch schwache Kopplung nicht angebracht.

Das Grundprinzip von W3, die Übermittlung von Dokumenten des Servers auf Anfrage des Clienten, reicht alleine für den Zugriff auf Mono-IS nicht aus. Der Client muss erweiterte Möglichkeiten haben, auf dem Serverrechner Hilfsprogramme zu starten. Mit CGI, dem Common Gateway Interface [CGI 96], wurde dazu schon sehr früh eine normierte Schnittstelle geschaffen. Dabei startet auf Anfrage des Clienten der W3-Server ein Hilfsprogramm (Bild 5.1). Der Zugriff auf das zu integrierende Mono-IS geschieht durch dieses Hilfsprogramm. Die Resultate der Anfrage an das Mono-IS werden direkt durch das Hilfsprogramm ohne Änderungen durch den W3-Server an den Clienten zurückgeschickt. Danach terminiert das Hilfsprogramm. Mit CGI können zustandslose, flüchtige Gateways implementiert werden.



Bild 5.1 CGI-basierte IS-Gateways in W35.1 CGI-basierte IS-Gateways in W3

Neuerdings sind verschiedene andere Ansätze, insbesondere die Integration von Server und Gateway, ausprobiert worden und stehen teilweise auch zur Verfügung [Perrochon 95d]. Neue Ansätze erlauben auch beständige Gateways.

5.1.5 Java          

In W3 können heute dank der Programmiersprache Java [Java 95] plattformunabhängige Benutzerschnittstellen zu Informationssystemen entwickelt werden, deren Funktionalität über HTML hinausgeht. Im Praxisbeispiel 2, LibAgent, wurden mit Java neue Möglichkeiten für die Einbindung bestehender Bibliothekssysteme in W3 konkret genutzt.

5.2 TS/IDLE: Einbindung von Mono-IS in W3

5.2.1 Zweck

In diesem Abschnitt wird die praktische Umsetzung eines generischen IS-Gateways vorgestellt. Dabei soll ein zustandsorientiertes Mono-IS von einem zustandslosen Browser aus benützt werden können. Die hier vorgestellte Lösung beruht auf zwei Hauptpfeilern:

Der formalen Sprache IDLE und

dem Translation Server (TS), einem IDLE-basierten IS-Gateway, das (HTTP­)Anfragen von Clienten entgegennimmt und serverseitig auf die (Benutzer­)Schnittstelle eines Mono-IS zugreift, verarbeitet.

Für Details der Implementation sei auf [Fischer 95] verwiesen.

5.2.2 Umsetzerrolle des Translation Servers (TS)

Das folgende Bild 5.2 verdeutlicht die Schwierigkeiten beim Zugriff aus W3 auf einen zustandsorientierten Server:



Bild 5.2 Funktionsweise des Translation Servers5.2 Funktionsweise des Translation Servers

1. Die Erstabfrage des Clienten tritt als HTTP-Anfrage ein. HTTP ist zustandslos und RPC-artig. Darauf erfolgt der Aufbau der Verbindung mit dem Server, die Kommunikation erfolgt bei TS/IDLE zustands- und dialogorientiert.

2. Erste Daten des Servers werden an den Clienten zurückgeschickt. Aufgrund der RPC-artigen Kommunikation ist für diesen die Zusammenarbeit beendet, die Verbindung wird unterbrochen.

3. Eine Folgeanfrage des Clienten trifft beim TS ein. Dieser muss nun erkennen, wenn es sich um eine Folgeanfrage handelt und in diesem Fall die Zuordnung zur letzten Anfrage korrekt vornehmen. Dann wird mit der noch offenen Verbindung zum Server weiter gearbeitet.

Die Verbindung zwischen TS und Informationsserver bleibt dabei dauernd offen. Die Verbindung zwischen TS und Client wird jeweils nach der Übertragung einer Antwort unterbrochen.

5.2.3 Konzepte

Einen Schwerpunkt bei der Implementation des TS bildete das Erkennen von Folgeanfragen und das Zuordnen derselben. Dies entspricht der Transformation von zustandsloser zu zustandsorientierter Kommunikation. In diesem Unterabschnitt wird ein Konzept vorgestellt, das es ermöglicht, Folgeanfragen zu erkennen und richtig zu verarbeiten. Ausserdem erlaubt dieses Konzept, "alte" (im Browser zwischengespeicherte) Anfragen des Endbenutzers als solche zu erkennen und darauf zu reagieren.

Erkennung von Folgeanfragen

Grundsätzlich wird zu diesem Zweck für jeden sich anschliessenden Endbenutzer eine Instanz des TS gestartet. Diese TS-Instanzen werden durch Prozess-Identifikationsnummern (PID) eindeutig identifiziert. Dies bedeutet in W3, dass die PID in alle Hyperlinks und in Formulare eingebunden werden muss. Damit laufend entschieden werden kann, ob eine Anfrage eine neue Folgeanfrage auf eine gelieferte HTML-Seite oder eine erneute Übermittlung einer älteren Anfrage ist, werden zusätzlich Sequenznummern erzeugt und jeder dynamisch erzeugten HTML-Seite zugewiesen. Die Sequenznummer identifiziert zusammen mit der PID der TS-Instanz jede erzeugte HTML-Seite eindeutig.

Die beiden zusätzlichen Angaben (PID der TS-Instanz und Sequenznummer der HTML-Seite) könnten bei HTML-Formularen sehr einfach in versteckte Felder (Input-Felder mit Typ 'hidden') abgelegt werden. Bei Hyperlinks geht das nicht. Dort müssen die gesamten Angaben, bestehend aus der Adresse des IDLE-Programms, PID der TS-Instanz und Sequenznummer in der URL untergebracht werden. Da der TS die URL von links nach rechts abarbeitet, können nach der Adresse noch weitere Angaben als Argumente angegeben werden:

URL/IDLE-Argumente

Die URL für eine Erstanfrage an einen TS könnte z. B. wie folgt aussehen:

http://.../cgi-bin/ts/IDLE_NAME=svi.idle

Diese URL gliedert sich aus Sicht des TS in drei Teile:

1. Zugriffsprotokoll und Serveradresse (http://.../)

2. Pfad und Name des Translation Servers (cgi-bin/ts)

3. Zusätzliche Argumente, im Beispiel die zu verwendende Beschreibung (IDLE_NAME=svi.idle)

Diese URL veranlasst jeden W3-Server, ein Programm namens ts zu starten. Dies wäre in diesem Fall der Translation Server. Die zusätzlichen Angaben IDLE_NAME=svi.idle muss der TS aus den mitgelieferten Parametern auslesen. Der TS kann daraufhin eine TS-Instanz starten und dieser mitteilen, welches IDLE-Programm (svi.idle in diesem Fall) abzuarbeiten ist. Sobald das IDLE-Programm dann auf einen PAGE Befehl trifft, werden Daten vom TS zurück an den Browser geliefert und schliesslich beim Endbenutzer sichtbar.

Enthält die Antwort, die das IDLE-Programm auf die Erstanfrage erzeugt hat, INPUT-Felder oder Hyperlinks, wird eine weitere Anfrage an den TS gestellt. Eine URL für eine Folgeanfrage sieht wie folgt aus:

http://ea.ethz.ch/cgi-bin/ts/IDLE_PID=124/IDLE_SEQ=1

Damit ist das Problem der Erkennung von Folgeanfragen gelöst wie auch die Erkennung von Anfragen, die keine direkte Antwort auf die zuletzt gesandte HTML-Seite sind. In diesem zweiten Fall ist die Sequenznummer der Anfrage kleiner als die erwartete.

5.2.4 Klassifikation

In diesem Unterabschnitt wird der TS mit der Programmiersprache IDLE nach den in Kapitel 3 diskutierten Kriterien klassifiziert.

Grundlegende Klassifikation (3.2)

Konzeptionell ist der TS teilweise generisch ausgelegt. Clientseitig wird konzeptionell nur ein RPC-artiges Protokoll vorausgesetzt. In der konkreten Realisation wurde jedoch HTTP und HTML vorausgesetzt. Die Serverseite ist durch IDLE voll generisch. Der Zugriff mit IDLE ist auf beliebige Server möglich. In konkreten Beispielen wurden einige IDLE-Programme entwickelt (z. B. für ETHICS, SVI-Kurs auf ezInfo und INFBIB [Schäuble 94]). Zusammen mit einem konkreten IDLE-Programm ist der TS nicht mehr generisch. Mit IDLE sind sowohl integrierende als verbindende IS-Gateways möglich. Das ETHICS-Gateway ist als solches stark integrierend, der W3-Client sieht überhaupt nichts von ETHICS.

Nach Funktionalität (3.3)

IDLE vermittelt zwischen RPC-artigen Protokollen clientseitig und dialogorientierten oder RPC-artigen serverseitig. In konkreten Beispielen ging es dabei serverseitig immer um dialogorientierte Kommunikation. IDLE kann Zustände vermitteln. In den konkreten Beispielen wurde sowohl auf zustandsorientierte Server (ETHICS) als auch auf zustandslose Server (INFBIB) zugegriffen. Die Befehlsvermittlung ist bei IDLE konzeptionell clientseitig offen, in der Umsetzung wurde clientseitig auf die HTTP Befehle abgestützt. IDLE lässt serverseitig alle Möglichkeiten offen. Die konkreten Beispiele vermitteln zwischen HTTP und IBM3270 (ETHICS), VT-100 (ezInfo) und einer rein zeilenorientierten Schnittstelle (INFBIB).

IDLE lässt bezüglich Zusatzfunktionalität alle Möglichkeiten offen. ETHICS zeigt beispielsweise von allen gefundenen Werken nur acht gleichzeitig an. Der Endbenutzer muss jeweils durch einen erneuten Befehl die nächsten acht Werke abrufen. Das ETHICS-Gateway listet hingegen alle abgerufenen Werke in einer Liste auf. Ausser diesem zusätzlichen Komfort für den Endbenutzer wurden jedoch im Rahmen des Prototyps keine zusätzlichen Funktionen implementiert.

Je nach IDLE-Programm können auch beliebige Datenstrukturtransformationen durchgeführt werden. Das ETHICS-Gateway ist recht zurückhaltend in dieser Hinsicht und ändert die Struktur der von ETHICS gelieferten Angaben kaum. Allerdings werden, wie schon erwähnt, zur Verbesserung der Lesbarkeit mehrere Einträge auf einer Seite zusammengefasst. Dies kann auch als Änderung der Datenstruktur aufgefasst werden. Die Aspekte Sicherheit und Zwischenspeicherung wurden nicht betrachtet.

Nach Entwurfsvarianten (3.4)

Der TS ist zustandsorientiert, und somit sind IDLE-Gateways nicht darauf angewiesen, Zustandsinformationen zum Clienten zu schicken. Konkret sind sowohl zustandsorientierte (ETHICS) oder zustandslose (INFBIB) IS-Gateways realisiert worden. Gemäss Bild 3.12 folgt aus dem obigen, dass der TS beständig ist. Flüchtige IS-Gateways können jedoch realisiert werden, sofern auf der Serverseite ein zustandsloses Protokoll verwendet wird. In den konkreten Fällen wurden aus Effizienzgründen ausschliesslich beständige IS-Gateways realisiert. Alle konkret mit IDLE realisierten IS-Gateways greifen auf die Benutzerschnittstelle des ursprünglichen Dienstes zu.

5.2.5 Resultate

Realisierte IDLE-Programme

Für die folgenden Informationsserver wurden IDLE-Programme entwickelt (Bild 5.3):
DienstIDLE-Programm URL des Server
ETHICSethics.idle telnet://ethics.ethz.ch/
SVI-Kurssvi.idle telnet://ezinfo.ethz.ch/
INFBIBinfbib.idle telnet://infbib@orion.ethz.ch/
Forschungsberichte rereth.idle telnet://rereth@orion.ethz.ch/
Bundesverfassungbv.idle telnet://bv@orion.ethz.ch/

Bild 5.3 Realisierte IDLE-Programme5.3 Realisierte IDLE-Programme

Die ursprünglichen Informationsserver sind teilweise nicht mehr in Betrieb (Bundesverfassung, INFBIB, SVI-Kurs) bzw. über andere IS-Gateways verfügbar (RERETH). Die Programme svi.idle und ethics.idle implementieren je eine Teilmenge der Funktionalität des Dienstes und stellen nur ein Beispiel für eine vollständige Beschreibung der Schnittstellen dar. svi.idle ist im Anhang B als Beispiel aufgeführt.

Diverse Testprogramme sowie die Realisation von konkreten IS-Gateways für SVI-Kurs und ETHICS haben gezeigt, dass die Programmiersprache IDLE die in [Perrochon 94a] und [Perrochon 94b] gestellten und in Unterabschnitt 3.3.2 diskutierten Aufgaben (Verwaltung unterschiedlicher Zustände von verschiedenen Anfragen sowie Erkennung und Verarbeitung von zwischengespeicherten "alten" Anfragen) lösen kann. Die dazu notwendigen detaillierten Beschreibungen der Serverschnittstelle zeigen aber auch ganz klar auf, dass der hier aufgezeigte Weg nicht für alle Arten von Serverschnittstellen gangbar ist. Für sehr komplexe Serverschnittstellen werden die Beschreibungen schnell unübersichtlich.

Für einfache Serverschnittstellen hingegen ist der TS ein nahezu ideales Werkzeug. Mit wenig Aufwand kann eine moderne Benutzerschnittstelle (im konkreten Beispiel W3-basiert) konstruiert werden. Dabei sind keine Änderungen am Server notwendig. Trotzdem sind Funktionserweiterungen möglich. So kann theoretisch gleichzeitig in mehreren Bibliotheken gesucht werden. (Im zweiten Praxisbeispiel, LibAgent, wurde eine solche Erweiterung praktisch implementiert.)

Performance

Das Hauptproblem des TS ist eine allfällige Leistungseinbusse. Da in TS keine parallelen Prozesse vorgesehen sind, wird die Wartezeit auf den Endbenutzer nicht anderweitig genutzt. Konkret heisst das, dass erst bei entsprechender Aktion eines Endbenutzers eine Verbindung mit dem Server aufgenommen wird. Im konkreten Beispiel ETHICS dauert diese Verbindungsaufnahme 15-30 Sekunden. Während dieser Zeit muss der Endbenutzer warten. Zwar dauert die Verbindungsaufnahme beim herkömmlichen Vorgehen mit Terminalemulation mindestens gleich lange. Im herkömmlichen Fall wird jedoch die Wartezeit kurzweiliger gestaltet, weil der Endbenutzer alle paar Sekunden etwas eingeben muss (z. B. die gewünschte Dialogsprache). Mit dem TS wird diese Eingabe durch den TS vorgenommen. Der Endbenutzer wird davon entlastet, er realisiert die Entlastung aber kaum, nur das lange Warten. Die Situation gleicht dem Unterschied zwischen Taxifahren und Selbstfahren: Die Reise dauert gleich lang, aber die eigene Mitarbeit am Geschehen ist unterschiedlich. Der TS und die implementierten IS-Gateways stehen seit mehr als einem Jahr auf W3 zur Verfügung. Die Benutzung hält sich jedoch, insbesondere wegen der diskutierten Probleme, in kleinem Rahmen.

Resultate aus ähnlichen Forschungsprojekten

Gleichzeitig mit dieser Arbeit wurde an der Universität Trento ein ähnliches Projekt durchgeführt. Auch dabei ging es um einen W3-Zugriff auf ein Bibliothekssystem. Der Zugriff wurde durch ein spezifisches IS-Gateway realisiert. Im Gegensatz zu TS/IDLE wurden sämtliche Angaben zu den einzelnen Systemen direkt in ein Programm kodiert. In [Ronchetti et al. 95] werden die Resultate wie folgt beschrieben (übersetzt und an die Terminologie dieser Arbeit angepasst):

1. Ein IS-Gateway ist auch ohne die Unterstützung der Betreiber des ursprünglichen Anwendungsprogramms realisierbar.

2. Überraschenderweise können neue Funktionen realisiert werden, die durch das ursprüngliche Anwendungsprogramm nicht (direkt) angeboten wurden.

3. Ein IS-Gateways kann auch auf ein Anwendungsprogramm angewandt werden, das bisher nicht netzfähig war.

4. Die Vermittlung zwischen zustandsorientierter Interaktion mit dem ursprünglichen Anwendungsprogramm und zustandsloser Interaktion ist ein Problem.

5. Das IS-Gateway kann natürlich die Fehler des ursprünglichen Anwendungsprogramms nicht beheben.

6. Das IS-Gateway ist sehr empfindlich auf Änderungen der ursprünglichen Anwendung. Änderungen im ursprünglichen Programm können zu Änderungen am Gateway führen.

7. Der Endbenutzer empfindet den neuen Zugang oft als langsam, weil er von einer modernen Schnittstelle höhere Geschwindigkeit erwartet.

[Ronchetti et al. 95]

Sämtliche Feststellungen treffen uneingeschränkt auch auf TS/IDLE und das ETHICS-Gateway zu. Einzig der Punkt 6 ist bei TS/IDLE weniger ein Problem, weil durch den generischen Ansatz Änderungen am Server einfacher ins Gateway übernommen werden können.

Ein anderes, in [Barta, Hauswirth 95] beschriebenes Projekt war andererseits so erfolgreich, dass das neu über W3 verfügbare Mono-IS wegen akuter Überlastung abgestellt werden musste.

5.3 LibAgent: integrierter Zugriff auf IS

5.3.1 Zweck

Auch LibAgent schlägt eine Brücke zwischen W3 und vorerst inkompatiblen Mono-IS. Ziel ist hier der gleichzeitige Zugriff auf mehrere Server gleichzeitig. LibAgent übernimmt dabei die gesamte Kommunikation mit den Servern. Trotz dem Namen LibAgent handelt es sich nicht um einen Agenten, sondern um ein typisches Multigateway. Konkret soll LibAgent von einem W3-Browser aus den Zugriff auf die Informationssysteme ETHICS, WAIS und INFBIB ermöglichen. WAIS (Wide Area Information System) ist ein verteiltes Information-Retrieval-System, das mit einer Variante des ANSI Z39.50/ISO SR-Protokolls arbeitet [WAIS 88], [ISO 10162:1993]. INFBIB enthält den Katalog der Bibliothek des Departements Informatik der ETH. Für Details der Implementation von LibAgent sei an dieser Stelle auf [Müller 96] verwiesen.



Bild 5.4 Architektur von LibAgent5.4 Architektur von LibAgent

5.3.2 Konzept

LibAgent ist ein Multigateway gemäss Abschnitt 3.7. Eine Übersicht über die Architektur von LibAgent gibt Bild 5.4 LibAgent besteht aus einem LibAgent-Manager genannten Gatewaymanager und Subgateways für die drei Informationssysteme ETHICS, WAIS und INFBIB. In LibAgent ist nur eine allgemeine Suche nach Wörtern implementiert. Optionen bestehen bei der Auswahl der zu berücksichtigenden Subgateways und der Obergrenze für die Anzahl Resultate. Wie die allgemeine Suche genau auf die einzelnen Server abgebildet wird, entscheidet das jeweilige Subgateway. Die einzelnen Subgateways können zusätzliche Funktionen anbieten wie das Bestellen von Büchern. Solche Angebote eines einzelnen Subgateways (oder dessen Servers) werden vom Gatewaymanager unverändert weitervermittelt.

5.3.3 Realisation

LibAgent wurde von Anfang an auf die neue Programmiersprache Java ausgerichtet. Der grosse Unterschied zum ersten IS-Gateway TS/IDLE ist dabei, dass in Java mehrere Prozesse parallel ablaufen können. Mit der Eingabe der Anfrage durch den Endbenutzer erfolgt somit gleichzeitig auch der Verbindungsaufbau zum Server. Im folgenden wird auf die beiden Komponenten des Multigateways eingegangen.

Der LibAgent-Manager

Der LibAgent-Manager besteht aus der Schnittstelle zum Clienten und der Logik zur Kontrolle der LibAgent-Subgateways sowie zur Integration der Resultate. In diesem speziellen Fall sind der (W3­)Client und der in Java geschriebene Gatewaymanager sehr eng verknüpft. Die Kommunikation zwischen dem LibAgent-Manager und dem Clienten geschieht über Prozeduraufrufe. Ähnlich geschieht die Kommunikation zwischen LibAgent-Manager und den Subgateways über das Aufrufen von Methoden.

Die LibAgent-Subgateways

Momentan sind Subgateways für ETHICS, WAIS und INFBIB verfügbar. An WAIS interessiert insbesondere der cs-techreports-abstracts-Datenbestand der Universität Monash, Australien (rdt.monasch.edu.au/cs-techreports-abstracts) [Harris 94]. Damit ist LibAgent in der gegenwärtigen Form vor allem für die Literatursuche von Angehörigen des Departements Informatik der ETH Zürich geeignet. Das Hinzufügen von weiteren Subgateways ist einfach und wurde auch schon realisiert; Angaben dazu finden sich in [Müller 96].

Das ETHICS-Subgateway verbindet den LibAgent-Manager mit ETHICS. Wie das entsprechende IDLE-Programm des Translation Servers simuliert es das Verhalten eines normalen, menschlichen Endbenutzer, welcher mit ETHICS in einen Dialog tritt. Beim ETHICS-Subgateway wurde der Vorteil der Parallelisierung in Java-Programmen genutzt. Schon während dem Starten und der Eingabe der Abfrage hat das ETHICS-Subgateway Zeit, die Verbindung mit ETHICS aufzubauen. Damit ergibt sich ein entscheidender Geschwindigkeitsvorteil. Während der ganzen Zeit, in der LibAgent aktiv ist, bleibt die Verbindung mit ETHICS bestehen und wird in einem eigenen Prozess verwaltet. Das ETHICS-Subgateway gibt die Resultate eines nach dem anderen an den LibAgent-Manager zurück, welcher sie kombiniert und dem Endbenutzer in einer zusammenhängenden Liste präsentiert.

ETHICS ist nicht bloss ein Katalogsystem einer Grossbibliothek, sondern erlaubt auch gleich das Bestellen allfälliger gefundener Bücher. Daher hat das ETHICS-Subgateway eine entsprechende Eingabemöglichkeit für das Bestellen von Büchern. Der Endbenutzer muss dazu das gewünschte Buch auswählen. Danach wird er aufgefordert, seine Benutzernummer und sein Passwort einzugeben. Darauf wird ihm bestätigt, dass das Buch für ihn bestellt oder reserviert wurde.

Das WAIS-Subgateway verbindet den LibAgent-Manager mit einem WAIS-IS. Es wird erst bei einer Anfrage aktiv. Die Resultate einer Anfrage werden von WAIS in Form einer geordneten Liste an das WAIS-Subgateway zurückgegeben. Diese Liste wird dann Eintrag für Eintrag an den LibAgent-Manager weitergegeben. An das WAIS-Subgateway können leicht beliebige WAIS-IS angebunden werden. Der Umfang der Transformation ist relativ klein. Die meisten Angaben der WAIS-IS wird an den LibAgent-Manager weitergegeben und umgekehrt. Die Verbindung zwischen dem WAIS-Subgateway und der WAIS-IS erfolgt nach dem WAIS-Protokoll.

Das INFBIB-Subgateway verbindet den LibAgent-Manager mit INFBIB. Die Resultate werden von INFBIB in Form einer gewichteten Liste zurückgegeben [Schäuble 94]. Auch diese Liste wird Eintrag für Eintrag an den LibAgent-Manager geschickt. Der Umfang der Transaktion ist relativ klein. Die meisten Angaben von INFBIB werden an den LibAgent-Manager weitergegeben und umgekehrt. Die Verbindung zwischen dem INFBIB-Subgateway und INFBIB erfolgt nach dem HTTP-Protokoll.

5.3.4 Klassifikation

Zu klassifizieren sind bei LibAgent vor allem die einzelnen Subgateways. Der Gatewaymanager kombiniert die einzelnen Listen ausschliesslich nach der Zeit des Eintreffens, ohne Duplikate zu entfernen oder sonstige Transformationen vorzunehmen. Die clientseitige Schnittstelle des LibAgent-Managers unterscheidet sich nicht grundsätzlich von der serverseitigen (das ist diejenige zu den Subgateways). Der Client der einzelnen Subgateways ist der LibAgent-Manager und der Server ist ETHICS, WAIS oder INFBIB.

Grundlegende Klassifikation (3.2)

Das ETHICS-Subgateway ist clientseitig spezifisch auf den LibAgent-Manager als Client ausgelegt, serverseitig spezifisch auf ETHICS. Der Inhalt der ETHICS-Felder, die weitergegeben werden, wird wenig geändert. Allerdings werden nur wenige Felder überhaupt weitergegeben und dies in einer anderen Datenstruktur. Insofern handelt es sich um ein integrierendes IS-Gateway. Dasselbe gilt auch für die beiden anderen Subgateways.

Nach Funktionalität (3.3)

Die Verbindung zwischen dem ETHICS-Subgateway und ETHICS bleibt auch nach dem Abschicken der Anfrage bestehen. Diese Kommunikation ist folglich synchron. Diejenige zum LibAgent-Manager hingegen ist nicht synchron. Das ETHICS-Subgateway ist folglich synchronisationsvermittelnd. Wie schon das TS/IDLE-ETHICS-Gateway ist auch das LibAgent-Subgateway zustandsvermittelnd. Weil die Befehle des LibAgent-Managers und von ETHICS alle verschieden sind, ist das ETHICS-Subgateway auch befehlsvermittelnd. Die meiste Funktionalität von ETHICS wird dem LibAgent-Manager nicht angeboten. Auf der anderen Seite stellt das ETHICS-Subgateway aber eine gewisse Zusatzfunktionalität zur Verfügung, welche in ETHICS nicht vorhanden ist, z. B. den Zugriff auf die gesamte Resultatmenge auf einmal. Die Datenstruktur von Client und Server ist sehr verschieden. Das ETHICS-Subgateway muss demzufolge die Datenstruktur transformieren. Bei den beiden anderen Subgateways ist die Situation ähnlich, ausser dass sie auf zustandslose Server zugreifen.

Nach Entwurfsvarianten (3.4)

Das ETHICS-Subgateway kommuniziert in einem eigenen Prozess mit ETHICS, schon bevor der Client aktiv ist. Somit entfällt die Möglichkeit, Zustandsinformation der Serverkommunikation zum Clienten zu schicken. Das IS-Gateway muss zustandsorientiert und damit beständig sein. Dasselbe gilt für die beiden anderen Subgateways. Der Zugriff auf ETHICS erfolgt über dessen Benutzerschnittstelle. Die WAIS- und INFBIB-Subgateways hingegen greifen auf Systemschnittstellen zu.

5.3.5 Resultate

LibAgent zeigt, dass der gleichzeitige Zugriff auf verschiedene Server mit überraschend einfachen Mitteln möglich ist. Einfache Integrationen mit grosser Wirkung sind mit einfachen Mitteln möglich. Beim ETHICS-Subgateway wurden dank der Parallelität von Java die Effizienzprobleme des Vorläufersystems TS/IDLE behoben. LibAgent ist genügend schnell für den praktischen Einsatz.

5.4 StD: Server für tabellarische Daten

5.4.1 Zweck

Auch StD, der Server für tabellarische Daten, ist ein IS-Gateway. Er setzt anstelle des vor allem im Praxisbeispiel 1 realisierten Zugriffs über die Benutzerschnittstelle den direkten Zugriff auf die Daten in den Vordergrund. Von Bedeutung ist einerseits der Nachweis, dass der direkte Zugriff auf die Daten zwar vieles vereinfacht, dass dabei aber immer noch typische Probleme auftreten. Auch hier wurde ein generischer Mechanismus realisiert, der auf beliebige relationale Daten zugreifen kann. Es sollen verschiedene Möglichkeiten gefunden und getestet werden, wie relationale Daten auf Hypertext abgebildet werden können. Darauf basierend soll ein W3-Server für tabellarische Daten implementiert werden.

5.4.2 Konzept

Der ausgeschriebene Name "Server für tabellarische Daten" deutet darauf hin, dass StD konzeptionell mit einem Server zu vergleichen ist. StD ist ein IS-Gateway, das serverseitig direkt auf die Nutzdaten zugreift. Ein bestehendes Datenverwaltungssystem und Anwendungsprogramme werden dabei umgangen. Die Daten von StD müssen in Form von relationalen Tabellen vorliegen. StD wandelt diese Tabellen generisch in HTML um, so dass anstelle von Fremdschlüsselbeziehungen Hyperlinks treten. Für die Umwandlung stehen eingebaute Funktionen zur Verfügung. Bessere Resultate können aber auch durch Definition von speziellen Ausgabemasken erzielt werden.

Die StD-Datenanfrage bildet die Schnittstelle zwischen StD und dem W3-Browser. Sie wird, getrennt durch ein Fragezeichen, an die URL des W3-Servers angehängt. Diese geschieht in der Form:

URL?StD-Datenanfrage

Die Anfrage muss folgende Angaben enthalten: Name der Tabelle, die zu lesenden Attribute, Suchkriterien, Sortierschlüssel und die Bezeichnung einer zu verwendenden Ausgabemaske. Die Notation der Anfrage ist SQL nachempfunden. Eine genaue Definition der Anfrage kann [Zollinger 95] entnommen werden. Als Beispiel diene folgende Anfrage: Gesucht werden Name und ETH-Nr aller Studenten, deren Name mit "A" beginnt. Die URL einer solchen Anfrage sieht wie folgt aus:

http://.../cgi-bin/std?SELECT.ETH-Nr,Name. FROM.Student.WHERE.Name.EQ.'A*'.SORT.Name.DISPLAY.Namelist

In StD lassen sich zwei aufgabenunabhängige Komponenten definieren (Bild 5.5). Einerseits muss ein minimales Datenverwaltungssystem realisiert werden, das auf relationalen Tabellen arbeiten kann, andererseits müssen die gefundenen Daten für eine spezielle Anwendung aufbereitet werden. Spezifisch für jede Situation zu definieren sind nur die anwendungsspezifischen Angaben. Ein Beispiel dazu wäre die Abbildung von Tabellennamen in StD-Datenanfragen auf Dateien im Dateisystem.



Bild 5.5 Architektur von StD5.5 Architektur von StD

5.4.3 Realisation

Konzeptionell ist es zwar möglich, mit StD auf verschiedene Datenverwaltungssysteme zuzugreifen; die praktische Implementierung beschränkt sich aber vorerst auf den Zugriff auf lokale Dateien. Die oben erwähnten zwei Komponenten Datenzugriff und Datentransformation werden im folgenden getrennt behandelt.

Datentransformation

Damit StD die Daten wunschgemäss transformieren und darstellen kann, müssen Formatierungsangaben bereitgestellt werden. Es sind hier zwei verschiedene Ansätze denkbar. Entweder wird eine Ausgabemaske in einer eigenen Notation aufgebaut, die dann in HTML übersetzt wird, oder der Aufbau erfolgt bereits in einer erweiterten Form von HTML. StD müsste dann die zusätzlichen Label herausfiltern und durch die gewünschten Daten ersetzen.

Die Entscheidung fiel zu Gunsten des zweiten Wegs aus. Der Hauptgrund ist, dass der Anwendungsprogrammierer wahrscheinlich mit HTML vertraut ist und sich deshalb nicht lange einzuarbeiten braucht. Zudem sind so alle Vorteile von HTML nutzbar, auch die von zukünftigen Versionen. So formuliert der StD-Programmierer Ausgabemasken in Form von HTML-Dokumenten, die er durch ein weiteres Label (<mzMask>) ergänzt. Die Standard-HTML-Elemente werden ungeprüft an den W3-Browser weitergeleitet. Der Wert von <mzMask> ist nicht direkt angegeben, sondern wird durch eine Anfrage an StD ersetzt. Die zusätzlichen Label werden durch die gewünschten Daten ersetzt. Der zwischen <mzMask> und </mzMask> eingeschlossene Code wird dabei für jeden gefundenen Eintrag einmal ausgegeben. Die folgenden zusätzlichen Label sind definiert.

<mzMask> . . . </mzMask>
Der zwischen diesen Label eingeschlossene Code wird für jeden gefundenen Datensatz einmal ausgegeben. Diese Label dürfen nur einmal auftreten.

$Attr[!](Attributsnummer[,Anfangsposition[,Länge]])
Dieses Symbol wird bei der Ausgabe durch den Wert des entsprechenden Attributs ersetzt. Durch die Angabe von Anfangsposition und Länge kann nur ein Teil des Attributes ausgegeben werden. Die Attributnummer bezieht sich auf die Reihenfolge der Attribute bei der Benutzeranfrage. Auch die mittels 'PARAM' übergebenen Angaben können so angesprochen werden. Die Nummer des ersten Parameters ist gleich der Anzahl eingelesener Attribute plus eins. Ist eine Attributnummer zu gross, so dass kein zugehöriger Wert existiert, wird $Attr ignoriert. Die Spezifizierung der Attribute durch Nummern anstelle von Namen wurde gewählt, damit Masken leichter für verschiedene Zwecke benutzen werden können. Wird das Ausrufezeichen verwendet, werden Sonderzeichen, die nicht in einer Benutzeranfrage vorkommen dürfen, maskiert. Dies wird zum Generieren von Hyperlinks mit neuen Datenabfragen verwendet.

$Script
Diese Variable wird durch die aktuelle URL des W3-Servers für tabellarische Daten ersetzt. Die Verwendung dieses Labels ist sehr empfehlenswert. Falls das IS-Gateway einmal physisch auf einem anderen Rechner installiert wird, müssen nicht alle Dateien mühsam angepasst werden.

Datenzugriff

Wie oben erwähnt, können die Anfragen auf die relationalen Tabellen prinzipiell durch ein beliebiges relationales Datenverwaltungssystem behandelt werden. In StD wurde bisher nur der Zugriff auf statische Dateien realisiert. Die Anfragen werden in der SQL-artigen Abfragesprache StD-SQL formuliert. Bild 5.4 enthält die vollständige EBNF-Definition von StD-SQL.


erweiterte URL = URL?Benutzeranfrage.



Benutzeranfrage = SELECT "." Attribute "." FROM "." Ident


[ "." WHERE "." Suchbedingungen { "," Suchbedingung } ]

[ "." SORT "." Ident ]

[ "." DISPLAY "." Zeichenkette]

[ "." NOTHING "." Zeichenkette]

[ "." PARAM "." Datentyp { "," Datentyp } ].

Attribute = Ident { "," Ident }.

Suchbedingungen = Suchbedingung { "," Suchbedingung }

{ "." OR "." Suchbedingungen }.

Suchbedingung = Ident "." RelOperator "." Datentyp.

RelOperator = EQ | NE | LE | LT | GE | GT.

Datentyp = Zeichenkette | GekürzteZeichenk | Dezimalzahl |

Fliesskommazahl | Datum.

Ident = Zeichen{Zeichen}.

Zeichenkette = "'" { Zeichen | "." } "'".

GekürzteZeichenk = "'" { Zeichen } "*" "'".

Dezimalzahl = Zahl.

Fliesskommazahl = Zahl "." Zahl [ "e" Vorzeichen Number Number ].

Zahl = Number { Number }.

Zeichen = "a"-"Z" | "0"-"9" | "$" | "-" | "_" | "@" | "&" | "+" | "!" | "*" |

'"' | "(" | ")" | Escape.

Escape = "%" Hex Hex.

Hex = "0"-"9" | "a"-"f" | "A"-"F".

Number = "0"-"9".

Vorzeichen = "+" | "-".



Zeichenerklärung:


[…] Eingeschlossener Teil ist optional


{…} Eingeschlossener Teil kann beliebig oft wiederholt werden (0 bis n).

A | B Entweder A oder B


"a"-"Z" Auswahl aus Bereich: "a" | "b" | … | "Z"


Bild 5.6 EBNF-Syntax von StD-SQL5.6 EBNF-Syntax von StD-SQL

Da innerhalb einer URL keine Leerschläge vorkommen dürfen, werden in StD-SQL Punkte (".") benutzt. Die Bedeutung der Schlüsselwörter und relationalen Operatoren ist wie folgt:

SELECT
Die Argumente von SELECT definieren die anzuzeigenden Attribute.

FROM
Die Argumente von FROM definieren die Tabellen, auf die zugegriffen wird.

WHERE
Innerhalb von WHERE können Suchkriterien spezifiziert werden.

OR
Oder-Verknüpfung von Suchbedingungen. Nur eine der Suchbedingungen muss erfüllt sein.

SORT
Das Argument von SORT bezeichnet den Sortierschlüssel, das Attribut, nachdem sortiert werden soll.

DISPLAY
Das Argument von DISPLAY bezeichnet die Maske, die zur Darstellung verwendet werden soll.

NOTHING
Mit NOTHING kann ein Text spezifiziert werden, der ausgegeben wird, falls kein Datensatz gefunden wird. So lassen sich auch im Fehlerfall eingermassen verständliche Fehlermeldungen ausgeben.

PARAM
PARAM enthält zusätzliche Angaben, die beim Aufbau der Seite benötigt werden. Für Details sei auf [Zollinger 95] verwiesen.

relationale Operatoren
In den Suchbedingungen stehen die folgenden Vergleichsoperationen zur Verfügung. EQ: gleich. NE: ungleich. LE: kleiner oder gleich LT: kleiner. GE: grösser oder gleich. GT: grösser.

Gross- und Kleinschreibung wird bei Schlüsselwörtern nicht unterschieden. Alle Schlüsselwörter ausser SELECT und FROM sind optional. Falls DISPLAY weggelassen wird, d. h. keine Ausgabemaske bestimmt wird, werden die Daten tabellarisch untereinander ausgegeben.

5.4.4 Klassifikation

Grundlegende Klassifikation (3.2)

Clientseitig ist StD spezifisch auf W3 ausgerichtet. Serverseitig dagegen ist StD prinzipiell generisch. Der Zugriff beschränkt sich jedoch auf direkten Zugriff auf Daten in Form von relationalen Tabellen. StD ist ein integrierendes IS-Gateway. Auf den Dateien sind ja prinzipiell nur die Funktionen des Betriebssystems vorhanden. Diese sind aber für den Clienten nicht sichtbar, und werden durch SQL-artige Anfragen ersetzt. Wird StD durch den Zugriff auf relationale Datenverwaltungssysteme erweitert, spricht nichts dagegen, sämtliche Anfragen einfach durchzureichen. In diesem Fall hat StD, was die Sprache der Datenabfragen betrifft, verbindenden Charakter. Die Datentransformationskomponente bleibt jedoch integrierend.

Nach Funktionalität (3.3)

Die StD-SQL-Anfragen werden durch das IS-Gateway in Zugriffe auf das Dateisystem übersetzt. Beide haben aber den Charakter von RPC. Die direkten Zugriffe auf die Daten geschehen bei StD über jeweils von neuem gestartete Betriebssystemfunktionen. Als solche sind diese zustandslos, wie auch HTTP, das clientseitige Protokoll. StD vermittelt also auch keine Zustände. In einem gewissen Sinne werden die HTTP Befehle in Betriebssystembefehle umgesetzt. Da die Daten auf verschiedenste Arten aufbereitet werden (z. B. Selektion, Projektion, Sortierung), kann von einer zusätzlichen Funktionalität gesprochen werden.

Da die Daten aus einer relationalen Darstellung in die HTML-Darstellung transformiert werden (z. B. Selektion, Projektion, Sortierung), kann von einer zusätzlichen Funktionalität gesprochen werden.

Nach Entwurfsvarianten (3.4)

StD ist zustandslos und flüchtig. Sämtliche notwendigen Angaben werden zum Client übermittelt. Für Folgeanfragen muss dieser die Angaben wieder zurückschicken.

5.4.5 Resultate

Es ist gelungen, mit StD das Mono-IS SVI-Kurs auch über W3 verfügbar zu machen. Der an "embedded SQL" erinnernde Ansatz mit StD-SQL Befehlen ist unterdessen in ähnlicher Form in kommerziellen Produkten verfügbar [Perrochon 95d].

Im Laufe der Entwicklung von StD konnten auch einige Erfahrungen über geeignete Formen der hypertextbasierten Darstellung von relationalen Tabellen gemacht werden. Für eine vertiefte Behandlung dieser Resultate sei auf [Zollinger 96] verwiesen.

5.5 PubDINIS: öffentlicher W3-Kiosk

5.5.1 Zweck

Die beiden letzten Praxisbeispiele, PubDINIS und WAB, verbinden Clienten und Server, die auch ohne ein IS-Gateway kommunizieren können. Durch beide IS-Gateways werden Standard-W3-Browser mit Standard-W3-Servern verbunden, und die Aufgabe des IS-Gateways ist es jeweils, die dem Endbenutzer zur Verfügung stehende Sicht auf die Daten des Servers zu verändern. Da die Änderungen im IS-Gateway stattfinden, können einerseits beliebige Clienten davon profitieren. Weil auf den Servern auch nichts geändert wird, kann andererseits jeder Client selbständig entscheiden, ob er das IS-Gateway benutzen oder auf die unveränderten Daten des Servers zugreifen will.


Bild 5.7 PubDINIS-Kiosk5.7 Foto PubDINIS-Kiosk

Die Rolle des Servers für das PubDINIS-Gateway übernimmt DINIS, das computergestützte Informationssystem des Departements Informatik. Obwohl DINIS über W3 weltweit verfügbar ist, sind Besucher und Passanten im Departmentsgebäude weiterhin auf konventionelle Informationsangebote wie Anschlagbretter angewiesen. Das Ziel des Projekts PubDINIS [Perrochon, Büchel 95] war die Verfügbarmachung von DINIS auch für Besucher des Departementsgebäudes. Es sollte ein elektronischer Kiosk als öffentlicher Zugang zum Departementsinformationssystem DINIS installiert werden. Dabei ging es nur um das Lesen von Informationen, das Erfassen von Daten war mit PubDINIS nie vorgesehen. An DINIS sollten dabei keine Änderungen anfallen. Die gelesenen Daten werden weiterhin auch von anderen Endbenutzern über W3 angefordert und nicht speziell für den Kiosk aufbereitet.

5.5.2 Konzept

Erwünscht waren vor allem einfache Bedienbarkeit und Wartung. Ein von der Schweizerischen Bankgesellschaft kostenlos zur Verfügung gestelltes Kioskgehäuse (Bild 5.7) enthielt als einziges Eingabemedium einen berührungsempfindichen Bildschirm (Touchscreen). Damit war die einfache Bedienbarkeit abgedeckt. Um die Wartung zu vereinfachen, sollte soweit möglich Standardsoftware eingesetzt werden. In der Folge war ein Konzept zu entwickeln, wie allein mit dem Touchscreen (d. h. insbesondere ohne Tastatur), mit Standardsoftware und ohne Änderungen an DINIS ein einfacher Zugriff auf DINIS realisiert werden kann.

Da auf DINIS normalerweise schon über W3 zugegriffen wird, lag der Einsatz eines W3-Browsers auch für PubDINIS nahe. Nun wird W3 hauptsächlich mit der Maus bedient, doch darüber hinaus treten auch bei normalem Gebrauch Situationen auf, wo eine Tastatur notwendig wird: beim Ausfüllen von Formularen oder beim Zugriff auf nicht W3-kompatible Informationssysteme. In letzterem Fall wird zusätzlich zum W3-Browser eine Terminalemulation gestartet. Diese beiden Fälle galt es zu vermeiden. Statt nun den Endbenutzer mit störenden Fehlermeldungen darauf aufmerksam zu machen, dass er einen bestimmten Hyperlink nicht anwählen kann, sind in PubDINIS alle Hyperlinks, die zu Fehlermeldungen führen könnten, von Beginn weg deaktiviert und nicht als solche erkennbar. Dazu modifiziert ein IS-Gateway alle Daten, die von DINIS zu PubDINIS geschickt werden (Bild 5.8).


Bild 5.8 Architektur von PubDINIS5.8 Architektur von PubDINIS

Das PubDINIS-Gateway übernimmt noch weitere Aufgaben. Von jeder beliebigen Seite soll der Endbenutzer nämlich durch Anwählen einer Schaltfläche direkt auf die Einstiegsseite von DINIS geführt werden ("HOME"). Ausserdem soll er jeweils auf die vorgehende Seite zugreifen können ("BACK"). Dieser letzte Punkt, den jeder W3-Endbenutzer von der "BACK"-Schaltfläche seines W3-Browsers her kennt, führt zu zusätzlichen Anforderungen an das PubDINIS-Gateway: Die eingebaute Funktion des W3-Browsers auf dem PubDINIS-Kiosk kann nämlich nicht verwendet werden, weil sie nicht einzeln zugeschaltet werden kann. Würde man sie zuschalten, wären gleichzeitig auch Funktionen wie das Drucken dem Endbenutzer zugänglich. Dies ist jedoch auf einem Kiosk ohne Drucker unerwünscht. Deshalb werden sowohl eine "HOME"- als auch eine "BACK"-Schaltfläche als zusätzliche Navigationselemente durch das PubDINIS-Gateway in die transformierten Dokumente eingefügt. Für letztere muss das PubDINIS-Gateway eine ständige Kontrolle über die bisher vom Endbenutzer angeforderten Seiten führen. Die notwendige Funktionalität der Schaltflächen wird durch das PubDINIS-Gateway sichergestellt.

5.5.3 Realisation

Die Realisation des PubDINIS Gateways war auf Effizienz in Programmierung und späterem Betrieb ausgerichtet. Die Kommunikation mit Server und Client basiert auf bestehenden (spezifischen) Programmen. Da die eingesetzten Programme sehr weit verbreitet sind, ist dies ein zweckmässiger Ansatz. Als einzige Änderung auf der Serverseite wurde eine zusätzliche Einstiegsseite mit einer attraktiven Grafik erstellt, die zum Ausprobieren einlädt. Ausserdem sammelt das PubDINIS-Gateway statistische Daten über das Verhalten der Endbenutzer.

5.5.4 Klassifikation

Grundlegende Klassifikation (3.2)

Sämtliche Transformationen wurden direkt ausprogrammiert. Anpassungen sind nur durch Programmänderungen möglich. Das PubDINIS-Gateway ist also äusserst spezifisch. Was die Kommunikation anbelangt, ist das PubDINIS-Gateway ein verbindendes IS-Gateway. Sämtliche Kommunikation zwischen Client und Server wird unverändert durchgereicht. Durch Änderung der Daten stehen aber zusätzliche Funktionen zur Verfügung. Der Server erscheint dadurch dem Clienten als direkt auf ihn zugeschnitten. Dieser Aspekt ist integrierend.

Nach Funktionalität (3.3)

Da bei PubDINIS Client und Server auch ohne IS-Gateway miteinander kommunizieren könnten, ist keine Kommunikationsvermittlung notwendig. Als zusätzliche Funktionalität stellt das PubDINIS-Gateway dem Endbenutzer aktiv neue Schaltflächen zur Verfügung. Nebenbei filtert das PubDINIS-Gateway alle unerwünschten Hyperlinks heraus. Diese Erweiterung der Funktionalität geschieht technisch durch Transformation der Daten. Ansonsten bleiben die Daten jedoch unverändert. Die Aspekte Sicherheit und Zwischenspeicherung sind bei den lokalen Verhältnissen nicht kritisch.

Nach Entwurfsvarianten (3.4)

Da mit HTTP client- wie serverseitig ein zustandsloses Protokoll eingesetzt wird, stand der Realisation eines zustandslosen IS-Gateways nichts im Wege. Für die Realisation der zusätzlichen Schaltfläche "BACK" führt das PubDINIS-Gateway eine Liste der bisher besuchten Seiten. Diese Zustandsinformation kann zwar theoretisch zum Clienten geschickt werden. Der Einfachheit halber werden diese Daten in eine Datei gespeichert.

5.5.5 Resultate

PubDINIS wurde im Frühjahr 1995 entwickelt und danach in Betrieb genommen. Im Sommer 1995 wurde der Kiosk wegen einer Neuverkabelung des Gebäudes entfernt und danach nicht mehr aufgestellt.

Entwurf und Realisation des PubDINIS-Gateways wurden mit den in Kapitel 6 beschriebenen Methoden ziemlich problemlos vorbereitet und durchgeführt. Die grössten Probleme im Betrieb brachten unerwarteterweise die im Kiosk eingesetzte Hard- und Software. Das einzige Problem im PubDINIS-Gateway selbst war die fehlende Anpassungsfähigkeit. Einige erst im Nachhinein erkannte Benutzerwünsche konnten nur mit Mühe oder überhaupt nicht mehr realisiert werden. Wider Erwarten zeigte sich, dass sich ein generisches IS-Gateway sogar in einem derartig spezifischen Fall auszahlt.

Im Hauptgebäude der ETH wird seit Jahren ein ähnliches System geplant. Ein spezieller Workshop zum Thema W3-basierte Kioske [Perrochon 95b] zeigte, dass ähnliche Ideen weltweit umgesetzt wurden: In Cambridge, MA [Marinoff 95] oder in U-Bahnstationen von Santiago de Chile [Hörmann 95].

5.6 WAB: W3-Zugriff für Blinde

5.6.1 Zweck

WAB, das letzte der Praxisbeispiele ist von der technischen Aufgabenstellung sehr nahe mit dem soeben diskutierten PubDINIS-Gateway verwandt. Das Einsatzgebiet des WAB-Gateways ist jedoch komplett verschieden: Das Ziel sind nicht Passanten in einem Gebäude, sondern blinde oder stark sehbehinderte Computerbenutzer in ihrer gewohnten Umgebung. Diese verwenden normalerweise ein Screenreader-Programm, das die Angaben auf dem Bildschirm in nichtvisuelle Formen wie Braille, Sprache oder nichtsprachliches Audio transformiert. Der Zugriff auf World Wide Web ist für Blinde trotzdem nicht ganz einfach. Ein blinder Endbenutzer kann leicht schon auf einer einzelnen W3-Seite die Übersicht verlieren. Dies liegt insbesondere daran, dass keine W3-Browser existieren, welche die speziellen Bedürfnisse von Blinden berücksichtigen. Herkömmliche W3-Browser präsentieren Strukturinformation in Hypertextdokumenten (z. B. Titel, Listen, Hyperlinks) visuell durch Farbe, Schriftart und ­grösse, etc. Solche visuellen Angaben in für Blinde geeigneter Form darzustellen, ist kaum möglich. Das macht es für Blinde auch mit Screenreader sehr schwierig, Strukturinformation zu erkennen. Ein W3-Browser für Blinde muss deshalb Strukturinformation durch andere Mittel wie zum Beispiel Text ("Hier beginnt ein Titel") oder Audio ausdrücken. An dieser Stelle wird nicht weiter auf diese Problematik der idealen Darstellung an sich eingegangen (vgl. aber [Kennel et al. 96]).

Ein Grund für das Nichtvorhandensein von geeigneten W3-Browsern für Blinde ist sicher die relativ geringe Nachfrage, die sich erst noch auf viele verschiedene Plattformen erstreckt. Das Ziel des WAB-Projektes war die Entwicklung einer benutzerfreundlichen, plattformübergreifenden Lösung. Wenn möglich sollten auch verschiedene Präsentationsformen realisiert und getestet werden.

5.6.2 Konzept

Das Ziel kann also wie folgt zusammengefasst werden: Beliebige W3-Browser auf verschiedenen Plattformen fordern von beliebigen W3 Servern beliebige W3-Dokumente an, die für Blinde passend dargestellt werden. Ähnlich wie bei PubDINIS werden die Daten der Informationsanbieter auch von anderen Endbenutzern angefordert und nicht speziell für Blinde aufbereitet. Die Lösung muss konfigurierbar sein, damit verschiedene Präsentationsformen einfach realisiert und ausgetestet werden können. Im Zeichen der Benutzerfreundlichkeit soll der blinde Endbenutzer nichts über die Funktionsweise wissen müssen.

Diese Anforderungen legen den Einsatz eines IS-Gateways nahe, welche verschiedenen Plattformen den Zugriff erlaubt (Bild 5.9). Das WAB-Gateway transformiert jedes Dokument in eine für Blinde besser angepasste Form. So werden die strukturbeschreibenden Label wie Titel (<TITLE>) oder Hyperlinks (<A>) in den Daten durch zusätzliche, textuelle Angaben sichtbar gemacht. Weitere Label, die rein gestalterische Effekte haben, wie Hervorheben (<emphasis>, <strong>) sind für Blinde weniger wichtig und werden im Sinne einer Konzentration auf das Wesentliche entfernt. Bei weiteren nicht textuellen Label wie <image>, <radiobutton>, <checkbox>, <editbox>, <button>, und <combobox> werden die dazugehörigen Werte durch spezielle Schlüsselwörter ergänzt.


Bild. 5.9 Architektur von WAB5.9 Architektur von WAB

5.6.3 Realisation

Die Kommunikation mit Server und Client basiert bei PubDINIS auf existierenden Programme. Da die eingesetzten Programme sehr weit verbreitet sind, ist dies ein zweckmässiger Ansatz. Zusätzliche Module übernehmen die Datentransformation. Um verschiedene Lösungen zu testen, sind diese clientseitig generisch. Alle durchzuführenden Transformationen werden als Produktionen mit folgender (vereinfachter) Form aufgefasst.

Id: X Y

Id ist der Name der Produktion und X gibt an, was durch Y ersetzt wird. Stellen, welche durch "…" markiert sind, können beliebigen Text enthalten. Die vollständige Liste der in WAB aktiven Produktionen ist in [Bosshard et al. 95] zu finden. Zwei kurze Beispiele sind die folgenden:

STR0: <STRONG>

LNK: <A … HREF="…"> … </A> <A … HREF="…"> Link … </A>

Produktion STR0 entfernt während der Transformation eines HTML-Dokuments alle Vorkommen des <STRONG> Labels. Produktion LNK fügt jeweils im Wert eines Hyperlinks (Anchor) <A> zusätzlich den Text Link ein. Der beliebige Text an den "…"-Stellen wird dabei jeweils entsprechend übernommen.

5.6.4 Klassifikation

Grundlegende Klassifikation (3.2)

WAB ist von Beginn weg so konzipiert, dass clientseitig Änderungen leicht durchzuführen sind. Nicht die Kommunikation stand dabei im Vordergrund, sondern die Aufbereitung der Daten. Was die Kommunikation anbelangt, ist das WAB-Gateway ein verbindendes IS-Gateway. Sämtliche Kommunikation zwischen Client und Server wird unverändert durchgereicht. Durch Änderung der Daten werden aber zusätzliche Funktionen realisiert. Der Server erscheint dadurch dem Clienten als direkt auf ihn zugeschnitten. Für den blinden Endbenutzer hat W3 dank WAB eine erweiterte Oberfläche. Dieser Aspekt ist integrierend.

Nach Funktionalität (3.3)

Da bei WAB Client und Server auch ohne WAB-Gateway miteinander kommunizieren können, ist keine Kommunikationsvermittlung notwendig. Als zusätzliche Funktionalität stellt WAB dem Endbenutzer neue Hyperlinks zur Verfügung Diese Erweiterung der Funktionalität geschieht technisch durch Transformation der Daten. Ansonsten bleiben die Daten jedoch unverändert. Die Aspekte Sicherheit und Zwischenspeicherung sind bei den lokalen Verhältnissen nicht kritisch.

Nach Entwurfsvarianten (3.4)

Da mit HTTP client- wie serverseitig ein zustandsloses Protokoll eingesetzte wird, stand der Realisation eines zustandslosen IS-Gateways nichts im Wege. Im Gegensatz zu PubDINIS wird bei WAB ausser statistischen Daten überhaupt nichts auf dem IS-Gateway gespeichert.

5.6.5 Resultate

Schon im Rahmen der Realisation und bei den ersten Tests wurden erste Erkenntnisse erzielt. Beispielsweise ist die formelle Korrektheit der zu transformierenden Daten von grundlegender Bedeutung, da das WAB-Gateway die gesamte Struktur einlesen muss. Die Regel "Garbage in, garbage out" gilt bei IS-Gateways, die Veränderungen an der Struktur vornehmen, ganz besonders. Offenbar verführen offene Datenformate wie HTML zu Ungenauigkeiten. Das Fehlen einer selbständigen Datenbeschreibung und eines Datenverwaltungssystems, das korrekte Datenstrukturen wenigstens teilweise garantieren könnte, macht sich in diesem Fall störend bemerkbar.

An diesem Beispiel seien ein paar wirtschaftliche Überlegungen demonstriert. Die Alternative zum WAB-Gateway wären allesamt unbezahlbar. Entweder werden alle W3-Server der Erde an die Bedürfnisse von Blinden angepasst oder alle von Blinden eingesetzten W3-Browser werden an die Server angepasst. Konkret müssten mindestens angepasste W3-Browser für Macintosh, DOS und Windows zur Verfügung stehen. Der Aufwand wäre mindestens dreimal so hoch.

Ähnlich wie bei PubDINIS führten bei WAB die angewandten Methoden zu einem stabilen und leicht wartbaren IS-Gateway. Die im Nachhinein notwendigen Änderungen und Ergänzungen spielen sich typischerweise auf der Stufe der Präsentationsform ab.

Das WAB-Gateway ist seit Juli 1995 an der ETH in Betrieb und steht Endbenutzern aus der ganzen Welt zur Verfügung. Die Software ist frei verfügbar. Die Analyse der Logdateien ergibt, dass nur eine kleine Anzahl von Endbenutzern das WAB-Gateway der ETH regelmässig benutzt. Aufgrund der ungenügenden Netzkapazitäten ist dieses für Nichteuropäer leider nicht attraktiv. Es ist deshalb zu hoffen, dass WAB oder Weiterentwicklungen davon an weiteren Orten installiert wurde.

Die Idee mit den HTML-transformierenden IS-Gateways von PubDINIS und WAB wurde andernorts [Brooks et al. 95] noch weiter generalisiert. Die sogenannten Stream Transducers erledigen auch noch weitere Aufgaben: So werden alle transformierten Dokumente laufend indexiert und ein Volltextsuchsystem aufgebaut.

6 HINWEISE F&UUML;R DEN PRAXISEINSATZ


6.1 Eingliederung in das Unternehmensumfeld

Dieses Kapitel soll einige kurze Hinweise für Entwurf und Realisation von IS-Gateways geben. Es ersetzt nicht andere Werke über Software-Engineering oder Informatik-Projektenwicklung.

Vor dem Gatewayeinsatz sollte ein bestehendes Informatikkonzept, "ein Leitbild des Informatikeinsatzes und der dafür vorgesehenen Informatikmittel" [Zehnder 96], konsultiert werden. Darin ist insbesondere nach einer Unternehmensarchitektur für die Informatik zu suchen. Soweit eine solche (eingekaufte oder selbst entwickelte) Unternehmensarchitektur vorhanden ist, müssen die zu integrierenden Komponenten in die Architektur eingeordnet werden. Es muss abgeklärt werden, ob die Unternehmensarchitekur zwischen den beiden Komponenten eine Schnittstelle vorsieht und ob die beiden Komponenten dazu kompatibel sind. Falls keine Zusammenarbeit vorgesehen ist, ist diese in der Unternehmensarchitektur nachzutragen oder auf die Zusammenarbeit ist zu verzichten.

6.2 Entwurfsschritte

Dieser Abschnitt legt die Schritte eines Entwicklungsprozesses für IS-Gateways dar, wie sie sich aus dieser Arbeit ergeben. Sie basieren in Aufbau und Terminologie auf einem Phasenmodell für die Informatik-Projektentwicklung [Zehnder 91]. Es ergeben sich jedoch einige Änderungen im Vergleich zu anderen Informatikprojekten.

6.2.1 Projektumriss

Bei der Entwicklung von IS-Gateways ist der Projektumriss die wichtigste Phase. Sie umfasst eine ausführliche Analyse des Problems. Die Zahl der Randbedingungen ist bei IS-Gateways sehr hoch; es geht ja um das Einpassen existierender Komponenten in eine erweiterte Nutzung. Die Schnittstellen zur Aussenwelt und die Systemumgebung sind fest vorgegeben. Die Ist-Zustands-Beschreibung umfasst drei Komponenten:

1. Abklären der Möglichkeiten des Servers
In einem ersten Schritt müssen die Möglichkeiten des Servers abgeklärt werden. Welche Schnittstellen bestehen auf dem Server? (In bevorzugter Reihenfolge:) Steht serverseitig eine Systemschnittstelle, eine Datenschnittstelle oder eine Benutzerschnittstelle zur Verfügung (3.4.3)? Wie geschieht die Kommunikation mit dieser Schnittstelle: Mit RPC, dialog- oder meldungsorientiert (3.3.1)? Welche Zustände (3.3.2) und Befehle (3.3.3) kennt der Server? Der letzte wichtige Punkt betrifft die notwendigen Datenstrukturen (3.3.4).

2. Abklären der Möglichkeiten des Clienten
Im zweiten Schritt muss der Client untersucht werden: Welche Schnittstellen bestehen clientseitig? Bestehen Beschreibungen dieser Schnittstellen? Die Fragen nach der Kommunikation mit der Client-Schnittstelle (3.3.1, 3.3.2, 3.3.3) und den benötigten Datenstrukturen (3.3.4) sind analog zum Server abzuklären.

3. Herausarbeiten der Differenzen zwischen den beiden Schnittstellen
Im Anschluss an die Bestandesaufnahme müssen die beiden Schnittstellen verglichen werden. Insbesondere stellt sich die Frage nach Gemeinsamkeiten. Oft können solche durch einfache Erweiterungen der Teilsysteme geschaffen werden.

Basierend darauf kann ein Pflichtenheft für das neue IS-Gateway erstellt werden.

Erarbeiten eines Pflichtenhefts für das IS-Gateway

Die durch den Server angebotenen Dienste müssen allenfalls nicht vollständig durch das IS-Gateway vermittelt werden. Dafür werden möglicherweise zusätzliche Funktionen angeboten (3.3.5). Die Frage, welche Funktionen des Server durch das IS-Gateway vermittelt werden sollen, ist unter Berücksichtigung der 80-20-Regel [Zehnder 91] zu beantworten. Diese Regel besagt bezüglich Entwicklungsarbeiten für IS-Gateways: "Die Vermittlung von 80% der Serverfunktionalität kann mit nur 20% des Aufwandes für die Vermittlung der vollen Serverfunktionalität realisiert werden."

Aufgrund der herausgearbeiteten Differenzen und des Pflichtenhefts lässt sich das zu verwendete IS-Gateway nach den oben besprochenen Kriterien genau klassifizieren. Durch diese Klassifikation werden verschiedene Konzept- und Implementationsentscheide vorweggenommen. So kann beispielsweise bei zustandsorientiertem clientseitigem Protokoll nur ein zustandsorientiertes und damit ein beständiges IS-Gateway in Frage kommen (Bild 3.12).

6.2.2 Konzept (mit Varianten)

Das wichtigste sind Abklärungen, ob für das vorliegende Problem spezifische IS-Gateways existieren oder ob generische mit kleinem Aufwand angepasst werden können. Falls noch keine solchen Lösungen existieren, geht es um einige wichtige Entscheide: Meist ist die Schnittstelle des Clienten fest gegeben, aber auf der Serverseite bestehen noch Wahlmöglichkeiten. Auch muss entschieden werden, wie flexibel das IS-Gateway sein soll und ob allenfalls neue Schnittstellen definiert oder bestehende von aussen neu übernommen werden.

Serverseitige Schnittstelle

Der direkte Zugriff auf die Datenschnittstelle des Servers ist allerdings problematisch, da auf die Daten unter Umgehung allfällig vorhandener konsistenzsichernder Datenverwaltungsmechanismen zugegriffen wird. Besonders erfolgreich sind Daten-Gateways, wenn die Daten schon in der gewünschten Struktur gespeichert sind. Dann muss das IS-Gateway keine Datentransformation mehr machen. Daten-Gateways sind ausserdem nur angebracht, wenn die Daten ausschliesslich gelesen werden. Es hat keinen Sinn, im bestehenden Datenverwaltungssystem des Servers realisierte Funktionen im IS-Gateway zu duplizieren. Weiter sollte auf die Daten nicht anderweitig zugegriffen werden (z. B. weil die bestehende Anwendungsprogramme vollständig abgelöst werden oder auf Kopien gearbeitet wird). Falls das IS-Gateway gleichzeitig mehrere Clienten unterstützt, muss es notfalls selber die notwendigen Transaktionsmechanismen sicherstellen.

Die vorzuziehende Variante ist der Zugriff auf die Systemschnittstelle, da diese schon im bestehenden Server für die Kommunikation von Programmen optimiert worden ist. Wird auf die Systemschnittstelle des Servers zugegriffen ist die Möglichkeit einer Aufteilung der Aufgabenbereiche zwischen IS-Gateway und Server (bzw. dessen Datenverwaltungssystem) interessant. Oft kann durch einfachste Massnahmen innerhalb des Informationsservers die Arbeit des IS-Gateways stark vereinfacht werden. Beispiele sind die Definition von Sichten innerhalb des Datenverwaltungssystem oder die Verwendung von "Stored Procedures", die Aufgaben schon im Datenverwaltungssystem erledigen.

Der Zugriff auf die Benutzerschnittstelle ist soweit möglich zu vermeiden. Ist er nicht zu umgehen, ist eine möglichst flexible Lösung zu wählen, da sich Benutzerschnittstellen relativ häufig ändern.

Flexibilität

Falls ein IS-Gateway neu entwickelt werden muss, stellt sich auch folgende Frage: Soll ein spezifisches oder ein generisches IS-Gateway entwickelt werden? Spezifische IS-Gateways sind einfacher, aber generische sind im allgemeinen leichter wart- und portierbar (3.2.1).

Bei generischen Daten-Gateways müssen durch den Gatewaybetreiber nur die Struktur der Daten auf dem Server, die gewünschte Struktur des Resultats für den Clienten und die gewünschten Abfragen auf die Daten definiert werden. Für beides werden in der Regel SQL-ähnliche Sprachen verwendet. Die Abfragen werden durch das IS-Gateway interpretiert und in Datenzugriffe umgesetzt. Die erhaltenen Daten werden dann in der gewünschten Struktur an den Clienten weitergeleitet.

Im Gegensatz zu Daten-Gateways muss bei generischen Systemschnittstellen-Gateways die Struktur der Daten auf dem Server nicht mehr detailliert beschrieben werden. Die Beschreibung beschränkt sich auf die Formulierung von Abfragen. Dazu werden in der Regel SQL-ähnliche Sprachen verwendet. Falls das Datenverwaltungssystem des Informationsservers diese Abfragen abarbeiten kann, werden sie durch das IS-Gateway direkt dorthin geschickt. Andernfalls werden sie durch das IS-Gateway interpretiert und in die Abfragesprache des Informationsservers umgesetzt. Die erhaltenen Daten werden dann in der gewünschten Struktur an den Clienten weitergeleitet.

Bei generischen Benutzerschnittstellen-Gateways müssen in diesem Fall die Benutzerschnittstelle des Informationsservers sowie die gewünschte Datenstruktur für den Clienten beschrieben werden.

Neue Schnittstellen

Weiter muss entschieden werden, ob neue Schnittstellen definiert oder weitere Normschnittstellen in den Betrieb eingeführt werden müssen. In der Praxis wird sich die Einführung einer weiteren Schnittstelle vor allem dann lohnen, wenn die Anzahl der Clienten und Server sehr hoch ist. In diesem Fall wird sich die Definition einer Schnittstelle (oder die Verwendung einer Normschnittstelle) sowieso aufdrängen.

6.2.3 Realisation

In der Realisationsphase muss erst eine Detailspezifikation für das IS-Gateway erarbeitet werden. Im Rahmen der Präzisierung der Randbedingungen wird bei der Entwicklung von IS-Gateways der grösste Teil der Arbeit schon in der Phase Projektumriss geleistet. Offen bleibt noch die Gestaltung innerhalb des IS-Gateways. Für ein generisches IS-Gateway muss sicher die Spezifikationssprache für die verschiedenen Beschreibungen definiert werden. Mehr programmiertechnische Fragen betreffen die Kommunikation innerhalb des IS-Gateways: geschieht diese meldungsbasiert oder -gesteuert, synchron, über Prozeduren oder Bibliotheksaufrufe? Generell sind intern soweit möglich die Vorgaben von aussen zu übernehmen, insbesondere wenn die beiden externen teilweise Schnittstellen übereinstimmen.

Für den Gatewaybetreiber spielt es ferner eine erhebliche Rolle, welchen Umfang die für die Anpassung an weitere Teilsysteme notwendige Beschreibung hat. Ein wichtiger Vorteil eines generischen IS-Gateways entfällt, wenn die Anpassung der Beschreibung an ein neues Serversystem mehr Aufwand als das Entwickeln eines neuen IS-Gateways kostet.

Basierend auf der Detailspezifikation wird das IS-Gateway realisiert. Dabei sind die übrigen Regeln des Software-Engineerings zu beachten. Mögliche Optimierungen werden durch zustandsorientierte und beständige IS-Gateways erreicht, da diese weniger Kommunikationsaufwand haben bzw. nicht dauernd neu gestartet werden müssen. Die in "normalen" Informatikprojekten üblichen Teilphasen Datenbereitstellung und die Rahmenorganisation entfallen bei der Entwicklung von IS-Gateways ganz oder teilweise.

6.2.4 Systemtest

Besonderes Gewicht liegt beim Systemtest auf dem Integrationstest zusammen mit Client und Server. Oft kommen dabei Fehler und Mängel in Client oder Server selber zum Vorschein. [Ronchetti 95], [Barta, Hauswirth 95] berichten unabhängig voneinander übereinstimmend davon, dass Endbenutzer das IS-Gateway gerne auch für Serverfehler verantwortlich machen.

6.2.5 Einführung und Betrieb

Falls ein existierendes IS-Gateway abgelöst wird, sei hier auf die Ausführungen zur Migration von IS-Gateways in Unterabschnitt 2.4.2 verwiesen. Ansonsten ist die Einführung normalerweise problemlos. So müssen beispielsweise keine Endbenutzer geschult werden. Sobald das IS-Gateway in Betrieb ist, können nach und nach weitere Arbeiten zwecks Nutzung des neuen IS-Gateways in Angriff genommen werden.

6.3 Schlussfolgerungen aus Kapitel 6

Die dritte Hypothese aus Abschnitt 1.3 lautete:

Hypothese 3:
Bereits die Berücksichtigung einiger weniger systematischer Kriterien kann den Entwurf, die Entwicklung und den Einsatz von IS-Gateways stark erleichtern.

In Kapitel 6 wurden Hinweise für den Praxiseinsatz von IS-Gateways gegeben. Die fünf Praxisbeispiele wurden implizit nach dieser Methode erstellt. Die dabei gemachten Erfahrungen weisen auf die Brauchbarkeit der angewandten Methoden hin.

7 SCHLUSSBEMERKUNGEN


7.1 Resultate

In dieser Arbeit wurde die komplexe Welt der globalen IS reduziert auf einfache Interaktionskonstrukte. Solche Interaktionskonstrukte bestehen aus einem Clienten und einem Server. Bei Differenzen in der Schnittstelle kann durch ein IS-Gateway vermittelt werden, das IS-Gateway muss sich dazu den Rahmenbedingungen anpassen. IS-Gateways haben eine Reihe von typischen Eigenschaften, die eine einfache Klassifikation zulassen. Eine Zusammenfassung der in Kapitel 3 diskutierten Klassifikation gibt Bild 7.1

Für IS-Gateways wurde eine Referenzarchitektur definiert, welche die Entwicklung von generischen IS-Gateways unterstützt.

Im Umfeld verschiedener Anwendungen wurden als Praxisbeispiele fünf konkrete IS-Gateways realisiert. Sämtliche IS-Gateways wurden als Prototypen entwickelt. Es spricht für die Qualität dieser Prototypen, dass zwei davon (StD und WAB) in den produktiven Betrieb gingen. Einer davon, WAB, ist immer noch in Betrieb. StD wurde nach einem problemlosen Jahr überflüssig, weil das durch StD in W3 eingebundene Mono-IS SVI-Kurs aus betrieblichen Gründen durch eine neue, rein W3-basierte Lösung ersetzt wurde. Der Prototyp LibAgent wurde mit sämtlichen Unterlagen an die ETH-Bibliothek übergeben, wo inzwischen ein umfangreicheres produktives System entwickelt wird.
MerkmalFragestellungen
Grundlegend
FlexibilitätAnpassung an neue Situation durch Programmänderung oder Konfigurationsdatei? spezifisch/generisch
Umfang von Transformation und Vermittlung Verbindend oder integrierend?
Wieviel "sieht" der Client vom Server?
Funktionalität
Synchronisationsvermittlung Synchron/asynchron? Entfernte Prozeduren (RPC), meldungs-, dialogorientierte Kommunikation?
Zustandsvermittlung Zustände in Client oder Server? Wenn ja, stimmen sie überein?
Befehlsvermittlung Sprechen Client und Server dieselbe Sprache? Befehle?
Zusatzfunktionalität Wird zusätzliche Funktionalität angeboten?
DatenstrukturenStimmen sie überein?
SicherheitReine Firewalls? Verschlüsselte Kommunikation?
Zwischenspeicherung Puffer/Cache?
Entwurfsvarianten
ZuständeZustandsorientiertes/zustandsloses IS-Gateway?
Beständigkeit Flüchtig/beständig?
Logische Eingliederung Wo wird durch IS-Gateway auf den Server zugegriffen? Wie durch Client auf das IS-Gateway?

Bild 7.1 Übersicht über die IS-Gatewayklassifikation7.1 Übersicht über die IS-Gatewayklassifikation

7.2 Schlussfolgerungen aus dieser Arbeit

In der Einleitung wurden folgende drei Hypothesen aufgestellt:

1. Zur globalen Integration von Informationssystemen reicht die Definition präziser Schnittstellen alleine nicht aus. Im allgemeinen Falle sind zusätzliche Programme (IS-Gateways) notwendig, um die Lücken zu schliessen.

2. Durch den Einsatz von IS-Gateways ist prinzipiell jedes Informationssystem in ein globales Informationssystem integrierbar.

3. Bereits die Berücksichtigung einiger weniger systematischer Kriterien kann den Entwurf, die Entwicklung und den Einsatz von IS-Gateways stark erleichtern.

Im Verlauf dieser Arbeit konnten alle drei Hypothesen bestätigt werden. Es hat sich gezeigt, dass mit wenigen gezielten Kriterien IS-Gateways entwickelt werden können, die Brücken zwischen heterogenen Informationssystemen bauen, wo die Definition einer Schnittstelle alleine nicht ausreichend ist. Durch die Praxisbeispiele, fünf konkret realisierte IS-Gateways, wurde exemplarisch aufgezeigt, dass die präsentierte Theorie in die Praxis umgesetzt werden kann.

Um bestehende Systeme mit kleinstem Aufwand und möglichst ohne Änderungen in ein neues, umfassendes Gesamtsystem zu integrieren, sind als erstes geeignete Schnittstellen und Normen zu finden. Durch den Einsatz von möglichst generischen IS-Gateways können bestehende Systeme an Normen angepasst werden. Mit Rücksicht auf laufende Anwendungsprogramme und die Autonomie der Systembetreiber sind oft kaum Änderungen am bestehenden System möglich. Trotzdem können und sollen diese neuen Endbenutzern zur Verfügung gestellt werden. Kleinere Änderungen dürfen dabei in die Abklärungen einbezogen werden, erlauben diese jedoch oft den Einsatz von bestehenden, generischen IS-Gateways.

Grundsätzlich sollen diese Erkenntnisse auch in die Ausbildung von Informatikern einfliessen. Neben dem tiefgehenden Studium der verschiedenen Arten von Informationssystemen und ihren Eigenschaften, müssen übergeordnete Ziele verstärkt in den Vordergrund gestellt werden. Dabei sollte gerade angesichts der Komplexität heutiger Informationssysteme deren Nutzung über geeignete IS-Gateways einbezogen werden; so lassen sich überraschende Ergebnisse erzielen.

7.3 Ausblick auf zukünftige Entwicklungen

7.3.1 Einbezug der Semantik

Von verschiedener Seite wird versucht, durch den vermehrten und automatischen Einbezug der Semantik der Daten Teilsysteme globaler IS besser einzubinden. Bisherige Resultate, beispielsweise bei der automatischen Schemaintegration, sind jedoch nicht besonders überzeugend. Wie in der "künstlichen Intelligenz" (und häufig auf ähnlichen Techniken basierend) scheint sich die automatische Berücksichtigung der Semantik der Daten bei Entwurf und Implementation von IS-Gateways nur in eng abgegrenzten Gebieten zu lohnen.

7.3.2 Weitere Kommunikationsarten

Meldungsorientierte Kommunikationsarten kamen bisher vor allem in der Kommunikation innerhalb der Teilsysteme vor. Mit der Verbreitung der CORBA-Architektur und dem Aufkommen von Object Request Broker ergeben sich grundlegend neue Aspekte. Auch Objekte, bisher nur in der "objektorientierten Programmierung" verbreitet, bekommen ein globales Eigenleben. Es wird nicht mehr nur auf Daten, sondern auf Objekte zugegriffen. Anstelle der direkten oder durch ein Datenverwaltungssystem unterstützten Datenmanipulation tritt das Aufrufen von Methoden. Die Objekte kontrollieren sich dabei selber. Dadurch wird das Problem der Einbindung wesentlich komplexer. Die Anzahl an Objekten in einem globalen IS ist um Grössenordungen grösser als die Anzahl von Informationssystemen. Die Integration vieler heterogener Objekte in ein Gesamtsystem ist ein noch ungelöstes Problem.

ANH&AUML;NGE


Anhang A: SGIS Referenz


Bild B.1 SGIS Referenz - statische AspekteB.1 SGIS Referenz - statische Aspekte

Die statischen Aspekte globaler Informationssystem werden wie folgt aufgezeigt: Mit Kästchen werden Programme angegeben. Clienten werden immer oberhalb der zugehörigen Server gezeichnet. IS-Gateways, Programme deren einzige Funktion die Vermittlung zwischen inkompatiblen Schnittstellen ist, werden mit abgerundeten Ecken dargestellt. Verbindungen werden durch Linien dargestellt. Schnittstellen werden zum Schnittpunkt zwischen Verbindung und Programm geschrieben. Die Art der Verbindung gibt an, ob keine, eine oder mehrere Verbindungen gleichzeitig möglich sind.


Bild B.2 SGIS Referenz - dynamische AspekteB.2 SGIS Referenz - dynamische Aspekte

Die dynamischen Aspekte globaler Informationssystem werden durch Pfeile in Zeit-Diagrammen dargestellt. Die Beständigkeit von Programmen und die Art der Kommunikation kann so dargestellt werden.

Anhang B: Ein Beispiel für ein IDLE-Programm: svi.idle

Die Zeilennummern im folgenden Programm wurden nachträglich eingeführt.1. (* Demonstration of IDLEIDLE: A Description of SVI-Kurs *)



2. BACKPHASE START3. BEGIN (* Open the service (* Let's go *) *)4. OPEN PORT "ezinfo.ethz.ch" 23;5. WRITE "\r\n";6. READ UPTO "Username: ";7. WRITE "GAST\r\n";8. READ UPTO "\27\[c"; (* Query device attributes *)9. WRITE "\27[?1;2c"; (* Complete vt100 *)10. READ UPTO "ezInfo>";11. WRITE "EXT SVI\r\n";12. READ COUNT 100;13. READ UPTO ">";14. WRITE "4";15. id := "";16. vorw := "mehr";17. list := ""; WRITE "\r\n";18. weiter := "0";19. READ UPTO "Liste aller Veranstaltungen";20. WHILE vorw = "mehr" DO21. READ UPTO "\(";22. READ COUNT 1 INTO nr;23. IF nr = "V" THEN24. weiter := "1";25. WRITE "v"; 26. id := CONCAT (id, "v");27. ELSE28. IF nr = "R" THEN29. IF weiter = "1" THEN30. weiter := "0";31. ELSE32. vorw := "";33. END;34. ELSE35. READ UPTO "H";36. READ COUNT 1 INTO nr;37. READ UPTO "\)";38. END;39. END;40. IF nr CONTAINS "[1-6]" THEN41. READ UPTO "H";42. READ UPTO "H";43. READ UPTO "\27" INTO item;44. item := LEFTOF (item, "\27");45. item := CONCAT (item, "!");46. item := CONCAT (item, FIRST (id));47. item := CONCAT (item, "!");48. item := CONCAT (item, FIRST (nr));49. list := ADD (list, item);50. END;51. END;
52. (* Reset SVI to the menu *)
53. WRITE "m";
54. READ UPTO "\(E\)xit\27";55. FRONT Auswahl;56. END57. FRONTPHASE Auswahl58. BEGIN59. PAGE60. OUTPUT TITLE "SVI-Kurs";61. OUTPUT HEADER 1 "Alle Kurse auf einen Blick";62. FOREACH item IN list DO63. text := LEFTOF (item, "!");64. id := RIGHTOF(item, "!");65. INPUT REF (FIRST (text), FIRST (id)) INTO wahl;66. END;67. INPUT REF ("Stop the svi-script.", "stop") INTO wahl;68. END;69. IF wahl # "stop" THEN70. BACK Detail;71. END;72. END73. BACKPHASE Detail74. BEGIN75. WRITE "4"; 76. pages := LEFTOF (wahl, "!");77. (* skip pages *)78. WHILE pages CONTAINS "v" DO79. READ UPTO "orwaerts blaettern";80. WRITE "v";81. pages := RIGHTOF (pages, "v");82. END;83. (* Skip last page *)84. READ UPTO "blaettern";85. (* Send the relative ID *)86. WRITE RIGHTOF (wahl, "!");87. (* Scan the info *)88. READ UPTO "\27\[5;14H"; (* Start of title *)89. READ UPTO "\27" INTO title;90. title := LEFTOF (title, "\27");91. READ UPTO "\27\[6;";92. READ COUNT 1 INTO tmp;93. READ UPTO "H";94. IF tmp = "1" THEN (* Title has 2nd line *)95. READ UPTO "\27" INTO title2;96. title := ADD (title, LEFTOF (title2, "\27"));97. END;98. (* Date *)99. READ UPTO "\27\[8;14H";100. READ UPTO "\27" INTO datevon;101. datevon := LEFTOF (datevon, "\27");102. READ UPTO ":.*H";103. READ UPTO "\27" INTO datebis;104. datebis := LEFTOF (datebis, "\27");105. (* Typ *)106. READ UPTO "\27\[8;53H:\27\[8;";107. READ COUNT 1 INTO tmp;108. IF tmp = "5" THEN (* Typ present *)109. READ COUNT 2;110. READ UPTO "\27" INTO typ;111. typ := LEFTOF (typ, "\27");112. ELSE113. typ := "-";114. END;
115. (* Ort *)116. READ UPTO "\27\[10;12H:\27\[10;";
117. READ COUNT 1 INTO tmp;118. IF tmp = "1" THEN (* Ort present *) 119. READ COUNT 2;120. READ UPTO "\27" INTO ort;121. ort := LEFTOF (ort, "\27");122. ELSE123. ort := "-";124. END;125. (* Sprache *)126. READ UPTO "\27\[10;53H:\27\[10;";127. READ COUNT 1 INTO tmp;128. IF tmp = "5" THEN (* Lang present *)129. READ COUNT 2;130. READ UPTO "\27" INTO lang;131. lang := LEFTOF (lang, "\27");132. ELSE133. lang := "-";134. END;135. (* Skip to end of page *)136. READ UPTO "\27\[22;5H";137. WRITE "m";138. FRONT ZeigeDetail; 139. END140. FRONTPHASE ZeigeDetail141. BEGIN142. PAGE143. OUTPUT TITLE "Detailinformationen SVI-Kurs";144. OUTPUT HEADER 1 title;145. OUTPUT "Datum: ";146. OUTPUT datevon;147. IF datebis # "" THEN148. OUTPUT " bis ";149. OUTPUT datebis;150. END;151. OUTPUT "Typ der Veranstaltung: ";152. OUTPUT typ;153. OUTPUT "Ort der Veranstaltung: ";154. OUTPUT ort;155. OUTPUT "Veranstaltungssprache: ";156. OUTPUT lang;157. INPUT REF ("Zurueck zur Auswahl", "1") INTO wahl;158. END;159. IF wahl="1" THEN160. PRINT "und nochmal...";161. BACK dummy;162. END;163. END164. BACKPHASE dummy165. BEGIN166. FRONT Auswahl;167. END

LITERATURVERZEICHNIS


Einige Referenzen beziehen sich teilweise oder ausschliesslich auf online verfügbare Dokumente. Bei solchen Referenzen ist jeweils in Klammern das Datum des Zugriffs angegeben.

[Aebi 96]
Aebi, D.: Re-Engineering und Migration betrieblicher Nutzdaten. Diss. ETH Zürich. 1996. <ftp://ftp.inf.ethz.ch/pub/publications/dissertations/th11628.ps> (24.6.96).

[Arens et al. 94]
Arens, Y., Chee, C. Y., Hsu, C. nan, Knoblock, C. A.: Retrieving and integrating data from multiple information sources. International Journal on Intelligent and Cooperative Information Systems, 1994. S. 127-158. <http://www.isi.edu/sims/papers/94-sims-piwksp.ps> (21.5.96).

[Balestra, Ferruci 95]
Balestra, A., Ferruci, M.: Accessing Libraries in a Uniform Way: The CUBAI Project. Zusammenfassung in Computer Networks and ISDN Systems, Vol. 27 (1994), No. 2, November 1994. S. 330. Der Dienst selbst ist unter <http://www.oat.ts.astro.it/biblio/biblio.html> (28.2.96) verfügbar.

[Barta, Hauswirth 95]
Barta, R. A., Hauswirth, M.: Interface-Parasite Gateways. World Wide Web Journal: Issue One: Conference Proceedings, Fourth International Conference on the World-Wide Web (4WWW95), Boston, MA, Dezember 1995. O'Reilly & Associates, Inc. ISBN 1-56592-169-0. S. 227-290. <http://www.w3.org/pub/Conferences/WWW4/Papers/273/> (15.5.96).

[Berners-Lee et al. 94]
Berners-Lee, T., Cailliau, R., Luotonen, A., Nielsen, H. F., Secret, A.: The World-Wide Web. Communication of the ACM. Vol. 37, No 8, August 1994. S. 76-82.

[Bosshard et al. 95]
Bosshard, A., Marti, M., Ullius, M., Wili, R.: World Wide Web Access for Blinds. Semesterarbeit. Institut für Informationssysteme, ETH Zürich. 1995. <http://www.inf.ethz.ch/department/IS/ea/blinds/> (1.6.96).

[Brodie, Stonebraker 95]
Brodie, M. L., Stonebraker, M.: Migrating Legacy Systems: Gateways, Interfaces & the Incremental Approach. Morgan Kaufmann Publishers, Inc. ISBN 1-55860-330-1.

[Brooks et al. 95]
Brooks, Ch., Mazer, M. S., Meeks, S., Miller, J.: Application Specific Proxy Servers as HTTP Stream Transducers. World Wide Web Journal: Issue One: Conference Proceedings, Fourth International Conference on the World-Wide Web (4WWW95), Boston, MA, Dezember 1995. O'Reilly & Associates, Inc. ISBN 1-56592-169-0, S. 539-548. <http://www.w3.org/pub/Conferences/WWW4/Papers/56/> (28.2.96), <http://www.osf.org/www/waiba/papers/www4oreo.htm> (28.2.96).

[Bush 45]
Bush, V.: As We May Think. Atlantic Monthly, July 1945. <http://www.isg.sfu.ca/~duchier/misc/vbush/> (20.5.96).

[CGI 96]
The Common Gateway Interface. <http://hoohoo.ncsa.uiuc.edu/cgi/overview.html> (10.5.96).

[Coleman et al. 94]
Coleman, D., Ash, D., Lowther, B., Oman, P.: Using Metrics to Evaluate Software Systems Maintability. IEEE Computer, Vol. 27, No. 8, August 1994, S. 44-49.

[Collet et al. 91]
Collet, C., Huhns, M. N., Shen, W.-M.: Resource integration using a large knowledge base in Carnot. IEEE Computer, S. 55-62. <http://www.mcc.com/projects/carnot/carnot-paper.html> (15.6.96).

[Date 95]
Date, C. J.: An Introduction to Database Systems. Addision Wesley. 6. Auflage, 1995.

[De Lorenzi 96]
De Lorenzi, M.: Extending a Library for Geometric Computation to Provide Network Services: A Case Study. Diss. ETH Zürich. 1995. <ftp://ftp.inf.ethz.ch/pub/publications/dissertations/th11267.ps> (1.3.96)

[Engelbart 62]
Engelbart, D. C.: Augmenting Human Intellect: A Conceptual Framework. Summary Report, Stanford Research Institute, Oktober 1962.

[Fischer 95]
Fischer, R.: Translation Server. Diplomarbeit. Institut für Informationssysteme, ETH Zürich. 1995.

[Harris 94]
Harris, R.: Computer Science Technical Reports Abstracts Database. <wais://rdt.monash.edu.au/cs-techreport-abstracts> (5.3.96).

[Hörmann 95]
Hörmann, P.: A W3 Online Kiosk for Admission Purposes. Proceedings of the Workshop on World-Wide Web Based Online Kiosk Systems of the Third International Conference on the World-Wide Web (WWW'95), Darmstadt, April 1995. S. 3. <ftp://ftp.inf.ethz.ch/pub/publications/proceedings/W3-kiosk.html> (15.5.96).

[HP 95]
Hewlett-Packard: Open Enterprise Computing (OEC). <http://www.dmo.hp.com/gsy/1a1.html> (27.2.96).

[I3 95]
I3 Initiative Homepage. <http://haifa.isx.com/pub/I3/> (15.5.96).

[IBM 95]
IBM: Open Blueprint. <http://www.software.ibm.com/openblue/OPENBLUE.HTM> (27.2.96).

[ISO 9735:1988]
ISO TC 154 Documents and data elements in administration, commerce and industry: ISO 9735:1988: Electronic data interchange for administration, commerce and transport (EDIFACT) --Application level syntax rules. Amended and reprinted 1990, Amendment 1:1992.

[ISO 10162:1993]
ISO TC 46/SC 4 Computer applications in information and documentation: ISO 10162:1993: Search and Retrieve Application Service Definition for Open Systems Interconnection. 1991.

[ISO 10303:1994]
TC 184 / SC 4 Industrial data and global manufacturing languages: ISO 10303:1994: Industrial automation systems and integration -- Product data representation and exchange. 1994.

[Java 95]
Sun Microsystems: Java/Hot Java. <http://java.sun.com/> (15.5.96).

[Jennings 94]
Jennings, N. R.: The ARCHON System and its Applications, Second International Working Conference on Cooperating Knowledge Based Systems (CKBS-94) (Invited Paper), Keele, UK, 1994, S. 13-29. <ftp://ftp.elec.qmw.ac.uk/pub/keag/distributed-ai/publications/CKBS94.ps.Z> (15.5.96).

[Kennel et al. 96]
Kennel, A., Perrochon, L., Darvishi, A.: WAB: World-Wide Web Access for Blind And Visually Impaired Computer Users. Proc. New Technologies in the Education of the Visually Handicapped, Paris, June 1996. ACM SIGCAPH Bulletin, June 1996. <http://www.inf.ethz.ch/department/IS/ea/publications/sigcaph95.ps> (15.5.96).

[Kindel 95]
Kindel, C.:Industrial Strength OLE: Using Microsoft's Object Technology to Build Business Solutions. Microsoft. 1995. <http://www.microsoft.com/DEVNEWS/ARCHIVE/MAINOLE5.HTM> (10.2.96).

[Levy et al. 95]
Levy, A. Y., Srivastava, D., Kirk, T.: Data Model and Query Evaluation in Global Information Systems. Journal of Intelligent Information Systems, Vol. 5, No. 2, September 1995. S. 121-143. <http://www.research.att.com/orgs/ssr/people/levy/jiis95.ps.Z> (15.6.96)

[Lin, Chung 95]
Lin, Y., Chung, J..: Web Access to IBM Legacy Systems Data. Workshop on Providing Web Access to Legacy Data of the Fourth International Conference on the World-Wide Web (4WWW95), Boston, MA, Dezember 1995. S. 15-17. <http://www.cs.brown.edu/people/yjl/legacy2www.html> (15.6.96)

[Marinoff 95]
Marinoff, T. N.: Cambridge's Public Information Project. Proceedings of the Workshop World-Wide Web Based Online Kiosk Systems of the Third International Conference on the World-Wide Web (WWW'95), Darmstadt, April 1995. S. 4-5. <ftp://ftp.inf.ethz.ch/pub/publications/proceedings/W3-kiosk.html> (15.5.96)

[Müller 96]
Müller, D.: LibAgent. Diplomarbeit. Institut für Informationssysteme, ETH Zürich, 1996 <http://ea.ethz.ch/libagent/> (15.5.96).

[Nieman 95]
Niemann, K. D.: Client/Server-Architektur, Organisation und Methodik der Anwendungsentwicklung. Vieweg, Braunschweig, 1995.

[NIIIP 96]
The National Industrial Information Infrastructure Protocols (NIIIP). <http://www.niiip.org> (23.2.96).

[OMG 91]
OMG.: The Common Object Request Boker: Architecture and Specification. OMG Document 91. Mai 1991.

[Papakonstantinou et al. 94]
Papakonstantiou, Y., Garcia-Molina, H, Widom, J.: Object Exchange Across Heterogeneous Information Sources. Technical Report, Stanford University Computer Science Department, 1994. <ftp://db.stanford.edu/pub/papakonstantinou/1994/> (1.6.96).

[Perrochon 94a]
Perrochon, L.: Multiple Service Integration Confronted with Legacy Systems. Proceedings of the Workshop Offering the same Information via multiple services of the First International Conference on the World-Wide Web (WWW'94), Geneva, Mai 1994. <http://www.inf.ethz.ch/department/IS/ea/publications/www94.html> (1.6.96).

[Perrochon 94b]
Perrochon, L.: Translation Servers: Gateways Between Stateless and Stateful Information Systems. Network Services Conference 1994 (NSC'94), London, November 1994. <http://www.inf.ethz.ch/department/IS/ea/publications/nsc94.html> (1.6.96).

[Perrochon 95a]
Perrochon, L.: World-Wide Web: Konzepte und Grundlagen. INFORMATIK/INFORMATIQUE 2/95. April 1994. S. 3-7 <http://ea.ethz.ch/svifsi/informatik/1995-2/artperro.html> (1.6.96).

[Perrochon 95b]
Perrochon, L.: (Ed.): Proceedings of the Workshop on World-Wide Web Based Online Kiosk Systems of the Third International World-Wide Web Conference (WWW'95) Darmstadt, Germany, April 1995. <ftp://ftp.inf.ethz.ch/pub/publications/proceedings/W3-kiosk.html> (1.6.96).

[Perrochon 95c]
Perrochon, L.: W3 "Middleware": Notions and Concepts. Workshop on Providing Web Access to Legacy Data of the Fourth International Conference on the World-Wide Web (4WWW95), Boston, MA, Dezember 1995. S. 26-36. <http://www.inf.ethz.ch/department/IS/ea/publications/4www95.html> (1.6.96).

[Perrochon 95d]
Perrochon, L.: On the Integration of Legacy Information Servers into the World-Wide Web. Part of the Internet-Tutorial of the first joint annual meeting 1995 of the Gesellschaft für Informatik (GI) and the Schweizer Informatiker Gesellschaft (SI) (GISI'95), Zürich, Schweiz, September 1995. Informatik aktuell. Springer, 1995, S. 57-60. <http://www.inf.ethz.ch/department/IS/ea/publications/gisi95.html> (1.6.96).

[Perrochon, Büchel 95]
Perrochon, L., Büchel, M. M.: Building a W3-Kiosk with Existing Products. Proceedings of the Workshop World-Wide Web Based Online Kiosk Systems of the Third International Conference on the World-Wide Web (WWW'95), Darmstadt, April 1995. S. 6-8. <ftp://ftp.inf.ethz.ch/pub/publications/proceedings/W3-kiosk.html> (1.6.96).

[Perrochon, Fischer 95]
Perrochon, L., Fischer R.: IDLE: Unified W3-Access to Interactive Servers. The Third International World-Wide Web Conference 1995 (WWW'95), Darmstadt, April 1995. Computer Networks and ISDN Systems 27 (1995) S. 927-938. <http://www.inf.ethz.ch/department/IS/ea/publications/www95.html> (1.6.96).

[Ronchetti 95]
Ronchetti, M.: Face Lift: using WWW technology for an external reengineering of old applications. Poster at the Third International World-Wide Web Conference 1995 (WWW'95), Darmstadt, April 1995. S. 37-40. <http://www.inf.unitn.it/~ronchet/CBT> (1.6.96).

[Ronchetti et al. 95]
Ronchetti, M., Feltrin, D., D'Andrea, V., Succi, G.: External reengineering of "Catalogo Bibliografico Trention": lessons learned. Workshop on Providing Web Access to Legacy Data of the Fourth International Conference on the World-Wide Web (4WWW95), Boston, MA, Dezember 1995. <http://athos.rutgers.edu:80/~shklar/www4/ronchetti.html> (6.3.96).

[Schäuble 94]
Schäuble, P. Benutzeranleitung für INFBIB - ein Information Retrieval System für die Informatik-Bibliothek. Institut für Informationssysteme. ETH Zürich. 1994.

[Sheth 91]
Sheth, A.: Semantic Issues in Multidatabase Systems. SIGMOD Record, special issue on Semantic Issues in Multidatabases. A. Sheth, ed., 20(4), Dezember 1991.

[Sheth, Kashyap 92]
Sheth, A., Kashyap, V.: So Far (Schematically) yet So Near (Semantically). Invited talk. Proceedings of the IFIP TC2/WG2.6 Conference on Semantics of Interoperable Database Systems, DS-5, Australia, Nov. 1992. Elsevier Scientific Publishers B. V. <http://lsdis.cs.uga.edu/~amit/41-sofar-sonear.ps> (15.5.96).

[Sheth, Larson 90]
Sheth, A. P., Larson, J. A.: Federated Database Systems for Managing Distributed, Heterogeneous, and Autonomous Databases. ACM Computing Surveys, Vol. 22, No. 3, September 1990. S. 183-236.

[Tibbetts 95]
Tibbetts, J.: Enterprise Architectures: A Comparison of Vendor Initiatives. IBM 1995. <http://www.software.ibm.com/openblue/KX95/COVER.HTM> (27.2.96).

[WAIS 88]
WAIS, Inc. <http://www.wais.com>, ERIN: WAIS Technical Notes and Pointers <http://kaos.erin.gov.au/technical/wais/wais_technical.html> (1.6.96)

[Widom 95]
Widom, J.: Research Problems in Data Warehousing. Proceedings of the 4th Int'l Conference on Information and Knowledge Management (CIKM), November 1995. <http://www-db.stanford.edu/pub/widom/1995/warehouse-research.ps> (10.5.96)

[Wiederhold 94]
Wiederhold, G.: Interoperation, Mediation, and Ontologies. Proceedings International Symposium on Fifth Generation Computer Systems (FGCSOB94), Workshop on Heterogeneous Cooperative Knowledge-Bases, Vol. W3, S. 33-48, ICOT, Tokyo, Japan, Dezember 1994. <http://db.stanford.edu/pub/gio/1994/medont.ps> (1.5.96)

[Wiederhold 95]
Wiederhold, G.: Mediation and Software Maintenance. Technical Note STAN-CS-TN-95-26. Modeling for Software System Maintenance. Ansprache an der ER-OO Konferenz, Brisbane Australia, Dezember 1995. In Michael P. Papazoglou (ed.): OOER'95: Object-Oriented and Entity Relationship Modeling. Springer Lecture Notes in Computer Science, Vol. 1021, S. 1-20; Proceedings of the ER-OO conference, Brisbane Australia, December 1995. <http://db.stanford.edu/pub/gio/1995/er.ps> (27.3.96)

[Wittig et al. 94]
Wittig, T., Jennings, N. R., Mamdani, E. H.: ARCHON - A Framework for Intelligent Cooperation. IEE-BCS Journal of Intelligent Systems Engineering - Special Issue on Real-time Intelligent Systems in ESPRIT, 3 (3) S. 168-179. <ftp://ftp.elec.qmw.ac.uk/pub/keag/distributed-ai/publications/IEE-BCS-JISE94.ps.Z> (1.6.96)

[Wunderli 96]
Wunderli, M.: Datebase Technology for CIM Subsystems. Diss. ETH Zürich. 1996 (erwartet). <ftp://ftp.inf.ethz.ch/pub/publications/dissertations/> (1.6.96)

[Zehnder 91]
Zehnder, C. A.: Informatik-Projektentwicklung. vdf Verlag Zürich. 2.Auflage, 1991. ISBN 3 7281 1761 7.

[Zehnder 96]
Zehnder, C. A.: Gestaltung grosser Informationssysteme. Vorlesungsskript. Institut für Informationssysteme, ETH Zürich, 1996.

[Zollinger 95]
Zollinger, M.: Zugriff auf relationale Datenbestände mittels World Wide Web am Beispiel SVI-Kurs. Semesterarbeit. Institut für Informationssysteme, ETH Zürich, 1995.

LEBENSLAUF


Am 2. September 1967 wurde ich in Bern geboren. Dort verbrachte ich die gesamte Schulzeit. 1986 schloss ich diese am Gymnasium Neufeld mit der naturwissenschaftlichen Matura Typus C ab. Anschliessend absolvierte ich die Rekrutenschule und war in verschiedenen Stellen tätig.

Im Herbst 1987 nahm ich das Informatikstudium an der ETH Zürich auf. Das Studium vertiefte ich in den Bereichen Hardware und Theoretische Informatik. Die Diplomarbeit führte ich bei Prof. P. Läuchli unter der Leitung von Dr. K. Simon aus. Im Frühjahr 1992 schloss ich das Studium als dipl. Informatik-Ingenieur ETH ab.

Von 1992 bis 1996 arbeitete ich als Assistent am Institut für Informationssysteme der ETH Zürich in der Gruppe von Prof. C. A. Zehnder. Dabei standen neben der Mitarbeit in der Lehre und der Betreuung von Studienarbeiten Projekte vor allem im Bereich der globalen Informationssysteme im Zentrum meiner Tätigkeit. 1992 bis 1993 war ich gleichzeitig in Teilzeit als Abteilungssekretär der Abteilung für Informatik (IIIC) zuständig für Studienberatung und administrative Belange des Studienbetriebs.

VERZEICHNIS DER BILDER


1.1 Frau Müllers Situation: Problem 141.2 Frau Müllers Situation: Lösungsansatz 141.3 Realisierte IS-Gateways 182.1 Aufbau eines Mono-IS 222.2 Varianten der Client-Server-Architektur bei Mono-IS 232.3 Ein globales Informationssystem 252.4 Einfache Client-Server-Architektur 292.5 Mehrstufige Client-Server-Architektur 302.6 Situation mit Rollenwechsel 322.7 Vielfalt der Benutzerschnittstellen 332.8 Vielfalt der Clienten 342.9 Vielfalt der Server 342.10 Vielfalt der Systemschnittstellen 352.11 Einfügen eines Gateways 362.12 Kaskade von IS-Gateways 372.13 Ein globales Informationssystem mit IS-Gateways 382.14 Kosten für Verbreitung und Bezug von Information 402.15 Änderung eines Teilsystems führt zu Inkompatibilitäten 412.16 Auffangen der Folgen von Änderungen mit IS-Gateways 422.17 Einsatz von Reverse- und Forward-IS-Gateways 432.18 Inkrementeller Ersatz von Schnittstellen dank IS-Gateways 443.1 Die grundlegenden Klassifikationsdimensionen bei IS-Gateways 573.2 Funktionalitätsumfang von Transformation und Vermittlung 593.3 Synchrone und asynchrone Kommunikation 603.4 Meldungsorientierte Kommunikation 613.5 Entfernte Prozeduraufrufe 623.6 Dialogorientierte Kommunikation 623.7 Zustandsorientierte und zustandslose Kommunikation 633.8 Beispiel für Befehlsvermittlung 663.9 "Rückwärtsblättern" durch das Gateway 683.10 Verschlüsselung durch Gateways 693.11 Beständigkeit bei IS-Gateways 713.12 Beständigkeits- und Zustandsproblematik 713.13 Daten-Gateway 723.14 Systemschnittstellen-Gateway 733.15 Benutzerschnittstellen-Gateway 743.16 Referenzarchitektur für IS-Gateways 763.17 Zyklisches Zustandsdiagramm eines IS-Gateways 793.18 Multigateway 813.19 Multigateway-Architektur 823.20 Architektur des Gatewaymanagers 824.1 IDLE 854.2 Phasen in IDLE 884.3 SVI-Kurs auf ezInfo und W3 894.4 Syntax von IDLE 935.1 CGI-basierte IS-Gateways in W3 1055.2 Funktionsweise des Translation Servers 1075.3 Realisierte IDLE-Programme 1115.4 Architektur von LibAgent 1145.5 Architektur von StD 1195.6 EBNF-Syntax von StD-SQL 1215.7 Foto PubDINIS-Kiosk 1245.8 Architektur von PubDINIS 1265.9 Architektur von WAB 1307.1 Übersicht über die IS-Gatewayklassifikation 140B.1 SGIS Referenz - statische Aspekte 144B.2 SGIS Referenz - dynamische Aspekte 145

STICHWORTVERZEICHNIS


Fett sind Verweise auf Definitionen oder einführende Erklärungen.

Agent, 28; 53; 59ARCHON, 53Benutzerschnittstelle, 22Browser, 27Carnot, 52Client, 27CORBA, 51Data Warehouse, 28Daten, 21Datenbestand, 22Datenschema, 22Datenschnittstelle, 22Datenverwaltungssystem, 22; 72Dienst, 26Einbindung, 12Endbenutzer, 39ETHICS, 17; 104Firewall, 59Gateway, siehe IS-GatewayHyperlink, 104; 118I3 (Intelligent Integration of Information), 28; 49; 52IDLE, siehe auch TS/IDLE; 19; 73; 77; 85; 106; 146IM, 49Information, 21Informationsanbieter, 39Informationsquelle, 26Informationsserver, 26Informationssystem, 21globales, 24Mono-, 21; 22Integration, 104Interaktionskonstrukt, 30IS-Gateway, 13; 14; 36Benutzerschnittstellen-, 73beständig, 71Daten-, 72flüchtig, 71generisch, 57; 75IS-, 36spezifisch, 57Systemschnittstellen-, 72verbindend, 59Kommunikationmeldungsorientiert, 61synchron/asynchron, 60; 61Label, 104LibAgent, 19; 81; 106; 111; 113Metadaten, 31; 78Middleware, 53Mono-IS, 21Monoinformationssystem, 22Multigateway, 81NIIIP (National Industrial Information Infrastructure Protocol, 50Nutzdaten, 31; 76; 78OLE, 52PubDINIS, 19; 124; 129Referenzarchitektur, 75RPC (Remote Procedure Call), 61; 104Schemaintegration, 50; 52; 54Semantik, 74Server, 26SIMS, 49SQL, 51StD, 19; 72; 77; 118StD-SQL, 121Steuerdaten, 31; 66; 78SVI-Kurs, 18; 88Systemschnittstelle, 22Three-Tier-Architecture, 28; 30Transformation, 37TS/IDLE, 19; 48; 73; 83; 106TV (Transformationsvorschrift), 76Vermittlung, 36W3 (World Wide Web), 17; 45; 102WAB, 20; 77; 124; 128Zustand, 63; 70; 78