RPCs über SOAP

Übersicht:

• Was sind RPCs?
• RPCs mit SOAP
• Beispiel
• Vorteile und Defizite

Um Berechnungen auf mehreren Computern durchführen zu können, gibt es seit 1984 den Ansatz der entfernten Funktionsaufrufe (RPC; engl. remote procedure call), der von den Amerikanern Birrell und Nelson ersonnen wurde. Das zugrundeliegende Konzept ist relativ einfach: Ein Programm X auf Rechner A kann ein Unterprogramm X1 auf einem anderen Rechner B aufrufen und dabei evtl. auch Parameter übergeben. Programm X wartet nun, bis das Ergebnis von dem Unterprogramm nach Abschluß der Berechnungen zurückgegeben wird.

Für die Parameterübergabe packt das Programm auf dem anfragenden Rechner (Client) die Parameter ein, was durch einen sog. Client-Stub realisiert wird. Dabei sind zunächst einmal nur Call-By-Value-Parameterübergaben möglich, da ja beide Prozesse auf verschiedenen Rechnern und damit in unterschiedlichen Adressräumen laufen. Ein Server-Stub auf dem Rechner, an welchen die Anfrage gerichtet ist, packt die Parameter wieder aus und ruft die jeweilige Methode auf.

Probleme können dabei durch unterschiedliche Rechnerarchitekturen entstehen, wie zum Beispiel bei der Darstellung von Integer-Zahlen (1-er Komplement und 2-er Komplement) oder der Anordnung der Bytes in den verschiedenen Systemen (Big Endian bei SPARC, Little Endian bei Intel). Weiterhin müssen außer den berechnungsspezifischen Fehlerquellen auch noch Übertragungsfehler behandelt werden, wobei grundsätzlich 5 Fehlerkategorien unterschieden werden können

• Der Client kann den Server nicht lokalisieren
• Die Anfragenachricht geht verloren.
• Die Antwortnachricht geht verloren.
• Der Server fällt nach dem Erhalt der Nachricht aus.
• Der Client fällt nach Senden der Anfrage aus.

Momentan gibt es verschiedene Ansätze, RPCs zu realisieren. Dabei lassen sich zwei Formen unterscheiden: die Realisation in den eigentlichen Programmiersprachen (wie Remote Method Invocation in Java) oder das Benutzen eines Object Request Brokers in einer verteilten Objekt-Architektur wie DCOM oder CORBA. Beide Ansätze haben ihre Defizite, weil Sie implizieren, das die Kommunikationspartner entweder wie in Fall 1 die gleiche Programmiersprache verwenden, oder wie in Fall 2 das gleiche Protokoll für entfernte Methodenaufrufe. Leider (oder glücklicherweise?) wurde von Seiten der Industrie bisher keine einstimmige Entscheidung zugunsten einer einzigen Programmiersprache oder eines einzigen RPC-Protokolls getroffen.

Ein weiteres Problem stellt die Unfähigkeit von DCOM und CORBA dar, sich in Internet- Szenarien einzufügen. So ist es im Falle von DCOM zum Beispiel unwahrscheinlich, dass sich ein über das Internet angeschlossener Windows98-Nutzer bei einem Server auf Domänenbasis authentifizieren kann. Falls eine Firewall den Server von den Clients trennen sollte, so ist die Wahrscheinlichkeit einer Übermittlung von DCOM- oder CORBA-Paketen zwischen den kommunizierenden Rechnern relativ gering, da viele Firewalls aus Sicherheitsgründen nur HTTP-Pakete durchlassen. Während etliche Hersteller von ORBs mittlerweile Technologien verwenden, um Firewalls tunneln zu können, tendieren diese Object Request Broker dazu, sensibel gegenüber Konfigurationsfehlern zu sein.

[ Nach oben ]

SOAP stellt nicht nur einen standardisierten Weg zum Serialisieren von Daten zur Verfügung, sondern auch einen simplen Mechanismus, um auf entfernten Rechnern Methoden aufzurufen. Das Kapseln und Austauschen von RPCs in dem XML-Datenstrom war eines der Design-Ziele der Autoren der SOAP-Spezifikation, wozu eine einheitliche Darstellung von RPCs definiert wurde. Dabei ging es vor allem darum, auf existierenden Standards wie HTTP und XML ein einheitliches und erweiterbares Protokoll zu schaffen, welches auch in Umgebungen funktioniert (und gerade dort), wo herkömmliche RPC- Mechanismen scheitern.

Beim Nutzen des HTTP für Übertragungszwecke fügt sich ein RPC auf natürliche Weise in das Request/Response-Schema ein. Dabei wird der RPC als HTTP-Request übermittelt, das Ergebnis der Berechnung als HTTP-Response.

Um eine entfernte Methode aufzurufen, werden im Allgemeinen die folgenden Informationen veröffentlicht:

• Der URI des Zielobjektes
• Der Methodenname
• Evtl. vorhandene aktuelle Parameter der Methode.

Zusätzlich können weitere Informationen im SOAP-Header transportiert werden.

Für das Serialisieren eines RPC in einer SOAP Nachricht wurden in der Spezifikation relativ strikte Regeln definiert, um die gewünschte Interoperabilität zwischen verschiedenen System sicher zu stellen:

