IIOP

Das Internet Inter-Orb Protocol (IIOP) [Omg98] ist die Implementation des von der OMG festgelegten Standardprotokolls zur Kommunikation zwischen ORBs (GIOP) auf Internet-Ebene.
IIOP ist ein weiteres Protokoll der Anwendungsschicht und ähnelt im Aufbau in gewisser Weise HTTP [Ix97]. Auch IIOP hat einen kleinen Satz an Nachrichten (Messages), die für die Kommunikation zwischen Clients und Servern sorgen und basiert auf dem Request/Reply-Paradigma (anders als unter HTTP, wo der Browser Anfragen stellt, die der Server beantwortet, kann aber jedes Objekt gleichzeitig Client und Server sein, wodurch, die Kommunikationsmöglichkeiten prinzipiell symmetrisch sind). Die wichtigsten Nachrichten sind dabei die vom Typ Request und Reply. Beide Nachrichten bestehen aus einem Protokoll-Kopf, der neben weiterer Meta-Information den ``Adressaten'' enthält (beim Request einen Objekt-Schlüssel und die aufzurufende Operation, beim Reply den Schlüssel des aufrufenden Requests) und einem Protokoll-Körper (Body), in dem die übergebenen Parameter enthalten sind. Da die Request-Nachricht unter den Gesichtspunkten Sicherheit und Proxifizierung sicherlich von Interesse ist (schließlich muß anhand von ihr entschieden werden, ob eine Anfrage erlaubt ist und an wen sie weitergeleitet werden muß), wollen wir sie uns genauer ansehen (Abb.3): Eine Request-Nachricht beginnt zunächst mit dem GIOP-Header, der die Anfrage als eine GIOP-Nachricht identifiziert und neben der Versionsnummer ihren Typ (in diesem Fall also ``Request'') festlegt. Es folgt der eigentliche Request-Header, in dem die interessanten Felder die folgenden sind:

 

Abbildung 3: Der IIOP-Request Header

• Das service_context-Feld erlaubt es CORBA-Services, dem Request zusätzliche Informationen beizulegen. Diese werden allerdings von der CORBA-Kernspezifikation nicht benutzt.
• Die request_id, die den Request mit einer eindeutigen Nummer identifiziert. Dies ist wichtig für die richtige Zuordnung der Antwort des Servers.
• Das Feld response_expected, das angibt, ob der Client eine Antwort erwartet, dies ist etwa beim Aufruf einer oneway-Operation nicht der Fall.
• Der object_key, mit dem das Zielobjekt eindeutig ermittelt werden kann.
• Das operation-Feld, das die aufzurufende Operation enthält.
• Das requesting_principal-Feld, das die Benutzerkennung der Person enthält, die den Client gestartet hat.

Der daraufhin folgende Reqest-Body enthält die zur Ausführung der Operation nötigen Parameter.

Um ein CORBA-Objekt unter IIOP weltweit eindeutig zu adressieren wird ein ähnliches Konstrukt wie ein URL verwendet: die Interoperable Object Reference (IOR). Da IIOP im Gegensatz zu HTTP keine textbasierte, sondern eine numerische Darstellung wählt, sieht die verwendete URL weniger intuitiv aus. Hier ein Beispiel:

IOR:010000000e00000049444c3a48656c6c6f3a312e3000000001000000000000003e00
000001010040130000006d6f7365732e6d75656e737465722e636f6d0000891300001a00
00004f422f49442b4e554d0049444c3a48656c6c6f3a312e30003000

Betrachtet man diese Datei jedoch mit einem Hilfsprogramm (z.B. iortool von Iona, oder iordump von OOC), das die Zahlen - wo möglich - in die zugehörigen ASCII-Zeichen umwandelt, so erhält man die folgenden Informationen [Ow97]:

RXR:_______%0eIDL:Hello:1.0______%01_______>_%01_____%13moses.muenster.c
om__%13%89_____%1aOB/ID+NUM_IDL:Hello:1.0_0_

Auf die einzelnen Felder soll hier nicht im Detail eingegangen werden; wichtig zu wissen ist jedoch, daß neben der TCP-Adressierung (Rechnername/IP-Adresse und Port) noch weitere Informationen übergeben werden, darunter auch eine Zeichenkette (der object_key), die von dem zugehörigen ORB lokal interpretiert wird. Diese Zeichenkette wird im Standard nicht spezifiziert und ist damit für das Protokoll undurchsichtig (``opaque'').