Interoperability with other orb implementations can
only be done by the communication of at least one object reference.
In order for any orb to understand how to access an object managed by
another orb, the OMG has defined a standard format named
Interoperable Object Reference (IOR) which contains all the
information needed.
This format has four standard
representations:
a binary form, which is only used between orbs
a string form, beginning with "IOR:" which
can be used by any client or service
this form can be transformed
from and to an object reference by calling the orb operations
Object_To_String and String_To_Object
a string form, which is a corbaloc URL beginning with
"corbaloc:" which can be used by any client or service,
providing that the corresponding service has registered the
reference to the object as an initial one (for an OrbRiver service)
or into a (orb specific) location service
this form can be
transformed to an object reference by calling the orb operation
String_To_Object
a string form, which is a corbaname URL beginning with
"corbaname:" which can be used by any client or service,
providing that the corresponding service or any other entity has
registered the reference to the object in the naming service
indicated in the URL under the name indicated in the URL
this
form can be transformed to an object reference by calling the orb
operation String_To_Object
The IOR of the object which will be used to start
up the communication between two orb implementations must be stored
as a string form in an independent place (in the clipboard, in a
file, etc...) so that the other implementation can access it. Then,
operations on this object will transmit other object references, and
the inter-orb communication is bootstrapped. The first IOR can
cleverly be the root naming context of the Naming Service.
OrbRiver can interoperate with any orb able to communicate through IIOP, the TCP/IP implementation of GIOP (the General Inter-ORB Protocol). As each orb needs its own TCP port, care should be taken to allocate different TCP ports to the different orbs running on the same host. For setting the TCP port of an OrbRiver orb, see Configuration.
If another ORB implementation client needs to access
an object managed by an OrbRiver service, the latter must display the
stringified IOR of this object. This string is obtained by calling
Corba.Orb.Object_To_String with the object reference as parameter.
The client must use the corresponding inverse operation provided by
its orb to translate it into the convenient object reference.
A
new and simpler solution to this problem is to use corbaloc or
corbaname URLs. To use the former, the reference must be registered
as an initial one, to use the latter, the reference must be
registered in a Naming service.
If an OrbRiver client needs to access an object managed by another ORB implementation service, the latter must display the stringified IOR or URL of this object. This string is obtained by calling the proper operation provided by its orb to translate the object reference into a stringified IOR. The client must use Corba.Orb.String_To_Object with the stringified IOR or URL as parameter to get the convenient object reference.
Copyright
Micro Focus 2002-2014. All rights reserved.