Die Entwicklung eines heterogenen Netzes, das Zugriff und Anwendungen auf Rechnern unterschiedlicher Typen wie Hersteller ermöglicht und darüber hinaus auch Zugang zu internationalen Netzen anbietet, ohne daß der Benutzer seine gewohnte Rechnerumgebung verläßt, ist eines der wesentlichen Themen der vierjährigen Forschungskooperation zwischen der Universität Karlsruhe und der IBM. Horst Wettstein und (Oswald Drobnik* geben einen Überblick über das Projekt

Die in der Mitte unseres Jahrhunderts aufgekommenen elektronischen Datenverarbeitungsanlagen waren nach heutigem Verständnis ihrer Art und ihrer Diktion nach Zentralrechner. In der Tat war etwa ab 1960 für zirka zwei Jahrzehnte die typische Betriebsform die des geschlossenen Rechenzentrums. Der Benutzer gab seine zu erledigenden Aufgaben dort ab und erhielt die Ergebnisse nach einer angemessenen Zeit wieder zurück. Die Rechenanlage selbst bekam er selten zu Gesicht. Trotzdem entwickelte sich unter der Regie des Rechenzentrums eine Art Benutzergemeinschaft, in der die einzelnen Mitglieder voneinander profitierten. Jeder einzelne Programmentwickler war nämlich aufgefordert, seine Programme nach Fertigstellung, sofern diese von allgemeinen Interesse waren, dem Rechenzentrum zu überlassen. Jenes stellte die Produkte in eine Bibliothek ein und bot sie damit der Benutzergemeinschaft zum Gebrauch an. Wer wollte, konnte auf diesen Vorrat zurückgreifen und dadurch seine eigene Arbeit erleichtern.

Diese Gemeinschaften lösten sich etwa ab der Mitte der siebziger Jahre allmählich auf, nachdem es mehr und mehr den dezentralen Institutionen als Folge der Verbilligung der Datenverarbeitungsanlagen möglich war, eigene Geräte zu installieren. Vollends besiegelt war das Schicksal der Benutzergemeinschaften mit dem Aufkommen der sogenannten Arbeitsplatzrechner. Jetzt arbeitete jeder Programmentwickler für sich; ein Austausch von Programmen wurde schwierig und war häufig eher von Zufälligkeiten bestimmt. Damit war aber auch der gegenseitige Nutzen nicht mehr möglich.

Vernetzung

So wie sich die Natur in schwierigen Situationen irgendwie zu helfen weiß, so zeigte sich auch im Hinblick auf die Benutzergemeinschaften bald eine Entwicklung die die Grundlage zur Überwindung der geschilderten Nachteile legte, nämlich die Möglichkeit, Informationsverarbeitungsanlagen - so die heutige Sprechweise - zu verbinden, ja in größerer Anzahl gar zu vernetzen. Diese Vernetzung, auf welcher technischen Grundlage auch immer erlaubte zunächst allerdings nur die rein physische Übertragung von Daten von einer Anlage zu einer anderen. Zu welchen Zweck und in welchem Zusammenhang dies geschah, war eine davon gänzlich getrennte Entwicklung.

Auf der Basis der phisikalischen Verbindungen entwickelten sich daher zunächst lediglich die zum bloßen Transport notwendigen Mechanismen. dabei waren Aufgabe der Zuverlässigkeit, des Wegefindens, der Flußkontrolle etc. zu lösen. Darauf konnten dann die heute weitverbreiteten Netzdienste wie Dateitransfer, Elektronische Post und ähnliches aufgebaut werden. Diese bestehen tatsächlich im wesentlichen aus Adressierungs- und Transportvorgängen. Solche Dienste sind heute recht weit entwickelt, zum Teil verbindlich standardisiert oder im Stadium der Standardisierung.

Netzdienste

Mit den geschilderten Netzdiensten kann ein Benutzer eine Datei, die auf einem andren ihm bekannten Rechner lagert, auf seine eigene Anlage übertragen und dort wie eine lokale Datei einem Anwendungsprogramm zur Verfügung stellen. Auch der umgekehrte Fall, daß nämlich ein Programm an einen entfernten Ort transportiert und dort zur Ausführung gebracht wird, ist möglich und wird angewendet. Von einigen wenigen Ausnahmefällen abgesehen ist dem Benutzer aber die Tatsache der Einbeziehung eines anderen Rechners des Netzes bewußt. Er muß dessen Adresse sowie meist mehrere Netzbediensprachen kennen und anwenden. Dies stellt im Grunde genommen eine unnötige Erschwernis der Inanspruchnahme eines Netzes dar. Für einen gewöhnlichen Benutzer sollte es genügen, die ihn interessierenden Objekte einfach zu nennen. Netzdienste sollten ausreichend intelligent sein, diese Objekte für den Benutzer im Netz zu lokalisieren und ihre Benutzung zu ermöglichen. Dies in einer Pilotversion zu realisieren, ist das fundamentale Ziel des Informationsverarbeitungsverbundes im Rahmen des "Hector" -Projektes.

Benutzersicht

Normalerweise sieht ein einzelner Benutzer in einem Informationsverarbeitungssystem vordergründig drei Funktionsbereiche, nämlich die Möglichkeit,

* dem System über eine Bedieninstanz Weisungen zu erteilen,

* lagernde Anwendungsprogramme auszuführen,

* vorhandene Dateien und Betriebsmittel in Anspruch zu nehmen.

Damit läßt sich ein Verarbeitungssystem wie in einer der Spalten in Abbildung 1 darstellen. In einer größeren Institution wie beispielsweise einer Universität existieren nun zahlreiche solcher "Verarbeitungsinseln." Die erwünschte Benutzergemeinschaft kann dann wiedererstehen, wenn es gelingt, die genannten Bereiche so zu vereinigen, daß der Gesamtverbund dem einzelnen Benutzer wie ein einziger großer Rechner erscheint, der dann wiederum aus den drei Teilbereichen besteht.

Einfachere Formen eines solchen Verarbeitungsverbundes liegen vor wenn alle Anlagen identisch sind. Dann müssen im Grunde lediglich die einzelnen Benutzungspfade innerhalb einer Anlage auf die entsprechenden Instanzen in anderen Anlagen umgelenkt werden. In einer akademischen Umgebung stammen nun aber die Anlagen von unterschiedlichen Herstellern, sind mit unterschiedlichen Betriebssystemen ausgestattet, enthalten unterschiedliche Programme und sind mit unterschiedlichen Betriebsmitteln konfiguriert. Dies ist eine nicht zu ignorierende Tatsache. Sie entsteht deshalb weil eine Universität aus einer Vielzahl einzelner Entscheidungsträger mit spezifischen Außenbeziehungen und individuellen Beschaffungsvorgängen besteht.

Die Überwindung dieser Heterogenität ist daher ein entscheidendes Anliegen des "Hector"-Verbundes. Konkret soll dies für den einzelnen Benutzer bedeuten, daß er von jeder Zugangsstation aus zu jeder anderen Bedieninstanz, das heißt in jede andere Betriebssystemumgebung, vermittelt werden kann. Er braucht daher nur eine einzige Kommandosprache beziehungsweise Bedinoberfläche zu kennen. Von dieser oder seiner eigenen Umgebung aus kann er dann alle Anwendungen und alle Betriebsmittel im Netz, die der Gemeinschaft zur Verfügung gestellt sind, in Anspruch nehmen. Abbildung 2 zeigt als Beispiel ein Szenario einer verteilten Verarbeitung, wie sie sich ohne Zutun des Benutzers ausbilden kann.

Realisierung

Das "Hector"-Projekt ist eine experimentelle Pilotanstrengung. Es soll die grundsätzliche Machbarkeit eines heterogenen Verbundes zeigen. In diese Pilotversion werden drei unterschiedliche Typen von Rechenanlagen, nämlich IBM 43xx, IBM PC-xx sowie DEC 8xxx mit den Betriebssystemen CP/CMS, PC-DOS und MVS einbezogen. Eine der aufwendigsten Teilaufgaben stellt dabei ohne Frage die Integration ohne Berücksichtigung einer Verbundarchitektur gewachsener Betriebssysteme dar.

Zur Einrichtung eines heterogenen Informationsverarbeitungsverbundes müssen grundsätzlich die folgenden Teilaufgaben unterstützt werden:

* Kommunikationsdienste

* Lagerung von Objektbeschreibungen in Katalogen,

* Orientierung und Lokalisierung von Objekten im Netz,

* Zugriff auf entfernte Betriebsmittel,

* Transfer verschieblicher Betriebsmittel (Dateien),

* Ablaufkontrolle verteilter Verarbeitungen,

* Anpassungen an lokale Betriebssysteme.

Instanzen für diese Aufgaben stellen in ihrer Gesamtheit eine Erweiterung lokaler Betriebssysteme zu Netzbetriebssystemen dar. Für den Hector-Verbund wurden diese Teile (mehr als 200 000 Zeilen C-Programmcode) weitgehend betriebssystemunabhängig erstellt, um einen möglichst hohen Grad von Portierbarkeit zu erreichen. Abbildung 3 zeigt eine Skizze der Gesamtarchitektur.

Kommunikationsnetze

In einem heterogenen Verbund ordnet man einem Kommunikationsdienst neben dem eigentlichen Transport auch den Umgang mit den

Datenformaten beim Transport zu. Der Transport von einem zu einem

anderen Rechner ist dabei eine essentielle Basiseinrichtung. Deshalb

sind solche Komponenten allgemein auch am weitesten entwickelt. Das

ISO/OSI-Referenzmodell stellt dafür sogar verbindliche Normen zur Verfügung, deren Umsetzung in konkrete Produkte allerdings teilweise noch aussteht. Im "Hector"-Verbund wurden daher zunächst die TCP/IP-Protokolle verwendet, weil dafür Produkte verfügbar waren, die relativ

schnell an die Projektumgebung angepaßt werden konnten. Die Ersetzung der TCP/IP-Protokolle durch ISO/OSI-Protokolle ist in Bearbeitung. Technisch sind die IBM-Anlagen untereinander über einen Token-Ring verbunden, wobei größere Entfernungen mit einer Glasfaserstrecke überwunden wurden. Die Vernetzung der DEC-Rechner erfolgte mit Hilfe des Produktes DECnet auf Ethernet-Basis. Die beiden Teilnetze sind über ein Verbindungsstück (Gateway) gekoppelt.

Eine wichtige neue Aufgabe eines Kommunikationsdienstes in einer heterogenen Umgebung ist die Umwandlung von Datenformaten und Datenanordnungen. Für diese sogenannte Präsentationsaufgabe mußten zahlreiche Bausteine zur Definition und zur Konvertierung entwickelt werden. Um aber im Betrieb keine unnötigen Wandlungen durchzuführen, wurde ein Verfahren realisiert, bei dem sich zwei Kommunikationspartner zunächst über ihre Formate abstimmen, um dann tatsächlich nur den Aufwand für die im Einzelfall notwendigen Umwandlungen erbringen zu müssen. Die Konvertierungsvorgänge sind in einen komfortablen, netzweit verfügbaren Mechanismus zum Aufruf entfernter Dienstgeber (Remote Procedure Call) eingebettet.

Katalog

Objekte, die der Benutzergemeinschaft zur Verfügung stehen sollen, müssen als solche natürlich bekannt gemacht werden. Deshalb existiert im Netz ein Katalog von Beschreibungen allgemein benutzbarer Objekte. Er kann beispielsweise Beschreibungen von Betriebssystemen ebenso enthalten wie die von Prozessoren, Plattenspeichern, Druckern, Dateien oder auch von den Benutzern selbst. Jedes Objekt ist durch seine Art, einen netzweit eindeutigen Namen sowie durch eine Reihe charakterisierender Attribute beschrieben, ein Prozessor etwa durch seine Geschwindigkeit, seinen Befehlssatz und seinen Adressierungsraum, ein Drucker dagegen durch die Druckart, die Papierbreite und die Schriftsätze. Zur Beschreibung eines Objekts gehören im allgemeinen Falle auch differenzierte Benutzungsrechte. Zur Unterstützung der Beschreibung existieren Hilfsdienste wie etwa ein Namensdienst oder ein Deskriptordienst zur Überwachung der richtigen Attributierung von Objekten. Jedes Objekt kann explizit von seinem Eigentümer in den Katalog eingetragen und auch wieder entfernt werden. Damit behält der Eigentümer die Kontrolle über die Verwendung seiner Objekte.

Der Katalogdienst stellt für sich genommen eine im Netz verteilte Funktion dar. An einzelnen ausgewählten Orten werden regionale Segmente des Kataloges gehalten. Sie umfassen etwa jene Objekte, die ein Institut oder eine Arbeitsgruppe anbietet. Sie haben einen permanenten Charakter, weil dort die Objektbeschreibungen als Originale existieren. Daneben können sich aber aufgrund von Benutzungsprofilen an den einzelnen Orten auch temporäre Kataloge ausbilden. Sie erfüllen den alleinigen Zweck, eine Zeitlang Beschreibungen jener Objekte aufzubewahren, die in der unmittelbaren Vergangenheit an diesem Ort nachgefragt wurden. Sie enthalten somit einen aktuellen Ausschnitt aus dem Gesamtkatalog. Nachfolgende Wiederbenutzungen können damit schneller befriedigt werden. Suchvorgänge im Netz werden seltener.

Orientierung

Wenn ein Benutzer eine bestimmte Objektart benötigt, dann kann er diese durch Angabe einiger gewünschter Eigenschaften näher spezifizieren; zum Beispiel kann er einen Drucker mit der Eigenschaft "Laser" wünschen. Wenn ein solches Gerät am Ort der Nachfrage nicht vorhanden ist, dann kann mit Hilfe des Orientierungsdienstes im Netz eine Nachforschung veranlaßt werden. Diese Nachforschung läuft als Welle von Erkundungsnachrichten durch das Netz. In der Regel wird es dann mehrere konkrete Objekte mit der gewünschten Eigenschaft geben von denen eines als das gesuchte verwendet wird.

Um auch dabei etwa ein größeres Netz nicht mit Nachfichten zu überschwemmen, lassen sich um die einzelnen Orte sogenannte Suchhorizonte einrichten. Man kann sie an der Organisationsstruktur einer Institution ausrichten oder aber frei definieren. Damit werden Objekte zunächst nur innerhalb eines eingestellten Horizontes gesucht. In den meisten Fällen wird dies erfolgreich sein, zum Beispiel wenn ein Laserdrucker in einem nächsten Raum aufgespürt ist. Erst bei spezielleren Objekten, die dann aber auch seltener nachgefragt werden wird es

sinnvoll sein, den Suchhorizont zu erweitern.

Der Orientierungsdienst stellt ebenfalls eine verteilte Funktion dar. Er stützt sich in seiner Tätigkeit unter anderem stark auf den Katalog und den Kommunikationsdienst. Er hat letztlich die Aufgabe, einer teilweisen Beschreibung eines Objektes einem Ort zuzuordnen, an dem ein entsprechendes Objekt vorhanden ist. Das Ergebnis einer Recherche kann am Ort der Nachfrage in den dortigen temporären Katalog eingetragen werden und steht so für weitere Nachfragen unmittelbar zur Verfügung.

Fernzugriff

In einer lokalen Umgebung kann eine Instanz eine andere durch einen einfachen Aufruf (Prozeduraufruf oder Prozeßaktivierung) benutzen. Wenn aber anstelle der aufgerufenen lokalen Instanz ein entfernter Dienstgeber angesprochen werden soll, dann muß der Aufruf abgefangen und auf eine substituierte Geberersatzinstanz umgelenkt werden. Dort können dann beispielsweise Parameter in Nachrichten verpackt und über den Kommunikationsdienst an den Ort des eigentlichen Dienstgebers verschickt werden. Am Zielort muß ebenfalls eine Nehmerersatzinstanz bereitstehen, um aus der angekommenen Nachricht die Parameter wieder auszupacken und schließlich den dann lokalen Aufruf des Dienstgebers zu veranlassen. Die Ergebnisse der Dienstleistung gehen einen ähnlichen Weg in umgekehrter Richtung. Beispiele sind etwa der Zugriff auf eine entfernte Datei (Remote File Access) oder der Zugriff auf eine entfernte Ablaufbetreuung (Remote Execution). Abbildung 4 zeigt die Architektur eines solchen Fernzugriffs.

Dateitransfer

Ortsgebundene Betriebsmittel lassen sich von anderen Orten nur über den oben geschilderten Fernzugriff benutzen. Dateien dagegen lassen sich sowohl über Fernzugriff ansprechen als auch von einem Ort zu einem anderen kopieren, zum Beispiel an den Ort des Programmes, das die Datei zu bearbeiten hat. Dies kann für die Bearbeitung nützlich sein, weil Einzelzugriffe auf lokale Dateien doch schneller erfolgen können. Der Dateitransferdienst soll solche Kopiervorgänge zwischen ihm vorgegebenen Orten vornehmen. Er muß dazu an den beiden beteiligten Orten die dort vorhandenen lokalen Dateizugriffsinstanzen verwenden. Beim Transport können die Daten gemäß der oben geschilderten Heterogenitätsproblematik umgesetzt werden .

Ablaufkontrolle

Eine einer Rechenanlage übergegebene Aufgabe besteht in der Regel aus der Ausführung eines Programmes, wobei als Parameter in die Ausführung eine Reihe von Betriebsmitteln eingehen. In einem Verarbeitungsverbund können Programme und ihre Betriebsmittel an unterschiedlichen Orten existieren, insbesondere an Orten, die vom Ort der Auslösung einer Aktivität verschieden sind. Programme und Dateien können dabei vor, während oder nach einer Ausführung ihren Ort wechseln. Die jeweilige Zuordnung zu einem bestimmten Ort wird aufgrund von Auslastungs-, Kompatibilitäts- oder Autorisierungskriterien entschieden. Für andere, ortsfeste Betriebsmittel müssen im Zuge einer Ausführungsvorbereitung eventuell Fernzugriffe eingerichtet und später wieder abgebaut werden. Diese Arbeiten, zusammenfassend als Ablaufkontrolle bezeichnet, können im Einzelfall so vielfältig werden, daß auch dafür die Einrichtung eines Netzdienstes zweckmäßig ist. Er nimmt, allgemein gesprochen, etwa die Rolle ein, die im lokalen Fall ein Auftragsabwickler innehat. Im Fall eines Verbundes besteht die Aufgabe darin, die in der Aufgabenstellung angeforderten Objekte mittels der Orientierung zu lokalisieren, über den Dateitransfer zu plazieren, gegebenenfalls Fernzugriffe einzurichten, eine entfernte Ausführung anzustoßen, Verbindung mit dem lokalen Benutzer zu halten und nach Beendigung der Ausführung alle aufgebauten Beziehungen wieder rückgängig zu machen.

Anpassungen

Die oben beschriebenen Netzdienste müssen im wesentlichen in allen Netzknoten vorhanden sein. Sie stützen sich dort auf die jeweils lokal vorhandenen Betriebssystemfunktionen. Da diese sehr unterschiedlich sein können, entsteht an dieser Stelle ein massives Anpassungsproblem. Im "Hector"-Verbund wurde dieses durch Unterfütterung der Netzdienste mit einer Schicht zumindest entschärft, die eine systemweit einheitliche Infrastruktur für die Existenz und die Interaktion von Prozessen anbietet beziehungsweise die Sicht der portierbaren Instanzen auf die jeweilige lokale Sicht abbildet. Deshalb muß diese Schicht bei Einbringung weiterer Betriebssysteme in den Verbund individuell angepaßt werden.

Stand

Die geschilderten Netzdienste beziehungsweise Einzelfunktionen befinden sich einzeln oder bereits integriert seit Anfang des Jahres in der Erprobungsphase. Anfang April wird das Projekt auf einem Kongreß der Öffentlichkeit vorgestellt.