Die durch die Netzwerkeuphorie ausgelöste Begeisterung wird immer dann gedämpft, wenn eine Realisierung von Verbindungen dezentral eingesetzter DV-Komponenten ansteht. Trotz der auf den ersten Blick vielversprechenden Aussagen in den Hochglanzprospekten der Hersteller sind noch nicht alle Probleme gelöst. In Abhängigkeit von den Aufgabenstellungen bei verteilter Datenverarbeitung lassen sich unterschiedliche Bereiche und Ebenen nennen, in denen sich erhebliche Schwierigkeiten ergeben können. Hierbei wird ein Verständnis von verteilter Datenverarbeitung zugrunde gelegt, das von der Dislokation auf der Ebene peripherer Geräte bis hin zu verteilter Rechnerleistung geht.
Beim Datentransport geht es um das Herstellen physischer Verbindungen zwischen zwei DV-Komponenten an verschiedenen Standorten. Ziel dabei ist nicht mehr als eine Bit- oder Byte-weise Übertragung bestimmter Informationen mit Hilfe elektrischer Signale. Bereits dieses reine "Aneinanderstöpseln" ist nicht trivial. So entstehen beispielsweise Probleme, wenn eine Verbindung zwischen der Koaxkabel-Welt und der V.24-(2/4-Draht-)Telefonkabel-Welt geschaffen werden muß. Dies ist zwar im Prinzip technisch lösbar, führt aber zum Einsatz von Interfaces und Modems, was nicht nur aufwendig ist, sondern auch zu Verzögerungen bei der Übertragung führen kann.
Pinbelegung läßt Herstellerindividualität erkennen
Aber schon die V.24-Schnittstelle ist nicht einheitlich. Dies beginnt bei der Pinbelegung der Steckanschlüsse, die oft die Individualität der Hersteller erkennen läßt. Auch die Informationen, die an den einzelnen Pins bereitgestellt oder abgefragt werden, müssen nicht deckungsgleich sein. Nur als Stichworte seien hier Übertragungsprozeduren wie X-ON/X-OFF oder der Unterschied zwischen synchroner und asynchroner Übertragung genannt. Weiterhin muß eine Festlegung bezüglich der Übertragungsgeschwindigkeit erfolgen, die einerseits erhebliche Auswirkungen auf die zu verwendenden Übertragungsleitungen und andererseits auf das übertragbare Datenvolumen hat.
Hierbei spielt insbesondere eine Rolle, ob es sich beispielsweise um einen
DFÜ- Anschluß, einen Kanalanschluß oder einen Bus-Anschluß handelt. Von Bedeutung ist auch, ob man Halb- oder Voll-Duplex fahren kann oder möchte.
Konventionen müssen bekannt sein
Dennoch können, wenn physische Verbindungen vorhanden sind, per Software die entsprechenden Datenströme mit den notwendigen Konventionen umgesetzt werden. Dazu müssen jedoch die Konventionen bekannt sein, denen der Datenstrom unterliegt. Im Prinzip wird dabei ein eigenes selbstgestricktes Protokoll mit einem Konvertierungsteil definiert und realisiert.
Dies gilt insbesondere, wenn es sich bei der zugrunde liegenden Übertragungsart um eine TTY-artige Ansteuerung von Geräten handelt. Gerade bei der Verbindung physischer Art steckt der Teufel im Detail. Ein Versprechen, daß ein Gerät eine bestimmte
(Hardware-)Schnittstelle hat, gewährleistet keinesfalls, daß es nach dem Einstecken des Steckers Daten richtig empfangen oder senden kann.
Ansteuerung bleibt problematisch
Bei der Ansteuerung von Geräten werden über den Datenstrom hinaus der "reine"
Informationen enthält, gerätespezifische Steuerzeichen benötigt. Diese sind herstellerabhängig und bauen lediglich auf einigen gemeinsamen, elementaren Code-Zeichen auf.
Doch schon auf der Ebene der Code-Tabellen gibt es Unterschiede.
So haben zum Beispiel die Funktionen LF, ESC und BEL in EBCDIC und ASCII unterschiedliche Werte, die eine Umsetzung erforderlich machen können. Auch innerhalb eines Codes verwenden die Hersteller unterschiedliche Darstellungen für die gleiche Aufgabe.
Außerdem werden die Funktionszeichen selbst bei unterschiedlichen Geräten des gleichen Herstellers oft unterschiedlich interpretiert. Zwar wird seit langem über virtuelle Terminalprotokolle geredet und auch geschrieben, es existieren jedoch immer noch Hersteller, bei denen die Spezifikation des Terminals nicht nur im Rechner, sondern auch im Anwendungsprogramm verankert sein muß.
Beim Anschluß neuer Geräte an einen bestehenden Rechner kann es daher durchaus erforderlich sein, die Code-Tabellen beider Partner genauestens zu studieren. Ein Steuerzeichen, das an einem Drucker eine bestimmte Funktion auslöst, beispielsweise das Ansteuern der Einzelblattzufuhr, kann bei einem Terminal, einem Plotter oder einer RJE-Station zu nicht vorhersehbaren Ergebnissen führen.
Homogene Rechnernetze in zwei Arten
Hier fehlt es an funktionsbezogenen Protokolldefinitionen, zu denen auch der DV-Anwender Zugang finden kann.
Unter homogenen Rechnernetzen können zwei unterschiedliche Konzeptionen verstanden werden. Homogene Rechnernetze sind zum einen Rechnernetze im Rahmen des gleichen Herstellers. Zum anderen können es auch Rechnernetze sein, die sich gleichartiger Datenübertragungsmethoden bedienen. Ein homogenes Rechnernetz der ersten Art kann bereits vorliegen, ohne daß Funktionen der Datenfernübertragung einbezogen sind. Liegt eine Kompatibilität oder Portabilität bezüglich externer Speichermedien wie Disketten und Bändern vor, die zu einem entsprechenden Datenaustausch führt, so kann man auch von einem "manuell gehandhabten" Netz sprechen.
Dies bedeutet jedoch, daß die gesamte Netzabwicklung in den Bereich der organisatorischen Regelung verschoben wird. Dabei müssen außerdem Zugeständnisse an die Aktualität der übertragenen Daten gemacht werden.
Ein Netz entsteht auch bereits, wenn eine Kopplung von Rechnern über gemeinsame Arbeitsspeicher, Kanäle oder den gemeinsamen Anschluß von externen Speichern (häufig Plattenspeicher) vorhanden ist. Daß solche Kopplungen zu entsprechend umfangreichen Betriebssystemen oder umfangreichen Verwaltungsproblemen führen, ist bekannt.
DFÜ bedeutet technische Ausweitung
Der klassische Fall von Netzen nämlich Netze unter Einbeziehung von Datenfernübertragungsfunktionen, bedeutet, daß nunmehr eine Menge weiterer technischer Komponenten in die Abwicklung einbezogen sind. Hierbei handelt es sich im wesentlichen um Modems, Vorrechner und Leitungen, aber auch um die Benutzung öffentlicher Übertragungsdienste.
Neben den grundsätzlichen Unterschieden bezüglich der Datenvermittlung sind bei der Einbeziehung dieser Dienste (HfD, Datex-L, Datex-P) verstärkt die entstehenden Kosten bei der Netzgestaltung zu berücksichtigen.
Im Rahmen solcher homogenen Netze kann zunächst eine Anwendungsverteilung angestrebt werden. Im Falle des Funktionenverbundes im Netz können dazu dedizierte Rechner verwendet werden.
Dedizierte Rechner übernehmen ganz bestimmte Aufgaben, für die sie besonders geeignet sind. Bei der Realisierung eines Funktionenverbundes ist jedoch kein Lastverbund möglich, da dieser voraussetzt, daß alle beteiligten Rechner alle Aufgaben übernehmen können.
Kommunikation auf Transaktionsebene
Neben dieser Anwendungsverteilung steht die Aufgabe der Anwendungsverbindung.
Anwendungsverbindungen sind erforderlich, wenn Anwendungen synchron oder asynchron mit Anwendungen, die auf anderen Rechnern laufen, kommunizieren sollen. Die Kommunikation muß dabei sinnvollerweise auf Transaktionsebene erfolgen.
Eine solche Art von Kommunikation wird selbst bei den hier betrachteten homogenen Netzen im Normalfall nicht unterstützt. Dies bedeutet, daß eine Transaktion standardmäßig nicht in der Lage ist, einen synchronen Transaktionsaufruf an einen anderen Rechner abzusetzen.
Bei Rechnernetzen, die sich gleichartiger Datenübertragungsmethoden bedienen, können auch Hardwarekomponenten unterschiedlicher Hersteller eingebunden werden.
Innerhalb eines solchen Rechnernetzes wird aber nur eine Datenübertragungsmethode benutzt, das heißt, auch die unterschiedlichen Hardwarekomponenten arbeiten unter einem Netzkonzept. Man sollte jedoch nur dann von einem homogenen Rechnernetz sprechen, wenn innerhalb des Netzes keine Protokollumsetzungen stattfinden.
Homogenität nicht automatisch
Arbeiten Hardwarekomponenten unterschiedlicher Hersteller unter einem Netzkonzept zusammen, so bedeutet dies noch nicht, daß ein homogenes Netz vorliegt. In der Regel wird die Hardwarekomponente zunächst ihr "eigenes" Protokoll fahren und dies in einer separaten Software- oder Hardwarekomponente in das Netzprotokoll, dem sie sich unterordnet, umsetzen.
Unter den genannten Gesichtspunkten können öffentliche Netze wie Datex-P, Transpac und ähnliche auch als homogene Netze bezeichnet werden, da sie den Teilnehmern einheitliche Schnittstellen nach außen zur Verfügung stellen. Dabei ist es dann tatsächlich unerheblich, auf welcher Hardware dieses Netz realisiert wurde.
Eine weitere entscheidende Anforderung an homogene Netze ist die Transparenz bezüglich der im zweiten Abschnitt genannten Steuerzeichen.
Inhomogene Rechnernetze können auch als offene Netze bezeichnet werden. Es sind Netze mit beliebigen Rechnern oder Hardwarekomponenten unterschiedlicher Hersteller und unterschiedlichen Datenübertragungsmethoden. Es handelt sich meist um Verbunde homogener Netze, wobei der Verbund über sogenannte Gateways durchgeführt wird.
Das Einschalten von Gateways bedeutet einen zusätzlichen Aufwand für die Erstellung des Netzes und zusätzliche Kosten während des Betriebes. In aller Regel treten außerdem Performance-Probleme und weitere Einschränkungen auf. So sind beispielsweise bezüglich der Anzahl möglicher Transaktionen, der Anzahl möglicher Verbindungen zwischen Netzknoten und bei der Länge der Nachrichten Begrenzungen möglich.
Die Standardisierungsbemühungen der ISO haben zwar zu einem allseits zitierten Standardisierungsvorschlag (7-Schichten-Modell) geführt, dies bedeutet jedoch leider nicht, daß dieser Standard auch in den Netzkonzepten implementiert wurde. Jeder Hersteller verweist darauf, daß auch sein Netzkonzept einer Schichtung folgt.
Jedoch sind die Zuordnungen von Funktionen zu Schichten nicht einheitlich, was meist zu einer unterschiedlichen Anzahl nicht vergleichbarer Schichten führt. In vielen Fällen sind zum Beispiel die untersten beiden Schichten des ISO-Referenz-Modells zusammengefaßt. Selbst die Normierungsbemühungen der ECMA und des CCITT (X.-Reihe) haben keine Vereinheitlichung bewirkt.
Bei "Mischehen" Funktionen emulieren
Werden Hardwarekomponenten unterschiedlicher Hersteller zusammengebracht, so handelt es sich oftmals lediglich um die Emulation von Terminalfunktionen. Dies ist erforderlich, da im Gegensatz zum homogenen Netz für die Arbeit an einem Rechner ein Terminal protokollmäßig mit diesem verbunden und an diesen angepaßt werden muß.
Einerseits ist hierbei Rechnerkapazität für die Emulation der Terminalfunktion bereitzustellen, andererseits sind im Rahmen der Arbeit des Benutzers An- und Abmeldevorgänge erforderlich.
Im Fall des Remote Job Entry werden lediglich Umcodierungen der Zeichensätze durchgeführt, und auf dem Quellrechner müssen die Befehlsworte des Zielrechners eingegeben werden.
Bei Dateiübertragungen über unterschiedliche Netze hinweg handelt es sich stets um Sonderlösungen, da die physikalische Speicherung von Dateien herstellerspezifisch ist. Hierbei ist jedoch nur eine satzweise Übertragung von Daten möglich oder sinnvoll. Standardmäßig werden meist nur Lösungen für die Übertragung von Dateiinhalten von oder an Rechner des Marktführers angeboten.
Eine Prozeß-Prozeß-Kommunikation ist im Fall inhomogener Rechnernetze praktisch nicht vorhanden. Sie ist in aller Regel auf einen Message-Transfer für andere Rechner beschränkt.
Organisatorisches Umfeld gewinnt an Bedeutung
Das Betreiben von Netzen erfordert entsprechendes Know-how. Gerade die Beschaffung dieses Know-hows stellt wesentliche Probleme dar. Solches Know-how ist, wenn es an Personen gebunden ist, teuer und schwer zu beschaffen. Darüber hinaus hat es nur eine geringe Halbwertzeit. Derjenige, der aktuelles Wissen über Netzverbindungen benötigt muß sehr viel Zeit und Aufwand in die Fortbildung stecken.
Wichtiges Netz-Know-how für eine bestehende Netzkonzeption muß umfassend sein und für alle Komponenten gelten. Da sich die Vernetzung um die Verbindung dezentraler Stellen kümmert, muß darüber hinaus für den Wartungsfall das Netz-Know-how dezentral verfügbar sein. In diesem Zusammenhang kann es sich daher empfehlen, bei Aufbau eigener firmeninterner Netze entsprechende Beratungsinstitutionen einzuschalten, um die möglichen Anfangsfehler zu vermeiden und um von vornherein relativ gute Netzkonzeptionen zu entwickeln.
Auch muß darauf hingewiesen werden, daß die Netzgestaltung nicht ohne Einfluß auf die Möglichkeiten der organisatorischen Gestaltung von Abläufen ist. So sind beispielsweise zentrale Systeme erforderlich, wenn von mehreren dezentralen Stellen aus auf aktuelle Lagerbestände unterschiedlicher Standorte zugegriffen werden soll und keine Prozeß-Prozeß-Kommunikation zwischen verschiedenen Rechnern möglich ist.
Als Alternative verbleibt lediglich der Einsatz mehrerer dezentraler Systeme, die durch einen ständigen Informationsaustausch miteinander verbunden sind und trotzdem Probleme bezüglich der Aktualität aufweisen. Der Einsatz verteilter Datenbanken, der sich hier prinzipiell anbieten würde, ist derzeit noch nicht möglich.
Vereinheitlichung noch nicht realisiert
Es bleibt festzuhalten, daß sowohl Standardisierungsorganisationen als auch Hersteller sich einig sind in der Erkenntnis, eine Vereinheitlichung von Protokollen und Schnittstellenvorschriften erreichen zu müssen. Gerade am Schicksal des ISO-Referenzmodells läßt sich jedoch zeigen, wie weit diese Bemühungen gediehen sind. Das ISO-Modell ist vorhanden, aber es dient lediglich als Referenz beim Beschreiben der unterschiedlichen Netzwerkrealisierungen.
Wer Netze einrichten und betreiben will, muß sich detailliertes Wissen über Netzgestaltung und Netzverbindungen aneignen. Dazu gehören auch die angesprochenen Informationen über Details der technischen Realisierung.
Dabei ist es wesentlich, zu erkennen, daß Netze einen hohen Beitrag zur Integration von Anwendungen und Daten unterschiedlicher Standorte leisten können, sofern die technischen Voraussetzungen dafür geschaffen sind.
Die technischen Grunddienste der Vermittlung von Informationen von einem Ort zum anderen Ort können zumindest für die Bundesrepublik als gegeben angesehen werden. Hat man jedoch große Ansprüche an Datensicherheit oder Datengeschwindigkeit oder umfangreiche Ansprüche an die Verbundenheit unterschiedlichster Orte, so stößt man auch hier schnell an die Grenzen der bisher gelösten Netzprobleme.
Dipl.-Inform. Erich Brück, Dr. Helmut Kromar und Dipl.-Wirtsch.-lng. Norbert Wittemann sind wissenschaftliche Mitarbeiter am Institut für Wirtschaftsinformatik an der Universität des Saarlandes.