In den letzten Jahren ist es immer einfacher, immer unkomplizierter geworden, Rechner verschiedener Hersteller und unterschiedlicher Leistungsklassen zu Netzen zusammenzuschließen. Die Netzwerksoftware der Hersteller ist komfortabler geworden, genormte Schnittstellen und Protokoll-Emulationen ermöglichen einen einfachen Datenaustausch. Und wo beides nicht verfügbar ist, sorgen Protokollkonverter für eine technisch einwandfreie Datenübertragung.

Trotzdem gewinnen verteilte Anwendungen in der Praxis nur langsam an Boden, gelten nach wie vor als schwer zu entwickeln, fehleranfällig und schwer zu warten. An den technischen Voraussetzungen zur Datenübertragung kann das in den meisten Fällen nicht mehr liegen; zudem sind die betriebswirtschaftlichen Aufgabenstellungen in verteilten Anwendungen in aller Regel nicht komplexer als in reinen Host-Anwendungen. Die Ursache für die Schwierigkeiten muß auf einer anderen Ebene liegen, auf einer Ebene, die in vielen Entwürfen verteilter Anwendungen schlicht übersehen und deshalb erst spät - nämlich bei Inbetriebnahme der Anwendungen - durch Job-Control-Einsatz und Adhoc-Programmierung bearbeitet wird; mit Inflexibilität und Fehleranfälligkeit als Folge.

Nehmen wir ein Beispiel: Ein Unternehmen betreibt ein Hochregallager. Die direkten Warenbewegungen in den einzelnen Lagerbereichen werden durch Prozeßrechner gesteuert. Die Verwaltung der Materialbestände und der Lagerplätze werden auf dem Host-Rechner durchgeführt. Host und Prozeßrechner sind jeweils über eine Asynchronleitung miteinander verbunden.

Die betriebswirtschaftliche Aufgabenstellung zum Beispiel für eine Auslagerung ist klar: Das Programmsystem auf dem Host hat nach einem gegebenen Satz von Regeln zu ermitteln, von welchem Platz eine Palette geholt und zu welcher Abgabestation sie transportiert werden soll. Diese Information muß das Programm an den Prozeßrechner übermitteln. Meldet der Prozeßrechner irgendwann später die erfolgreiche Ausführung des Befehls, so ist im Host eine entsprechende Buchung vorzunehmen.

Und handelte es sich hier nicht um ein automatisches, sondern um ein manuell betriebenes Hochregallager, wäre der Entwickler in der Tat schnell fertig: Er würde den Steuerungsbefehl auf einem Drucker ausgeben und eine Transaktion schreiben, über die das Lagerpersonal die Ausführung des Befehls zurückmelden kann. Weil aber bei der automatischen Abwicklung der Kommunikationspartner des Hosts ein Computer ist, tritt eine Reihe zusätzlicher Probleme auf:

- Steuerungsbefehle müssen gepuffert werden, da der Host sie schneller erzeugt, als der an die Geschwindigkeit der Regalförderzeuge gebundene Prozeßrechner sie abarbeiten kann;

