Remote Procedure Call / RPC-Webservices
Im Grunde genommen gibt es Remote-Dienste schon seit einer Ewigkeit. Sie stellen durch die gegebene Möglichkeit, auf entfernten Rechnern arbeiten zu können, genau das dar, was durch die Schaffung des ARPANets Ende der 60er erreicht werden sollte. Terminal-Werkzeuge wie Telnet, rlogin oder auch SSH bilden mit ihren Kommandozeilen also bereits genau die Remote-Funktionalität ab, die auch RPC für sich als technologisches Mittel der Internet-Neuzeit nutzt.
Der Gedanke der RPC Entwicklung stellt aber nicht den Anwender in den Mittelpunkt, der sich durch Telnet oder SSH Remote Protokolle auf andere Server einloggt, sondern richtet zunächst an die Vermittlung und Kommunikation von entfernten autonomen Softwarekomponenten. Das eigentliche Ziel, das RPC verfolgt, ist die „konsequente Fortsetzung der Modularisierung in der Programmierung“1 und das Zusammenspiel von netzwerkfähigen Plattformen im Sinne einer verteilten Anwendung.
GESCHICHTE UND HINTERGRUND VON REMOTE PROCEDURE CALLS (RPC)
In seinem Ursprung wurden Remote Procedure Calls (RPC, Aufruf einer fernen Prozedur) erstmalig 1976 publiziert. Sie waren Bestandteil des Xerox Network Systems sowie Novells Netware. Als ein in den RFC Standards 1057, 5531 eingetragenes Konzept wurde 1988 das ONC RPC (Open Network Computing RPC) von Sun Microssystems entwickelt, das zunächst für das hauseigene Network File System (NFS) verwendet wird. Aufgrund seiner Beliebtheit und hohen Verbreitung fand die Implementierung letztlich auch ihren Weg in das Linux Betriebssystem. Die Windows Seite verfügt ihrerseits über eine eigene Microsoft RPC Variante, die eine andere Referenzimplementierung nutzt (DCE RPC), sich über die Schaffung des DCOM-Standards weiterentwickelte und heute im .NET Remoting Framework enthalten ist.
In einem großen Ideenrahmen ermöglichen verteilte Anwendungen nicht nur Synergien, auch ungünstig gewachsene Infrastrukturen lassen sich durch sie einfach verbinden – ganz zu schweigen von den Vorteilen, die sich bieten, wenn flexibel auf makroökonomische Schwankungen des Marktes kostengünstig reagiert werden muss.
Bezogen auf die reinen softwaretechnischen Inhalte führt RPC uns direkt zum Thema Middleware mit ihrem typischen Schichtenkonzept. Dabei ist es egal, ob realisiert als Interprozesskommunikation auf Betriebssystemebene im Kernel oder als Java Interpreter, viele Softwaresysteme profitieren vom Remote Procedure Konzept. Eigentlich aber stehen Middleware Anwendungen vor allem für den folgenden Gedanken: Die Ausprägung in Kombination von Frontend, Backend und Datenbank – auf den Punkt gebracht – WEBSERVICES.
RPC und Webservices stehen insbesondere für freie wie auch kostenpflichtige APIs und eine IT Landschaft, die es erlaubt, auf Basis von bereitgestellten Framworks (Google, Amazon) profitorientierte Internetdienste anzubieten und verteilte Anwendungen zu entwickeln, die globale Webanwendungen ermöglichen.
Du brauchst Hilfe?
-
Wir sind erfahrene Web-Entwickler und Web-Designer aus Köln. Seit Gründung im Jahr 2011 arbeiten wir für unsere Kunden regelmäßig mit PHP, Ruby on Rails in der Softwareentwicklung und WordPress.
-
Du musst nicht länger suchen, wir vermitteln dir bezahlbare Agentur-Leistungen. Gerne arbeiten unsere Webentwickler auch als Teil deines Teams.
-
Beschreibe uns doch kurz deinen Bedarf. Wir rufen dich zurück, wann immer du Zeit hast. Fragen zu Aufwand und Komplexität eines Projektes beantworten wir natürlich kostenlos.
Neugierig geworden?
Nimm jetzt Kontakt mit uns auf. Wir freuen uns auf dich.
KOMMUNIKATION ÜBER REMOTE PROCEDURE CALLS (RPC)
Eine Realisierung von Remote Procedure Calls ist an sich die Implementierung eines Client Servers Modells. Als Protokoll sitzt RPC auf der fünften Schicht (Session Layer) des OSI-Modells und ist gekennzeichnet durch den Client, der parametrisierte Übergaben bei Aufruf einer Anwendung auf dem Server initiiert und mit der Ausführung eigener Prozesse bis zum Eintreffen einer Antwort des Servers und den entsprechenden Ergebnissen wartet.
Um eine entfernte bzw. fremde Prozedur aufzurufen, wird dazu auf Client-Seite zunächst eine Nachricht mit einem eindeutigen Identifier der Prozedur versandt und als Anfrage (Call Message) kommuniziert. Auf Seite des Servers übernimmt der Portmapper-Daemon (ONC RPC auf UDP/TCP Port 111) bzw. Endpointmapper (DCE RPC auf UDP/TCP Port 135) die Funktion des zentralen Empfängers, der die Informationen der Client Nachricht ausliest und an die Server Anwendung weiterleitet. Die Server-Anwendung generiert auf Basis der hereingereichten Daten daraufhin ihre Antwort, deren Ergebnisse dann als Reply Message an den Client ergeht. Für das Verständnis wichtig ist die wichtige Eigenschaft von RPC, dass es den Portmappern gestattet ist, die aufgerufenen Prozesse erstmalig neu zu erschaffen bzw. nach Belieben zu aktivieren. Zudem ist der Umstand erwähnenswert, dass mit und durch RPC mehrere Prozesse gleichzeitig verarbeitet werden können.
Das für die Software-Entwicklung kritische Moment in Bezug auf RPC ist vor allem die Fehlerbehandlung und die Anbindung von Variablen an lokale und entfernte Namensräume. Die im Allgemeinen verbindungslose Kommunikation über UDP macht dabei eine etwas aufwendigere Lösung hinsichtlich der Auswertung von Fehlern notwendig, die insbesondere das Vorhandensein von Doubletten ausschließen muss, und es verstehen sollte, hängende oder ausbleibende Server-Antworten zu kompensieren. Neben dem Java RMI Mechanismus stellen insbesondere CORBA und XML-RPC interessante Architekturen bereit, die für die technische Umsetzungen mit RPC uneingeschränkt genutzt werden können.