*Thomas G. Shirk leitet eine Projekt-gruppe zum Thema Netzwerk-Management bei der SAP AG Walldorf.
Leistungsfähige Personal Computer oder aktueller ausgedrückt Workstations gewinnen weiter an Bedeutung. Noch scheint es zu früh, das baldige Aussterben der Mainframes zu erwarten. Man kann aber davon ausgehen, daß es zu einer Koexistenz von Workstations und Mainframes kommen wird.
Die Frage, welcher Art die Verbindung zwischen den beiden Systemen in der Zukunft sein wird, läßt aber noch viele Details offen. Für uns als Hersteller von Standard-Anwendungssoftware ist es allerdings lebenswichtig, hier die richtige Prognose zu treffen. Die Architekturprinzipien und Standards, die sich in diesem Bereich zukünftig durchsetzen werden, müssen schon heute Grundlage bei der Gestaltung künftiger Produkte sein. Welche Erwartungen uns dabei leiten, beschreibt dieser Artikel.
Noch dominiert Architektur von gestern
Gehen wir von der Situation aus, wie sie heute noch in der Mehrzahl der Unternehmen vorzufinden ist: Alphanumerische Terminals werden von einem Mainframe bedient. Die Verbindung übernimmt eine Netzsoftware, wie zum Beispiel VTAM und NCP. Diese läuft auf dem Host und eventuell einem vorgelagerten Spezialrechner. Wenn zusätzlich Workstations im Unternehmen existieren, so stehen sie entweder gar nicht in Verbindung mit dem Host, oder es bestehen im Einzelfall spezielle Insellösungen für einen begrenzten Datenaustausch.
Daß dieses Szenario unter der Überschrift "gestern" erscheint, soll allerdings nicht heißen, die Unternehmen mit dieser Ausstattung seien, was den DV-Bereich angeht, nicht auf dem laufenden: Eine solche Architektur ist wie gesagt heutzutage die Regel. Gemeint ist lediglich, daß Neuplanungen in Sachen Rechnerausstattung heute die Workstation einbeziehen müssen. Dabei gelangt man fast immer zu der Erkenntnis, daß deren Möglichkeiten nicht voll ausgeschöpft werden, wenn eine Verbindung zur zentralen Datenverarbeitung fehlt.
Teure Mainframe-Zeit auf PC substituieren
Dies führt dann meist dazu, daß Architekturen aufgebaut werden, in der die Workstations durch ein lokales Netz miteinander verbunden sind, das auch ein Gateway zum zentralen Host-Rechner enthält. Über dieses Gateway kann jede Workstation eine direkte Verbindung zum Mainframe unterhalten. Programme, die einerseits auf Möglichkeiten der Workstation, zum Beispiel grafische Oberflächen, bauen und andererseits auf Datenaustausch mit dem zentralen System angewiesen sind, können nun befriedigend arbeiten.
Außerdem besteht wenigstens prinzipiell die Möglichkeit, teure Rechenzeit auf dem Mainframe durch relativ billiges Arbeiten auf der Workstation zu substituieren. Ein Nachteil dieser Architektur liegt allerdings darin, daß jede Workstation für ihre Kommunikation zum Host selbst zu sorgen hat. Die Programme, die das bewerkstelligen, laufen auf jeder Workstation und nehmen dort Speicherplatz und Rechenzeit in Anspruch. Noch gravierender schlägt dieser Nachteil auf dem Mainframe zu Buche: Für jede angeschlossene Workstation muß eine logische Instanz geschaffen werden, welche die Einhaltung des Kommunikationsprotokolls überwacht und periodisch überprüft, ob die Workstation Kommunikationswünsche äußert. Dies läuft dem Ziel zuwider, durch die Workstation-Einbindung den Mainframe von möglichst vielen Aufgaben zu entlasten. Daher wird eine dritte Architektur notwendig.
Die wahrscheinliche Architektur von morgen
Sie erfordert gegenüber der eben beschriebenen kaum Änderungen an der Hardwarekonstellation. Softwareseitig wird aber nun eine der angeschlossenen Workstations als Kommunikationsserver ausgezeichnet. Die übrigen Workstations wenden sich mit ihren Kommunikationswünschen an diesen Server und erhalten über ihn auch Daten vom zentralen System. Sie brauchen daher immer nur innerhalb des Netzes Daten auszutauschen; der Server übernimmt die aufwendige Prozedur der Host-Kommunikation. Auch der Mainframe wird entlastet, da ihm nur noch ein einziger Kommunikationspartner gegenübersteht. Es ist sehr wahrscheinlich, daß der Trend in Sachen Mainframe-Link sehr stark in Richtung auf solche Serverarchitekturen gehen wird.
Die Einbindung von Workstations hat Auswirkungen auf das Design der Programme, die in diesem Umfeld laufen sollen. Die Verteilung von Host-Funktionen auf die Workstations setzt voraus, daß die Anwendungsprogramme auf eine solche Möglichkeit vorbereitet sind. In vielen Fällen wird eine weitgehende Umstrukturierung bestehender Programmsysteme erforderlich sein, damit gleichzeitig dialogintensive Teile auf die Workstation migrieren, datenbankintensive Teile dagegen auf dem Host verbeiben können.
CPI als Brücke zur Unix-Welt
Abgesehen davon ist aber auch wichtig, daß sich Standards etablieren, was die Konzepte und Protokolle zur Realisierung dieser Architekturen angeht. Dabei muß unterschieden werden zwischen einerseits dem Datenaustausch der Workstations untereinander und der Host-Workstation-Kommunikation andererseits.
Bei der Kommunikation zwischen Host und Workstations scheint das Rennen mittlerweile entschieden zu sein. Hier setzt sich das ursprünglich unter dem Begriff APPC ("Advanced program-to-program-comunication") von der IBM propagierte Protokoll LU6.2 mehr und mehr durch. Vor allem die auf LU6.2 realisierte Kommunikationsschnittstelle CPI C ("Common programming interface for communication") ist inzwischen auf breiter Front akzeptiert, auch als eine gute Möglichkeit, zukünftig die Brücke zur Unix-Welt zu schlagen.
Der Zusammenhang zwischen den beiden genannten Normen stellt sich folgendermaßen dar: Über LU6.2 unterhalten sich während einer sogenannten) Session zwei logische Einheiten (LU: "Logical unit"). In eine Session kann eine sogenannte Konversation gemäß CPI C eingebettet werden, die zwei Prozesse wenden sich mit ihren Kommunikationswünschen jeweils an die LU auf ihrem Rechner Die logischen Einheiten setzen in der Regel mehrere CPI-C-Calls in einen Aufruf gemäß LU6.2 um.
In vielen Anwendungen wird es genügen, sich lediglich auf den sogenannten "Starter set" von CPI C abzustützen. Er enthält nur sechs verschiedene Aufrufe, die aber gemeinsam schon eine vollständige Kommunikationsbasis bieten. Auf ihr können bei Bedarf weitere Funktionen aufgesetzt werden.
In Vorbereitung sind Hilfsmittel, die gepufferte Kommunikation zwischen Partnern ermöglichen und dabei nur das CPI-C-Starter-Set voraussetzen. Daten, die an einen Empfänger geschickt werden, der zur Zeit nicht im Netz aktiv ist, werden beim Sender oder beim Server in einer Queue zwischengespeichert. Ein spezielles Treiberprogramm versucht dann, sie aus der Queue an den Empfänger zu übermitteln, sobald er seine Arbeit wiederaufnimmt. Das Programm, das die Daten absetzt, braucht sich darum nicht zu kümmern und kann seine Arbeit unmittelbar fortführen. Auch die Bereitstellung solcher höheren Kommunikationsdienste wird natürlich viel einfacher, wenn ein zentraler Server vorhanden ist.
Datenaustausch im lokalen Netz
Für die Kommunikation der Workstations untereinander existieren dagegen weiterhin Konstellationen, die eine befriedigende Lösung mit LU6.2 noch nicht zulassen. Dies ist zum einen dort der Fall, wo eine Verbindung zwischen OS/2- und Unix-Workstations benötigt wird. Zwar darf man hier einige Hoffnungen an die Tatsache knüpfen, daß die X/Open-Vereinigung sich zu CPI C bekannt hat. Dennoch wird es sicher länger dauern, bis CPI-C-Lösungen verfügbar sein werden. Aber auch in reinen OS/2- beziehungsweise DOS-Netzwerken kann die Verwendung von LU6.2 Probleme bereiten. Hier wirkt sich ungünstig aus, daß in der OS/2-Implementierung von LU6.2 Rechnergrenzen nicht völlig transparent werden: Verbunden werden können nur Prozesse, die auf verschiedenen Rechnern laufen, nicht aber Prozesse auf demselben Rechner. Es ist damit zu rechnen, daß sich letztlich auch hier CPI C als Standard durchsetzen wird.
Das Konzept der "Named Pipes"
Im Prinzip besteht immer die Möglichkeit, auf tieferen Schichten des Netzwerks, etwa auf Netbios oder TCP/IP, aufzusetzen. Dies birgt aber wegen des geringeren logischen Niveaus der Ebenen gewisse Risiken. Wünschenswert wäre ein Konzept, das in den oben geschilderten Problemsituationen LU6.2 auf dem gleichen logischen Niveau ersetzen kann. Hier scheint als einziger Kandidat derzeit das Konzept der "Named Pipes". Der Mechanismus erlaubt, gerichtete Punkt-zu-Punkt-Verbindungen zwischen zwei laufenden Prozessen aufzubauen. Der Prozeß auf der Empfängerseite einer "Named Pipe" ist austauschbar, wodurch auch ein Remote-Procedure-Call möglich wird: Auf ein Signal aus der Pipe hin ist es dem Empfängerprozeß möglich, den vom Sender gewünschten Prozeß aufrufen. Beide Kommunikationspartner identifizieren die Pipe über einen Namen. An ihm kann das Netzwerk erkennen, ob die Pipe sich auf demselben Rechner befindet wie der zugreifende Prozeß oder auf einem anderen, so daß völlige Transparenz der Rechnergrenzen gewährleistet ist.
"Named Pipes" vor allem im Token-Ring
Das Konzept der "Named Pipes" ist vor allem im Token-Ring verbreitet, jedoch auch auf Busnetzen wie Ethernet verfügbar. Novell hat ebenfalls signalisiert, die Version 3.1 von Novell-Netware würde "Named Pipes" unterstützen. Vor allem aber ermöglicht Hewlett-Pakkard "Named Pipes" zusammen mit 3Com und dem LAN Manager/X, so daß Verbindungen zwischen OS/2- und Unix-Workstations aufgebaut werden können.
"Named Pipes" dürften deshalb eine tragfähige Übergangslösung für die Zeit sein, die es brauchen wird, bis CPI C sich zum allgemein verfügbaren Standard entwickelt. Vorerst finden daher vielerorts Gateways Anwendung, in denen zwischen LU6.2 und "Named Pipes" umgesetzt wird, damit definierte Schnittstellen zwischen den beiden Protokollen entstehen.