Der Witz an den corbaloc ist, daßss man keinen Nameservice braucht, der z.B. ein single point of failure ist, wenn man nicht ganz besonders tolle nameserver implementiert.
Allerdings muß man dann genau den Rechner und port wissen (im IIOP-Fall), wo sich das Objekt befindet.
Beim Server brauchen wir nun persistente IORs (Interoperable Object Referenz), aus einem persistenten POA (Portable Object Adapter). (Achtung: persistente IOR heist, dass sie bei mehreren Incarnationen immer die selbe bleibt, die transiente IOR kann bei jeder Inkarnation eine andere sein, und nicht etwa daß das Objekt an sich persietent ist.)
Im Server muß deshalb ein POA mit persistenz-Policy erzeugt werden. Sinnvoll ist auch, dann eine expizite Objekt-Id vorzugeben, d.h. USER_ID - Policy, im gegensatz zur SYSTEM_ID-Policy.
An sich koennte der POA die corbalocs sirekt erzeugen. Das tut er auch, doch diese sehen beim TAO nicht schoen aus. (Beim MICO ist das anders).
Beim TAO gibt es daher einen IORTable-Mechanismus, der schoenere corbalocs erzeugt.
Der IOR-Tablemechanismus ist ein spezieller Objektadapter. Ich habe den Standard nicht genau im Kopf, aber es sieht so aus, das wie der Objektadapter seine Referenz ablegt, implementierungsspezifisch ist.
Aufruf:
./halloserver -ORBEndpoint iiop://zeta:12345 ./halloclient corbaloc:iiop:zeta:12345:/hallo Bernd