Interoperable Object Reference
# Interoperable Object Reference

Die Interoperable Object Reference, kurz IOR, beschreibt eine Objektreferenz auf ein CORBA-Objekt. Es handelt sich um Objektreferenzen für Objekte aus dem Bereich der Objektorientierung, die in verschiedenen Computern existieren und systemübergreifend genutzt werden.

## Objekte und Referenzen allgemein

Die Objektorientierung als Methode der Strukturierung einer Software kennt Objekte, die zur Laufzeit eines Systems erzeugt werden und im Arbeitsspeicher des Computers existieren oder auch in objektorientierten Datenbanken langfristig gespeichert werden. Bei der Erzeugung solcher Objekte erhält man in der Regel eine Referenz, die dieses soeben erzeugte Objekt jederzeit eindeutig unter allen möglichen vorkommenden Objekten identifiziert.

Diese Referenz wird dann genutzt, um Nachrichten an dieses Objekt zu senden, auf in diesem Objekt gespeicherte Daten zuzugreifen oder diese zu verändern. Referenzen können genau wie andere Variablen oder Werte weitergegeben werden.

## Objekte und Referenzen in verteilten Systemen

In verteilten Systemen, bei denen sich Objekte in unterschiedlichen Computern (oder zumindest in getrennten Bereichen des Arbeitsspeichers) befinden, muss es einen Mechanismus geben, der Objekt-Referenzen über Systemgrenzen hinweg transportieren kann. Dazu sollte es möglich sein, diese Referenz in ein für die Übertragung geeignetes Format zu konvertieren (Stringifizierung) oder auch für die spätere Verwendung zu speichern.

## Interoperable Object Reference

Zu diesem Zweck der Systemgrenzen übergreifenden Kommunikation spezifiziert der CORBA-Standard die Interoperable Object Reference, kurz IOR genannt. Die IOR enthält alle Informationen, um einen ggf. prozess- und systemübergreifenden Kommunikationskanal zu einem Objekt aufzubauen und entsprechende Nachrichten, ähnlich denen innerhalb eines Prozesses, auszutauschen.

Dazu gehören Angaben wie:

* Art des Kommunikationsprotokolls
* Angaben zum Ort des Objektes, wie im Fall von TCP/IP eine IP-Adresse und ein Port
* Vorgaben zur Darstellung von Text und Daten, wie Codepages, Endian, Verschlüsselung oder Kompression der Daten
* Angaben zur Identität des Objekts im Zielsystem

Die OMG spezifiziert für diese Angaben so genannte "TaggedProfile" und "TaggedComponent", wie der folgende Auszug der IDL aus der Spezifikation zeigt.

Profiledaten und Komponentdaten enthalten eine Datenstruktur, deren Bedeutung durch das Tag (hier eine Zahl) festgelegt wird. Für einige Tags legt die CORBA-Spezifikation deren Datenstruktur fest, z. B. beschreibt ein ProfileId-Tag 0 ein IIOP Profile.

Der jeweilige ORB eines Systems bekommt die Aufgabe, IORs aus anderen Systemen (und von anderen ORBs) zu interpretieren und in eine Objektreferenz zu verwandeln oder auch Objektreferenzen in eine textuelle Interpretation zu verwandeln (stringifizierte IOR).

Hersteller, die eigene ORB-Implementierungen nach der CORBA-Spezifikation erstellen, können auch eigene Tags verwenden. Um Fehlinterpretationen auszuschließen, sollten diese sich jedoch nicht mit anderweitig vergebenen Tags überschneiden. Kennt ein ORB die Bedeutung eines Tags nicht, kann und darf er die in der Datenstruktur enthaltenen Informationen nicht verwenden.

Aus einer IOR kann nicht auf die Methoden und Datenelemente des referenzierten Objektes geschlossen werden. Die einzige Angabe in der IOR ist der Typ des Objekts (type_id, auch Repository-Id) genannt, der zu der IDL korrespondieren sollte, welche das Interface dieses Objekts beschreibt.

## IOR-Nachschlagewerke

Der CORBA Naming Service, der als Service ebenfalls von der OMG spezifiziert wurde, ist eine Möglichkeit zur Speicherung von Objekt-Referenzen unter einem Namen. Da der Naming Service ebenso ein CORBA-Objekt darstellt, dessen Referenz bekannt sein muss, um es zu nutzen, stellt sich jedoch das Problem, wie die IOR zum Aufrufer kommt, was im CORBA-Standard nicht spezifiziert ist. Stringifizierte IORs lassen sich jedoch in Dateien speichern oder per Mail, Web oder Filetransfer verschicken.

