Die Interoperable Object Reference, kurz IOR, ist die eindeutige Kennzeichnung eines CORBA-Objektes, welches eine Instanz eines Servant darstellt (ein Servant wiederum ist die programmiersprachen-abhängige Implementierung der per IDL spezifierten Klasse).
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 (siehe auch Referenzen), die dieses soeben erzeugte Objekt jederzeit eindeutig unter Millionen anderer Objekte identifiziert.
Diese Referenz wird dann genutzt, um Methoden auf dem Objekt zu rufen, 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 Kommunikationskanal zu einem Objekt aufzubauen und entsprechende Aufrufe, wie auch in einem lokalen System, durchzuführen.
Dazu gehören Angaben wie:
- Art des Kommunikationsprotokolls
- Angaben zur Lokation 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.
struct TaggedProfile {
ProfileId tag;
sequence <octet> profile_data;
};
struct IOR {
string type_id;
sequence <TaggedProfile> profiles;
};
struct TaggedComponent {
ComponentId tag;
sequence <octet> component_data;
};
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. Andere Tags werden auch proprietär von den ORB-Herstellern festgelegt.
Der jeweilige ORB eines System 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).
Leider lässt sich aus den IORs nicht ablesen, welchen Methoden und Datenelemente das Zielobjekt besitzt. 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 des Objekts beschreibt.
IOR-Nachschlagewerke
Der Naming Service stellt den oben erwähnten Speicher dar, in dem Objekt-Referenzen unter einem Namen abgelegt werden können. Da der Naming Service ebenso ein CORBA-Objekt darstellt dessen Referenz bekannt sein muss, stellt sich wiederum das Problem, wie die IOR zum Aufrufer kommt. Leider spezifiziert der Standard nicht, wie die IORs zum Empfänger kommen. Aber zu diesem Zweck lassen sich stringifizierte IORs natürlich auch in Dateien speichern oder per Mail, Web, Filetransfer verschicken oder auch am Telefon durchsagen.