[omniORB] Object to URI

[JHJE (Jan Holst Jensen)]

Hi Sergei.

Yeah, you have a point. It is more messy than I thought.

According to http://www.iona.com/devcenter/corba/corbaloc.pdf 

"ORBacus provides some proprietary APIs-in the BootManager
interface-that can be
used by developers to embed server-side corbaloc support in their own
server applications.
These APIs are used by the ORBacus implementation repository, which
looks up
name!stringified-IOR mappings in a configuration file."

and

"OmniORB server-side support for corbaloc URLs relies upon placing
objects into a
specific, predefined POA. OmniORB also provides a prewritten server
application called
omniMapper that can listen on a specified port number and looks up
name!stringified-
IOR mappings in a configuration file."

As if that weren't enough,
http://www.tatanka.com/doc/technote/tn0052.html says
"A corbaloc:iiop URL allows the specification of object keys. It is a
string of the form

corbaloc:<address_list>/<object_key>

where each member of the <address_list> is an IIOP address in a
specified form. The <object_key> is mapped from the object key used in
the IOR. The mapping is done by escaping octets or characters which are
not permitted in URLs. In Bionic Buffalo ORBs, such forbidden characters
are already escaped (as described above), so the <object_key> in the
corbaloc:iiop URL is the same as the object key used in the IOR."

I made the mistake of assuming that the BootManager interface was
standardized since it is a feature of both Orbacus (see
http://www.2k-software.de/ingo/corba_putrefs.html) and the pascal orb I
use the most (MT_DORB). So it appears to vary wildly between ORBs how
object names, ids or keys - what have you, are published for use with
corbaloc URIs.

I guess it is safe to say that published corbaloc object keys should be
documented well before they are of much use. I would go with a naming
service for publishing persistent objects and only use corbaloc for
bootstrapping - i.e. contacting singleton objects or standard services.

Cheers

-- Jan

-----Original Message-----
From: Serguei Kolos [mailto:Serguei.Kolos at cern.ch] 
Sent: 29. januar 2004 14:47
To: JHJE (Jan Holst Jensen)
Subject: Re: [omniORB] Object to URI

JHJE (Jan Holst Jensen) wrote:

Date: Thu, 29 Jan 2004 10:18:57 +0100
From: Serguei Kolos <Serguei.Kolos at cern.ch>
Subject: Re: [omniORB] Object to URI
    
[...]
  
Corbaloc's are for permanent objects, and as such can easily be 
generated by humans. When you initialize the ORB you have to 
nail down the orbs port, and as such you can now create a corbaloc.
      
This is not quite true because I also have to know how the 
object key is constructed.
As far as I know there is no way of doing that apart from 
learning this from particular ORB's source code.

All the examples I have seen use user-code generated object ids, e.g.
from http://www.2k-software.de/ingo/corba_putrefs.html

  PortableServer::ObjectId_var oid =
PortableServer::string_to_ObjectId("/Serverobjectname");
  PortableServer::ServantBase_var servant = xImpl;
  poa->activate_object_with_id(oid, servant);

If I understand correctly the structure of the object key in the IOR
(and corbaloc), then it is not 
the same as the object id, which is returned by the
PortableServer::string_to_ObjectId. The object 
key in the IOR (and corbaloc) normally contains the object's POA id and
the object id itself
with arbitrary number of an arbitrary symbols. This object key appears
only AFTER call to the
activate_object_with_id or equivalent function.

The question is still open - how one can use corbaloc if the object key
construction procedure is
not publicly available?

Cheers,
Sergei