Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.


20.08.1993

Middleware-Komponenten muessen nicht neu sein Erst Remote Procedure Calls ermoeglichen Client-Server-DV

*Gottfried Horlacher ist Geschaeftsfuehrer der C-Technologies GmbH, Dreieich-Sprendlingen.

Middleware ist zwar ein neues Schlagwort, doch nicht jede einschlaegige Technik ist neuesten Datums. So kennt die Unix-Welt laengst Netzwerkverfahren, die zwischen heterogenen Systemen vermitteln. Zur Middleware werden Techniken wie das Netware File System (NFS) und der darin enthaltene Remote Procedure Call (RPC) dadurch, dass sie die Unix-Grenzen laengst ueberschritten haben und fast auf allen gaengigen Systemen eingesetzt werden.

Client-Server-Loesungen bestehen aus vernetzten Rechner- und Betriebssystem-Strukturen, die es gestatten, Programme und Daten ueber die verschiedenen Systeme im Netz zu verteilen. Damit werden die Systemleistungen der Netzkomponenten besser genutzt, proprietaere Inselloesungen ueberfluessig und Installationen flexibler konfigurierbar.

Ins Rollen brachte den Zug weg von der zentralistischen DV hin zur verteilten Datenverarbeitung das Betriebssystem Unix. Das hing nicht zuletzt damit zusammen, dass es von Anfang an Netzfunktionen enthielt. Unix ist heute das Rueckgrat offener Systemkonzepte, da es die unterschiedlichsten Hardwareplattformen mittels anerkannter Protokollstandards verbindet.

Unix ist nicht gleich Unix. Jeder Hersteller hat das Betriebssystem um spezifische Funktionen erweitert. Software- Entwickler, die plattformuebergreifende Client-Server-Anwendungen erstellen wollen, muessen all die feinen Unterschiede der Systeme und Netzwerk-Protokolle kennen. Wenige haben sich bis heute mit Remote Procedure Call (RPCs) beschaeftigt, einem Mechanismus, der dem Entwickler die Verteilung seines Programms im Netz ermoeglicht.

Die RPC-Technologie wurde urspruenglich im Jahre 1983 bei Xerox Parc entwickelt. Sie besteht aus einer Bibliothek von Funktionen, die dem Programmierer den Aufruf von Prozeduren innerhalb eines anderen Prozesses sowohl lokal als auch auf einem anderen System im Netzwerk ermoeglichen.