• Ein Methodenaufruf wird durch einen einzigen Struct repräsentiert, welcher von Namen und Typ mit der entsprechenden Methode übereinstimmt.
• Jeder IN- oder IN/OUT-Parameter wird durch ein Element in diesem Struct repräsentiert. Dabei korrespondieren auch hier Name und Typ des Element mit Namen und Typ des Parameters. Die Parameter-Elemente stehen auch in der selben Reihenfolge wie in der Signatur der Methode.
• Das Resultat eines Methodenaufrufs wird ebenfalls durch einen einzigen Struct repräsentiert. Dabei ist der Name des Structs nicht signifikant, es wird jedoch ein Anhängen des Wortes "Response" an den ursprünglichen Methodennamen als Konvention vorgeschlagen.
• Jeder OUT- oder IN/OUT-Parameter wird durch ein Element im Struct repräsentiert. Dabei ist das erste Element in dem Struct das Resultat des Aufrufs, wobei sein Name insignifikant ist. Es folgen die Parameter in der selben Reihenfolge wie in der Signatur des Methodenaufrufs.
• Ein evtl. aufgetretener Fehler muß durch Benutzen des SOAP-Fault-Elements übermittelt werden. Falls vom Übertragungsprotokoll weitere Regeln zum Übermitteln von Fehlermeldungen definiert werden (wie bei HTTP), müssen diese auch befolgt werden.
• Da ein Resultat ein erfolgreiches Ausführen eines RPCs signalisiert, ein Fault-Element aber einen Fehler, ist es unzulässig, in der Antwort auf einen RPC sowohl ein Resultat als auch einen Fehler zu übermitteln.

Header-Elemente können dazu benutzt werden, um Informationen, die nicht Teil der Signatur der aufzurufenden Methode sind, aber dennoch benötigt werden, zu übermitteln. Als Beispiel diene hier eine Transaktions- oder Session-ID:

[ Nach oben ]

POST /Aktien HTTP/1.1
Host: www.aktien.de
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "MeineURI"

<SOAP-ENV:Envelope
	xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
	SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/envelope/">
		<SOAP-ENV:Header>
			<T:Transaktion 
				xmlns:T="MeineAndereURI"
				SOAP-ENV:mustUnderstand="1">
				aERkjo545wrKij342nwET39
			</T:Transaktion>
		</SOAP-ENV:Header>
		<SOAP-ENV:Body>
			<M:HoleLetztenKurs xmlns:M="MeineURI">
				<Aktie>SUN</Aktie>
			</M:HoleLetztenKurs>
		</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn

<SOAP-ENV:Envelope
	xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
	SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/envelope/">
		<SOAP-ENV:Body>
			<M:HoleLetztenKursResponse xmlns:M="MeineURI">
				<Kurs>107.0</Kurs>
			</M:HoleLetztenKursResponse>
		</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

[ Nach oben ]

Remote Procedure Calls über SOAP abzuwickeln bringt im Vergleich zu den hergebrachten Lösungen mit ORBs sowohl Vorteile als auch Nachteile mit sich. ORBs können mit den zu versendenden Daten weitaus performanter verfahren, da sie die Datenstrukturen nicht in Zeichenketten serialisieren müssen. Dies verringert auf der einen Seite die Größe der Datenpakete (und damit die Übertragungszeit), auf der anderen Seite werden die Datenblöcke dem Betrachter gegenüber undurchsichtig. Der Nachteil dieses Verfahrens ist, dass die Gegenstelle der Kommunikation ein sehr komplexes Protokoll beherrschen muß, welches normalerweise kostspielige Middleware-Komponenten erfordert. Auch werden Datenpakete auf der Reise zwischen zwei ORBs von Firewalls leicht ausgefiltert, was den Einsatz in einem Business-To-Business-Szenario über das Internet stark verkompliziert.

Programmiert man sowohl Client als auch Server in ein und derselben Programmiersprache, lassen sich eventuell auch hier entfernte Methodenaufrufe direkt nutzen, wie beispielsweise bei Java die Remote Method Invocations. Sollte diese Möglichkeit bestehen, so sollte ihr auch unbedingt der Vorzug gegenüber SOAP gegeben werden, aus ähnlichen Gründen wie schon oben den ORBs: die Serialisierung der Daten kann schnell imperformant werden und in großen Datenpaketen resultieren. SOAP bietet sich vor allem dann an, wenn sehr unterschiedliche Systeme miteinander kommunizieren wollen, und die Geschwindigkeit der Datenübertragung keine vorrangige Rolle spielt. Hier kann der Einsatz einer einzigen Programmiersprache auf allen Systemen schnell unmöglich werden, oder er verbietet sich von selbst aus Gründen der Problemadäquatheit.

Einer selbstgebastelten Lösung "nach Hausmannsart" ist SOAP aus dem Grund vorzuziehen, aus dem eigentlich immer ein internationaler de-facto-Standard einer Einzellösung vorgezogen werden sollte: Die Chance der Wiederverwendung von Komponenten steigen, wenn öffentliche Standards benutzt werden. Zwei Kommunikationspartner werden sehr viel weniger Kommunikationsprobleme haben, wenn sich beide an ein öffentliches Protokoll halten, als wenn der eine den anderen erst von einer proprietären Lösung überzeugen muß.

[ Nach oben ]