CORBA 2.6.1 Programmer's Guide for C++

Appendix B. Object References
Appendix B. Object References
Obtaining Object References
Content of Object References
Addresses
NSDOM_GCF_IOP::Profile_Tag Addresses
NSDOM_GFS_IOP::Profile_Tag Addresses
IOP::TAG_INTERNET_IOP Addresses
Configured Versus Actual TCP/IP Addresses and TCP/IPv6 Addresses
Interoperable Object References for Objects in a Server Pool
IORs for Stateless Objects in a Server Pool
IORs for Stateful Objects in a Server Pool
This appendix contains reference information about object references that some programmers may find useful as background information, or
when debugging. Object references cannot be manipulated directly, but they are manipulated indirectly when you change configuration settings.
To invoke operations on a distributed object, a NonStop CORBA client uses an Interoperable Object Reference (IOR). IORs are created by
servers. An object reference is communicated to the client and its contents are known by the client.
A client can treat distributed objects just as it does local objects. A client need not be concerned with the content of an IOR, but the client must
know how to find an IOR and how to release one after using it.
An IOR contains protocol-specific information that NonStop CORBA uses to facilitate communication between the method invoker (client
process) and the method implementer (an object running in a server process). NonStop CORBA automatically generates object references on
behalf of the server process. If the server process is configured to use more than one protocol (for instance, TS/MP and file system), the object
reference will contain protocol-specific information for each protocol. The protocol-specific information tells the NonStop CORBA runtime:
How to find the server process when using the specific protocol
How to find the target object instance within the server process
Obtaining Object References
NonStop CORBA obtains server IORs at three points:
Explicitly, when the application calls CORBA::Object::object_to_string(). This action is usually done when an IOR must be "hand
delivered" to a client, for example, during initial testing of a system when the Naming Service is being avoided.
Implicitly, when an object is returned as an out parameter or result for an operation. An example is found in the Naming Service
resolve() operation.
Implicitly, when an object is passed as an in parameter to an operation. An example is found in the Bank sample program bank_main.cpp
when it calls the Naming Service rebind() operation.
Content of Object References
The content of a NonStop CORBA IOR is determined by the servant's POA policies, the server protocols enabled in the configuration database,
and the actual deployment of the server processes.
NonStop CORBA IORs adhere to the CORBA IOR rules except that NonStop CORBA does not recognize the
IOP::TAG_MULTIPLE_COMPONENTS.
NonStop CORBA recognizes three profile tags:
NSDOM_GCF_IOP::Profile_Tag (12346)
NSDOM_GFS_IOP::Profile_Tag (12345)
IOP::TAG_INTERNET_IOP (0)
If more than one protocol is enabled for a server, multiple profiles will exist in the IOR. Multiple profiles are ordered based on desirability from the
server's perspective, in the order shown above.