Creating Object References
Content of Object References
Object Keys
Configured Versus Actual TCP Addresses
Interoperable Object References for Objects in a Server Pool
This appendix provides some technical details that might be useful in understanding how Interoperable Object References (IORs) are created and the information that they contain.
To invoke methods on a distributed object, a NonStop DOM client uses an IOR, as defined by the OMG document Universal Networked Objects. IORs are created by servers. IORs are transparent to clients. The type of object reference for an object depends on class-design decisions such as the strategy for linking entity objects with external entities such as database records.
An object reference is communicated to the client and its contents are known by the client. However the object key information contained in the object reference is opaque to the client but is used by the server.
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 DOM uses to facilitate communication between the method invoker (client process) and the method implementor (an object running in a server process). By default, NonStop DOM automatically generates object references on behalf of the server process. If the server process is configured to use more than one protocol (for instance, Pathway and the file system), the object reference will contain protocol-specific information for each protocol. The protocol-specific information tells:
NonStop DOM generates server IORs at three points:
CORBA::Object::object_to_string( )
This is usually done when an IOR must be "hand delivered" to a client, for example, during initial testing of a system when complexities of Name Service interaction are being avoided.
out parameter or result for an operation.
An example of this is found in the Name Service resolve( ) operation.
in parameter to an operation.
An example of this is found in the samples/bank/server/bank_main.cpp when it calls the Name Service rebind( ) operation.
The content of a NonStop DOM IOR is determined by the servant's POA policies, the server protocols enabled via cfgmgt and the actual deployment of the server process(es). See the Administration Guide topic Using the Configuration Management Tool for a discussion of cfgmgt.
NonStop DOM IORs adhere to the CORBA IOR rules (see CORBA v2.1, section 10.6.2), except that NonStop DOM does not recognize the IOP::TAG_MULTIPLE_COMPONENTS.
NonStop DOM recognizes three profile tags:
IOP::TAG_INTERNET_IOP (0)
NSDOM_GFS_IOP::Profile_Tag
NSDOM_GCF_IOP::Profile_Tag
All three profiles contain version, address, and object key fields. If more than one protocol is enabled for a server, there will be multiple profiles in the IOR. Multiple profiles are ordered based on desirability from the client's perspective, as follows, first to last:
NSDOM_GCF_IOP::Profile_Tag
NSDOM_GFS_IOP::Profile_Tag
IOP::TAG_INTERNET_IOP
Be aware that if a server is configured to use Comm Servers (tcp_server true, use_comm_server), one or both of tsmp_server and fs_server must also be present. Otherwise, the Comm Server cannot relay requests to the target server.
Object keys are the same for all three types of profile. The object key is opaque outside of NonStop DOM. Roughly, it contains the server's profile, repository Id, POA policy mask, and (tcp_server true, use_comm_server true). The object key is a sequence of Relay Profiles that contain addressing used by the Comm Server for relaying individual requests to the target server (that is, each request does not contain an IOR; rather the object key is the only server-supplied data in individual requests).
When a server (see the note below) is configured to enable IIOP (tcp_server true), this profile will be added to IORs generated for objects within that server. NonStop DOM supports the IIOP profile defined by CORBA (see CORBA v2.1, section 12.7.2) with the exception that NonStop DOM does not support IIOP::ProfileBody_1_1. The content of the host, port, and object_key fields are of interest here.
The host and port fields contain an IP address in dot-decimal form and the port that is being listened on. Which IP address and port is dependent on server configuration and servant POA Lifecycle policy:
If the server is configured with use_comm_server or the servant's POA has a Persistent Lifecycle policy, these fields will contain the LSD's actual host name and port number (see Configured Versus Actual TCP Addresses. The result is that attempts to connect to such servers will first reach the LSD. See the Administration Guide The Architecture of NonStop DOM for a discussion of LSD behaviour.
If the server is configured as a "direct" TCP server (that is, tcp_server true, but not use_comm_server), and the servant's POA has the Transient Lifecycle policy, the host and port fields will contain the server's actual TCP host name and port number (see Configured Versus Actual TCP Addresses). Clients' attempts to contact such a server will connect directly to the server, as opposed to contacting the LSD first.
When a server (see note below) is configured to enable GIOP over the Guardian File System (fs_server true), the profile address will be set to a fully qualified Guardian process name. NonStop DOM clients connect using FILE_OPEN_ to the process name, qualified by the #NSDOMFS "subdevice".
When a server is configured to enable GIOP over TS/MP (tsmp_server true, If the server support transient objects, too, it will also be configured with fs_server true. <pathmon-process-name>, server_class <server-class>), the profile address will contain <pathmon-process-name> and <server-class>. NonStop DOM clients will use this profile when the IOR's object_key was generated by NonStop DOM, and has a Persistent Lifecycle POA policy.
Note: Server is intentionally ambiguous in the discussion above. When deployed as a server pool, server refers to all the processes in that pool. Otherwise, server refers to a single process.
When configuring "direct" tcp servers, the host_name field can be entered in name-form rather than the dot-decimal form. Further, since a host-name can map to more than one TCP process, the host-name may be ambiguous. This ambiguity is resolved by using the tcp_process field.
Also, the port_number field can be set to 0, allowing TCP to pick a port as shown here:
cfgmgt> entity xyz_service@ORB tcp_server true tcp_process $ztc1 host_name oss2.tandem.com port_number 0 |
When building a NonStop DOM IOP::TAG_INTERNET_IOP profile, the profile's host field must be in dot-decimal form to avoid having to export DNS/host-file configuration to every client. Also, the port field must have the actual port number selected by TCP if it was configured as 0.
This is accomplished by the server writing its actual TCP address to the configuration database upon successfully performing a socket-listen (the listen occurs during the CORBA::ORB::ORB_init( ) method invocation). Each time a direct TCP server runs, it will generate an actual_tcp_address entity. This record shows up as <profile>@actual_tcp_address in the configuration database. To continue with the example configuration above, after running the xyz server (and it calls ORB_init( ) method), you would be able to see this record using cfgmgt:
cfgmgt> entity xyz_service@actual_tcp_address host_name 204.160.16.38 port_number 1342 |
Each time the xyz server is run, you would expect to see a new xyz_service@actual_tcp_address entity. The host_name would not change, but since TCP is picking xyz's port_number, that field should have a new value each time.
This subtopic addresses two distinct types of server pool objects--stateless and stateful.
A stateless request (that is, a method invocation for a stateless object) can go to any free server process within a server pool.
The list below explains how NonStop DOM creates and uses object references for stateless objects. In this scenario, the client can be local or remote with respect to the server pool. If the client is remote, a Comm Server process obtains the link with the server pool on behalf of the client.
This behavior is similar to the CORBA "process-per-request" scenario. Because NonStop DOM establishes a new NonStop TS/MP link to process each request, load balancing occurs at the time of the request.
A stateful request (that is, a method invocation for a stateful object) must always go to the process where the object was created. Therefore, NonStop DOM generates a reference for a stateful object.
The list below explains how NonStop DOM creates and uses object references for stateful objects. The client can be local or remote with respect to the server pool. If the client is local, a Comm Server process obtains the link with the server pool on behalf of the client.
Once a stateful object is created, all method invocations go to the same server process rather than to the least busy server process in the server pool. However, the method request to create the stateful object itself is typically issued to a stateless object (a factory), and that request is sent to the least busy server in the server pool. This approach tends to spread stateful objects among processes and therefore to provide a level of load balancing across the server pool.
See the NonStop DOM Administration Guide topic NonStop TS/MP Process Management for information about setting NonStop TS/MP configuration variables (such as DELETEDELAY and MAXLINKS) for server pools that host stateful objects.