- je Regalförderung darf nur ein Befehl übermittelt werden, dann ist die Ausführungsbestätigung abzuwarten und dann kann eine neue (Übertragung eingeleitet werden;

- Pufferung der laufenden Aktion, wenn einer der Rechner ausfällt;

- Wiederanlauf der Übertragung nach Ausfall eines der beiden Rechner oder bei Arbeitsbeginn;

- Beendigung des Betriebes, auch wenn noch nicht alle Steuerungsbefehle abgearbeitet sind;

- bedienergesteuerte Wiederholung der Übertragung von einzelnen Steuerungsbefehlen bei technischen Problemen.

Zur Analyse des Zustandes bei technischen Störungen sind darüber hinaus wünschenswert, wenn nicht dringend erforderlich:

- Anzeige der Warteschlangen vor der Übertragung zum Prozeßrechner,

- Anzeige des Übertragungsstatus und der im Moment in Bearbeitung befindlichen Steuerbefehle,

- wahlweise Protokollierung des Leitungsverkehrs.

Probleme liegen beim Nachrichtentransport

Wohlgemerkt, all diese Anforderungen haben nichts mit der betriebswirtschaftlichen Aufgabenstellung "Auslagerung einer Palette einer bestimmten Ware" zu tun. Sie haben auch nichts damit zu tun, nach welchem Übertragungsverfahren (BSC, SDLC, Start/Stop) und welcher Geräte-Emulation (3270, 3770, 3780 etc.) die beiden Rechner gekoppelt sind. Vielmehr handelt es sich hier um Probleme einer "Zwischenebene", der Ebene des logischen Nachrichtentransports. Sie ist nicht nur in dem ausgeführten Beispiel vorhanden, sondern Bestandteil jeder verteilten Anwendung.

Allgemein formuliert: In einem System von durch Übertragungskanäle verbundenen Prozessoren tauschen asynchrone Prozesse Nachrichten aus. Um diesen Austausch zu organisieren, bei Ausfall von Teilen des Systems dessen Konsistenz und den Wiederanlauf der Übertragung sicherzustellen und über den jeweiligen Zustand des Systems auskunftsfähig zu sein, sind eine Reihe von Stammdaten/Tabellen, Übertragungsprozessen, Datenpuffern und Servicefunktionen erforderlich.

Ein anwendungsneutrales Standardsystem könnte beispielsweise wie folgt arbeiten (siehe dazu auch Kasten mit relevanten Begriffen):

Zunächst ist ein Schnittstellenprogramm erforderlich, dem jedes beliebige Anwendungsprogramm zu einem ihm genehmen Zeitpunkt Nachrichten übergeben kann (CALL-Modul). Neben dem Inhalt der Nachrichten hat das Anwendungsprogramm auch noch mitzuteilen, für welchen Empfänger die Nachricht bestimmt ist, zu welcher Nachrichtenart und -gruppe die Nachricht gehört und ob die Nachrichtengruppe mit dieser Nachricht abgeschlossen wird. Mehr braucht die Anwendung in puncto "Verteilte Verarbeitung" nicht zu wissen.

Die Schnittstelle ermittelt nun aufgrund von Tabelleneinträgen, zu welchem Netzknoten der Empfänger gehört, auf welchem Verbindungsweg dieser Netzknoten zu erreichen ist und ob das für diesen Verbindungsweg zuständige Übertragungsprogramm sofort oder später zu starten ist. Dann schreibt sie die Nachricht, vervollständigt um einige Parameter, in einen Nachrichtenspeicher - eine Art Spooler-Queue - und startet entsprechend der gegebenen Start-Option das zuständige Übertragungsprogramm.

Natürlich ist auch erforderlich, daß ein Anwendungsprogramm über eine Schnittstelle Nachrichten aus dem Nachrichtenspeicher auslesen kann: Dabei gibt es Empfänger und Nachrichtenart bekannt, die erste zu diesen Begriffen vorhandene Nachricht wird zurückgegeben und in Folgeaufträgen werden die weiteren übergeben.

Neben diesen Kernfunktionen ist eine Reihe von Servicefunktionen denkbar und in der Praxis auch überaus nützlich:

- Verschiedene Übersichts- und Detailanzeigen, um den Inhalt des Nachrichtenspeichers mit Anzahl Nachrichten je Empfänger, Nachrichtenstatus-Information und Nachrichteninhalt anzuzeigen;

- Möglichkeiten, die Start-Option einer Nachrichtengruppe zu ändern (zum Beispiel von "Start sofort" auf "Start durch Operator-Eingriff");

- Möglichkeiten, das Schicksal der Nachricht nach Abgabe zur Übertragung zu regeln ("Sofort löschen" und "n Tage aufheben"); - Möglichkeiten, eine Übertragung abzubrechen, wiederauflegen zu lassen, bestimmte Nachrichten noch einmal zu übertragen oder zu löschen;

- Möglichkeiten, bestimmte Übertragungen zu protokollieren.

Zurück zu unserem Beispiel: Wie würde die auf Host und Prozeßrechner verteilte Anwendung bei Verwendung dieser Bausteine aussehen?

Der erste Teil der Anwendung gestaltet sich folgendermaßen. Das Anwendungsprogramm "Auslagerung" ermittelt, welche Palette wohin ausgelagert werden soll. Es stellt eine entsprechende Nachricht zusammen und übergibt sie, versehen mit Nachrichtenart und dem Namen des zuständigen Regalförderzeugs als Empfänger an die Schnittstelle.

Das Interface stellt die Nachricht in den Nachrichtenspeicher, ermittelt aufgrund des Empfängers, daß die Nachricht an den für das Hochregallager zuständigen Prozeßrechner zu übertragen ist, ermittelt aus eigener Knotenadresse und Prozeßrechneradresse den Verbindungsweg, den Namen des Übertragungsprogramms und stellt an der Startoption fest, daß es die Übertragung sofort starten soll. Mit diesen Informationen stößt sie die Übertragung an. Irgendwann kommt die Ausführungsbestätigung vom Prozeßrechner. Sie wird von einem allgemeinen Rückmeldeprogramm entgegengenommen und über das Schnittstellenprogramm in den Nachrichtenspeicher geschrieben. Dabei prüft die Schnittstelle, für wen die Nachricht bestimmt ist, und findet unter diesem neuen Empfänger über - analog den oben beschriebenen verlaufende - Zwischenschritte heraus, daß sie ein bestimmtes Programm sofort zu starten hat.

Beim zweiten Teil der Anwendung liest das aktivierte Anwendungsprogramm über die Schnittstelle die Ausführungsbestätigung ein und vollzieht die eben physisch durchgeführte Palettenbewegung buchmäßig nach.

Nun ist ein solches Standardsystem zum Nachrichtentransport, kurz NTS, nicht nur hilfreich, wenn es um Kopplung eines kommerziellen Hosts mit einem Prozeßrechner geht: Das System ist vielmehr auf vielfältige Anwendungsprobleme anwendbar; hier einige Beispiele:

1. In einem Einzelhandelskonzern werden Daten nach einem festliegenden Zeitplan von allen Filialrechnern abgerufen und auf dem Zentralrechner so verteilt, daß sie den folgenden Verarbeitungsprogrammen als sequentielle Eingaben zur Verfügung stehen. Die im Zentralrechner erzeugten Auswertungen werden je Empfänger als Nachrichtengruppen bereitgestellt und an die Filialrechner/Lagerrechner übertragen.

2. In einer internationalen Spedition sollen die Niederlassungen über Sendungen, die sie übernehmen und dem Empfänger zustellen sollen, möglichst frühzeitig von der abgebenden Niederlassung informiert werden. Außerdem sollen auch sendungsunabhängige Nachrichten für wohldefinierte Empfänger in der Zentrale und den Niederlassungen übermittelt werden.

3. Ein Konsumgüterhersteller setzt zur Betreuung seiner Einzelhandelskunden zirka 30 Vertreter, die mit mobilen Datenerfassungsgeräten (MDE-Geräten) ausgestattet sind, ein. Während ihrer Kundengespräche tasten die Vertreter die jeweilige Bestellung sofort in das MDE-Gerät ein. Nach Abschluß des Auftrages rufen sie vom Kunden aus den Rechner der Firmenzentrale an und übertragen mittels Akustikkoppler die eben aufgenommenen Bestellungen an den Rechner. Der Rechner prüft je nach der gewünschten Position sofort die Verfügbarkeit und sendet für jede nicht lieferbare Position die Artikelnummer und den voraussichtlichen Liefertermin zurück an das MDE-Gerät. Danach wird die Verbindung beendet. Der Vertreter hat nun die Möglichkeit, den Kunden sofort über Lieferengpässe zu informieren und ihm die Bestellung von Ersatzartikeln vorzuschlagen.

Der wichtigste Vorteil der Definition und Anwendung einer solchen "Zwischenebene" des logischen Nachrichtentransports liegt zweifellos in der klaren, auf genau definierten Begriffen und Funktionen beruhenden Trennung zwischen Anwendungs- und Netzwerkebene: Die Anwendungsdesigner legen logische Empfänger, Nachrichtenarten und -gruppen fest, diskutieren Startoptionen und Rückmelderegeln, brauchen sich aber um Standorte von Rechnern, Wähl- oder Standleitungen, Hardware- und Netzwerksoftware-Auswahl nicht zu kümmern. Das spart Zeit, denn die Anwendungsentwicklung kann so auch vor der Hardware- /Netzwerksoftware-Entscheidung beginnen, und Geld, denn die Funktionen des Nachrichtentransports müssen nicht neu erdacht und erprobt werden - sie sind eben da!

Der andere große Vorteil liegt darin, daß die Anwendung unabhängig gegenüber Veränderungen des Netzwerkes wird: Veränderungen des Mengengerüsts, Verschiebungen im Preis-Leistungs-Verhältnis und Einführung neuer Übertragungsverfahren können innerhalb kurzer Zeit eine Neugestaltung des Netzes, die Zusammenlegung von Knoten oder deren Splittung erforderlich machen. Derartige Änderungen sind in der NTS-Logik durch Änderungen von Tabellen nachzuvollziehen. Die Einführung eines neuen Übertragungsverfahrens kann die Entwicklung eines neuen Übertragungsprogramms erfordern, das dann aber unabhängig von der Anwendung in eine Tabelle eingetragen und vom NTS angestoßen wird.

*Dieter Heyde ist geschäftsführender Gesellschafter der Heyde & Partner GmbH, Bad Nauheim.

Begriffe für anwendungsneutrale Systeme

Nachricht

Datensatz, der von einem Prozeß erzeugt und zur asynchronen Verarbeitung bereitgestellt wird.

Nachrichtenart

Bezeichnung einer Menge strukturgleicher Nachrichten

(= Satzart)

Nachrichtengruppe

Anzahl von Nachrichten einer Nachrichtenart, die nur geschlossen - als Paket - im System transportiert werden darf

Empfänger

Stelle (=Funktionsträger), die Nachrichten konsumiert

Netzknoten

Rechner, auf dem Nachrichten erzeugt, gepuffert und Prozesse zum Nachrichtentransport durchgeführt werden.

Verbindungsweg

Der Verbindungsweg gibt an, welcher direkte Nachbar von Netzknoten A aus angesprochen werden muß, um den Zielknoten B zu erreichen.

Übertragungsprogramm

Name des Programms, das aufzurufen ist, um einen Übertragungsprozeß auf einem bestimmten Verbindungsweg einzuleiten. Über das Übertragungsprogramm werden gleichzeitig die verschiedenen Verbindungsarten (Standleitung/Wählleitung, BSC/SDLC, Start/Stop/Datex-P) wie auch die Varianten des Rückmelde-Verfahrens entschieden.

Startoption

Über die Startoption wird festgelegt, durch welches Ereignis eine Übertragung einzuleiten ist. Zur Auswahl stehen:

- sofort einleiten, wenn die Nachrichtengruppe vollständig ist,

- einleiten bei Erreichung eines bestimmten Termins, Start durch Operator-Eingriff,

- Abruf (die Verbindung wird von einem entfernten Netzkonten aus aufgebaut und die Datenübertragung eingeleitet).