Maskierung der Server-IOR: Bevor nun die IOR an den Client übergeben wird, wandelt ein Hilfsprogramm einen Teil der IOR (in der Regel das Adreßfeld Rechnername/Port) um, indem es an die Stelle des Rechners, auf dem das Objekt abläuft, die Adresse des Proxy-Servers hinterlegt. Zusätzlich muß der Proxy wissen, wo sich das Objekt befindet.
Übermittlung zum Client und Umwandlung der IOR in ein Objekt: Die IOR wird daraufhin, wie normalerweise üblich, dem Client über eine Netzwerkverbindung übermittelt - etwa via HTTP als Parameter eines Applets oder via NFS als Datei, und dieser wandelt sie durch string_to_object() wieder in eine Referenz auf ein CORBA-Objekt um.
Entfernter Methodenaufruf: Will nun der Client in dem entfernten Objekt eine Methode aufrufen, so tut er dies, indem er eine TCP-Verbindung zu dem Proxy-Server öffnet, im Glauben, das Objekt befinde sich dort.
Aufnahme und Weiterleitung des Aufrufs durch den Proxy: Stattdessen ``lauscht'' aber ein Programm auf diesem Port, das den Request-Header (s. 1.3.2) der IIOP-Nachricht ausliest, das originale Objekt über eine Datenbank ausfindig macht und die Nachricht an den richtigen Adressaten weiterleitet.
Interessant ist sicherlich der Fall, in dem das entfernte Objekt eine sog. Factory ist, was soviel heißt, daß es eine Referenz auf ein weiteres CORBA-Objekt zurückliefert. Dies ist etwa bei einem Objekt der Fall, das die im folgenden Beispiel skizzierte Schnittstelle Kernel::Context des Insekten-Simulators implementiert:
// IDL
interface Insect {
...
};
interface Context {
...
Insect createInsect(...);
};
In diesem Fall stellt sich bei der Proxifizierung folgendes Problem:
Der Client fordert vom Server durch Aufruf von createInsect()
ein neues Insekt an; dieser weiß jedoch nicht, daß er hinter einer
Firewall abläuft und gibt die Referenz auf das Insekt in Form einer
IOR zurück, die höchstwahrscheinlich auf einen Rechner verweist, auf
den der Client keinen Zugriff hat.