Zur Integration von PCs in ein Gesamtsystem mit Servern und Hosts reicht die technische Verbindung zwischen den Rechnern nicht aus. Die Software auf den verschiedenen Rechnern muss miteinander interagieren. Michael Bauer* beschreibt Moeglichkeiten der Interprogramm-Kommunikation.
Bei operativen Anwendungen muessen richtige Client-Server-Loesungen geschaffen werden, bei denen eine transaktionsorientierte Verarbeitung (Online Transaction Processing = OLTP) ablaeuft, da mehrere Benutzer zugleich einen gemeinsamen Datenbestand bearbeiten. Eine Loesung ist, die Anwendungsprogramme auf den PCs ablaufen zu lassen und ihre Datenbankoperationen auf einem gemeinsamen Server abzuwickeln. Doch die Erfahrung zeigt, dass das Versenden von SQL-Befehlen (Structured Query Language) ueber das Netz - besonders bei einem remote angeschlossenen Server - nicht performant ist.
Eine bessere Alternative besteht darin, dass der Teil des Programms, der die Daten bearbeitet, auch auf dem Server ablaeuft und auf diese Weise die SQL-Befehle lokal erzeugt werden (siehe Abbildung 1).
Die Kommunikation zwischen dem Programmteil auf dem PC und dem auf dem Server kann auf zwei Arten erfolgen. Zum einen steht die Funktion "Stored Procedure" eines Server-DBMS wie Sybase, Informix, SQL-DB, Ingres oder Oracle zur Verfuegung. In diesem Fall uebernehmen die Routinen des DBMS den Transport des Aufrufes ueber das Netz. Doch diese Stored Procedures sind nicht bei jedem DBMS vorhanden. Ferner muessen sie in der Sprache des jeweiligen DBMS codiert werden und sind somit nicht mehr unabhaengig.
Zum anderen besteht die als universellere Loesung zu bezeichnende Moeglichkeit, die Server-Prozeduren als unabhaengige Programme zu schreiben und diese mittels Programm-zu-Programm-Kommunikation (Interprogram Communication = IPC) aufzurufen.
Stored Procedures sind nicht das Nonplusultra
Hierfuer steht eine Vielzahl von Schnittstellen zur Verfuegung, deren Beurteilung nach fuenf wesentlichen Kriterien erfolgt:
1.Aufgabenstellung: Genuegt eine Kommunikation, die allein vom PC ausgeht, oder soll eine bidirektionale Kommunikation moeglich sein?
2.Funktionsumfang: Reicht ein einmaliger Aufruf eines entfernten Programms aus, oder ist eine Mehr-Schritt-Konversation mit entsprechenden Synchronisationsmechanismen erforderlich?
3.Reichweite: Soll die IPC nur innerhalb eines LANs oder auch in Verbindung mit einem Host-Rechner erfolgen?
4.Protokollunabhaengigkeit: Welcher Wert wird auf Normung und damit auf die Unabhaengigkeit der Schnittstelle in bezug auf unterschiedliche Netzprotokolle gelegt?
5.Komplexitaet der Programmierung: Wie abstrakt soll die Schnittstelle sein? Was kann der Entwickler beherrschen? Wie hoch darf der Anteil des speziellen Codes fuer IPC in einem Anwendungsprogramm sein?
Einige Kommunikations-Schnittstellen sind so ausgelegt, dass immer nur ein Rechner die Kommunikation eroeffnet und steuert; dies ist beispielsweise bei dem Emulator High Level Language API (EHLLAPI) so. Fuer eine vollstaendige Kommunikation zwischen Rechnern werden jedoch Protokolle benoetigt, die beide Partner gleich berechtigen. Somit kann jeder Rechner eine Verbindung eroeffnen und den Ablauf der Kommunikation steuern.
Bei einem solchen symmetrischen Protokoll muessen die Programme an beiden Enden der Kommunikationsstrecke die gleiche Schnittstelle benutzen. Deshalb bezeichnet man ein solches Protokoll als "End- zu-End-" oder "Peer-to-peer-Protokoll".
Netbios ist zur Zeit der De-facto-Standard fuer IPC innerhalb eines LANs. Netbios-Schnittstellen existieren fuer TCP/IP, XNS (Netware), OSI und IEEE 802.2. Anwendungen, die Netbios benutzen, koennen unter MS-DOS, OS/2 oder Unix laufen. Mittels Sessions bietet Netbios einen zuverlaessigen bidirektionalen Transportservice fuer IPC mit entsprechenden Quittungsmechanismen. Die Programmier- Schnittstelle besteht aus 20 Kommandos.
Bei Named Pipes handelt es sich um einen Kommunikationsmechanismus zwischen Programmen, der sowohl innerhalb eines Rechners als auch im LAN ablaufen kann.
Named Pipes beinhaltet einen wesentlich hoeheren Grad an Abstraktion als Netbios. Einer einzelnen Named-Pipe-Funktion entsprechen oft eine Vielzahl einzelner Netbios-Calls.
Die Uebergabe von Nachrichten zwischen den Anwendungen erfolgt wie das Lesen und Schreiben sequentieller Dateien. Damit wird das Netz fuer den Programmierer unsichtbar. Named Pipes werden von den meisten LAN-Produkten unterstuetzt
Die Schnittstelle EHLLAPI wurde von der IBM entwickelt, um Terminalemulationen auf PCs aus Programmen heraus einfach ansprechen zu koennen. Inzwischen wird dieses Interface von den meisten Terminalemulationen bedient. Da der Bildschirm-Datenstrom, der eine Host-Anwendung empfaengt oder sendet, "angezapft" wird, lassen sich bestehende Host-Anwendungen ohne Aenderungen verwenden. Somit bietet sich ein leichter Einstieg in die PC-Host- Kommunikation, wobei zwei Aspekte zu beachten sind: Eroeffnung und Steuerung der Kommunikation kann nur vom PC ausgehen. Ausserdem gibt es keinen Quittungsmechanismus. Somit ist nur eine Ein- Schritt-Kommunikation sinnvoll.
TCP/IP unterstuetzt ueber die Socket-Schnittstelle schon seit 1981 die Peer-to-peer-Kommunikation. Dabei stehen dem Programmierer 54 Kommandos zur Verfuegung. Durch die weite Verbreitung von TCP/IP kann die IPC sowohl im LAN als auch zu und zwischen Host-Rechnern aufgebaut werden. APPC stellt eine Programmier-Schnittstelle fuer LU 6.2 in einem SNA-Netz dar. Bei LU 6.2 handelt es sich um einen selbstaendigen Knoten fuer die Peer-to-peer-Kommunikation.
APPC umfasst 60 LU-Verben und eine Vielzahl von Parametern. Damit ist eine gesicherte Konversation zwischen Partneranwendungen moeglich (siehe Abbildung 2). Eine Konversation umfasst mehrere Nachrichten, die miteinander ausgetauscht werden. Entsprechend gibt es auch Befehle fuer Quittung, Synchronisation und Rollback. Doch darin liegt auch der Haken. Obwohl LU 6.2-Unterstuetzung von so gut wie allen Herstellern angeboten wird ist der Leistungsumfang unterschiedlich implementiert. So sind zum Beispiel in OS/2 die Synchronisationsbefehle nicht enthalten. Auch die Sprach-Schnittstellen (APIs) sind ueber die verschiedenen Implementierungen hinweg nicht konsistent.
Zur Loesung der Probleme von LU 6.2 hat IBM im Rahmen des SAA- Konzepts eine neue Sprach-Schnittstelle definiert, die auf LU 6.2 aufsetzt: das Common Programming Interface for Communication (CPI- C). Durch die Lizenzierung an X/Open wurde daraus ein De-facto- Standard fuer die Peer-to-peer-Kommunikation. Anwendungen mit CPI-C besitzen eine einheitliche und portable Sprach-Schnittstelle, die unter CICS, TSO, IMS-DC, OS/2, Sinix, BS2000, OSI, AS/400 oder MS- DOS etc. gleichartig ist. Auch die Bandbreite des Funktionsumfangs wurde nivelliert. Damit ist eine einheitliche Interoperabilitaet zwischen Rechnern jeder Art auf LANs und WANs moeglich.
CPI-C stellt jedoch nicht die Loesung aller IPC-Probleme dar. Es ist wie LU 6.2 fuer einen normalen Anwendungsentwickler viel zu komplex: Es verfuegt ueber 29 Call-Funktionen mit einer Vielzahl von Parametern. Ausserdem deckt CPI-C einen Funktionsumfang ab, der fuer normale Client-Server-Anwendungen gar nicht benoetigt wird. Im Rahmen operativer Client-Server-Loesungen genuegt es, einer Server- Funktion einmalig einen Aufruf zuzusenden.
Ueber eine solche Funktionalitaet verfuegt der Remote Procedure Call (RPC). Es handelt sich hier um eine maechtige und abstrakte Schnittstelle, die den Anwendungsentwickler und das Programm, an dem er arbeitet, von jedem Wissen ueber die Kommunikation und die darunterliegenden Netzprotokolle freihaelt.
Er verwendet die normale Call-Funktion, die sonst zum Aufruf lokaler Unterprogramme dient, um ihnen Parameter mitzugeben. Nur in diesem Fall laeuft das Unterprogramm auf einem entfernten Rechner ab. Zur technischen Realisierung solcher RPCs gibt es drei Moeglichkeiten:
1. RPC-Compiler: Im Rahmen von TCP/IP sind RPC-Compiler schon seit Jahren ueblich. Sie generieren fuer das rufende und gerufene Programm jeweils ein Ersatzstueck fuer das fehlende Partnerprogramm (stub) sowie die entsprechende Netzbibliothek, um die Parameter des Calls in Form einer Nachricht zu versenden oder zu empfangen. Bei TCP/IP setzen die RPCs auf der Socket-Schnittstelle auf, aber im Prinzip koennten Netzbibliotheken fuer verschiedene Protokolle eingebunden werden.
Aus den beiden RPC-Haupt- linien (Sun-RPC und NCS-RPC) hat sich fuer das Softwarepaket OSF/DCE (DCE = Distributed Computing Environment) ein einheitlicher RPC herauskristallisiert. Zur Zeit wird DCE allerdings erst im Unix-Bereich (auch AIX) ausgeliefert. Angekuendigt sind auch noch die Plattformen OS/2 und MVS/ESA mit Posix-Schnittstelle. Damit fehlt natuerlich die Unterstuetzung des wichtigsten Traegersystems fuer Client-Server-Anwendungen, naemlich CICS. Hier bietet die Firma Netwise einen "Mainframe-RPC" an, der OS/2-, Sun-, VMS- und CICS-Plattformen verbindet.
2. Eine auf CICS begrenzte RPC-Funktionalitaet ist der "Distributed Program Link" im CICS. Hierbei wird der normale CICS- Unterprogrammaufruf (EXEC CICS LINK) von einem CICS-System zu einem anderen zur Ausfuehrung versendet. Dazu nutzt CICS LU 6.2. Die Daten werden in Form der COMMAREA mitgeschickt. CICS selbst nutzt dazu wiederum LU 6.2. Da CICS inzwischen auf den Betriebssystemen MVS, VSE, OS/400, OS/2, AIX und VMS verfuegbar ist, bietet DPL eine weitreichendere Unterstuetzung fuer heterogene Rechner als der DCE-RPC.
3. Proprietaere Loesungen: Zwar ist DPL von CICS proprietaer, doch aufgrund der grossen Verbreitung von CICS schon fast wieder als Standard zu betrachten. Anders sieht es mit RPC-Funktionen aus, die in bestimmten Sprachen oder Generatoren eingebunden sind. Als gutes Beispiel laesst sich hier die Sprache "Natural" anfuehren. Fuer ein in Natural geschriebenes Programm bleibt der uebliche Unterprogrammaufruf (CALLNAT) bestehen. Den Versand an ein anderes Natural-Programm uebernimmt die Komponente Netword. Da Natural vom PC bis zum Mainframe auf vielen Plattformen laeuft, ist eine einfache Zusammenarbeit zwischen vielen heterogenen Rechnern moeglich. Fuer eine Generatorloesung kann "AAI" von Microfocus als Beispiel dienen. Damit wird RPC-Funktionalitaet generiert und an ein Cobol-Programm angebunden.
Um Client-Server-Loesungen wirtschaftlich zu erstellen, sollte die Kommunikation zwischen dem Client- und dem Server-Teil einer Anwendung fuer den Programmierer unsichtbar und auf allen wesentlichen Betriebssystem- und Netzplattformen verfuegbar und damit portabel sein. Dies ist die Aufgabe einer neuen Softwarekategorie, der Middleware.