Die Informationsuebertragung vom Aufrufer (Client-Prozessan den Aufgerufenen (Server-Prozess) wird in Form von Uebergabeparametern fuer die Prozedur abgewickelt. Die Ergebnisse werden als Return- Werte zur Verfuegung gestellt. Der Programmierer muss sich nicht um Message-Passing oder In- und Output-Operationen kuemmern. Durch die Abstraktion mittels der RPC-Befehle koennen Prozesse im gesamten Netz transparent ueber Prozeduraufrufe verteilt werden.

Die RPC-Funktionsbibliothek kursierte in den 80er Jahren als Freeware in der amerikanischen Universitaetsszene. Weite Verbreitung erfuhr die Technologie, als Sun Microsystems den Quellcode fuer RPC als Teil des Netware File Systems (NFSueber das weltweite Internet-Netzwerk frei zugaenglich machte. NFS ist heute durch weitreichende Lizenzierung de facto der Standard fuer die netzwerkweite Dateiverwaltung im Unix-Umfeld geworden und Bestandteil der Sun- und COSE-Standards ONC und ONCi (Open Network Computing). Dazu gehoert auch External Data Representation (XDR), eine Technik, die die gemeinsame Darstellung der Daten unabhaengig von den Prozessoren im Netz regelt, indem es Unterschiede in der Anordnung der Datenbytes, der Data Type Sizes sowie der Darstellung und Ausrichtung aufloest.

Das NFS-Verfahren ist auch in andere Systemwelten eingeflossen. Zu nennen sind hier IBMs MVS, DECs VMS, Novells Netware, Apples Macintosh, Microsofts Windows unter PC/NFS und IBMs OS/2. Damit stehen die RPC-Funktionen auch in den Systemen der genannten Hersteller zur Verfuegung.

Programmieren mit dem

Remote Procedure Call

Die RPC-Mechanismen als Entwickler anzuwenden ist nicht allzu einfach. Neben der Programmierung der Client- und Server-Prozesse mit RPC-Funktionen muessen die Dienste fuer die Kommunikation zwischen den Systemen und entsprechende Fehlerbehandlungsroutinen definiert werden. Bei komplexen Programmen mit vielfaeltiger Verteilung von Subprozessen im Netz wird das Ganze recht aufwendig und unuebersichtlich.

Der Einsatz von Protokoll-Compilern vereinfacht die RPC- Programmierung wesentlich. Mit solchen Werkzeugen werden die Bezeichnungen der Prozeduren, die die gewuenschten Dienste realisieren, sowie die Datentypen der Uebergabeparameter wie auch Rueckgabewerte in einer Protokolldefinition festgeschrieben. Der Protokoll-Compiler uebernimmt diese Definitionen und erzeugt automatisch die Client- und Server-Stubs (Stubs sind standardisierte RPC-Kommunikations-Schnittstellen, die die komplexen RPC- Dienste vor den Client-Server-Prozessen verstecken).

Werkzeug fuer die

RPC-Programmierung

Unter der kryptischen Bezeichung "rpcgen" kam vor einiger Zeit ein Werkzeug fuer die RPC- Programmierung heraus, das inzwischen mit verschiedenen Versionen von Unix System V, Release 4, (SVR4) ausgeliefert

wird. Die Funktionalitaet ist eng begrenzt. So eignet sich das Tool nur fuer synchrone RPCs, laesst nur ein Funktionsargument zu und keine komplexen Datenstrukturen. Zudem muessen die Protokolldefinitionen noch mit Hilfe der Sprache RPCL angepasst werden.

Ausser fuer sehr einfache Anwendungen wird es meistens erforderlich, den entstandenen Quellcode manuell zu modifizieren und zu erweitern, um Zuverlaessigkeit zu garantieren. Dazu ist schon einiges Know-how in der RPC-Technik erforderlich, wie es erst wenige Programmierer haben. Die schlechte Dokumentation von rpcgen erschwert zudem den Einstieg.

Seit Anfang der 90er Jahre liefert eine Handvoll von Unternehmen entsprechende Code-Compiler. Sie bieten deutlich mehr Funktionalitaet als rpcgen, generieren aber meist verschluesselten Code. Dies ist insbesondere ein Problem bei der Fehlersuche in der Anwendung, denn es gibt keine Moeglichkeit, den RPC-Code zu beurteilen.

Offene RPC-Compiler-Toolkits machen die RPC-Technologie einfacher nutzbar. Sie sind damit ein wichtiger Baustein fuer die wirtschaftliche Programmierung und Wartung von verteilten Anwendungen auf der Basis des Client-Server-Modells. Neben der Unterstuetzung der Standards NFS/RPC und XDR sollten sie das Einarbeiten in die RPC-Technologie erleichtern und das Umstellen von existierenden, lokalen Anwendungen auf verteilte Loesungen besonders einfach gestalten.

Als neuester Standard gilt die Transport-Independent-(TI-)-RPC- Vereinbarung. Sie stellt ein neues High-level-Interface dar, das mit den von der International Standards Organisation (ISO) spezifizierten Richtlinien im Einklang steht. Auf der Basis dieses neuen Standards koennen Applikationen unabhaengig von den Transportprotokollen im Netz verteilt werden. Sun und Novell haben bereits entsprechende TI-RPC-konforme Bibliotheken in ihren neuen Betriebssystem-Versionen angekuendigt. Somit koennen PC-Plattformen mit PC/NFS und Netware-Support of TI-RPC in die Client-Server- Umgebung eingebunden werden.

Tausende von praxiserprobten Anwendungen warten darauf, endlich die heute verfuegbare Hardwaretechnologie zu nutzen - zum Wohle des Anwenders, der mehr Leistung, schnellere Antwortzeit und flexibleren Ressourcenzugriff verlangt. RPC-Funktionen sind heute Bestandteil aller offenen Systemarchitekturen der fuehrenden Systemhersteller. Anwendungsentwickler setzen somit nicht auf eine Eintagsfliege, sondern auf eine Technologie mit garantierter Zukunft.