You install the CORBA Name Service when you install Oracle Tuxedo. For complete information about installing Oracle Tuxedo, see Installing the Oracle Tuxedo System.To start the server process for the CORBA Name Service, you need to define the server process in the UBBCONFIG file for your Oracle Tuxedo CORBA application. Use the cns command to start the server process for the CORBA Name Service. List the cns command-line options after the CLOPT parameter in the UBBCONFIG file. Note there can be only one CORBA Name Service server process running per Oracle Tuxedo domain. Listing 3‑1 is an example of the UBBCONFIG entry for the server process for the CORBA Name Service.Listing 3‑1 UBBCONFIG File Entry for the CORBA Name Service...
#
#Server process for Oracle Tuxedo CORBA Name Service
#
cns
SRVGRP = SYS_GRP
SRVID = 6
RESTART = N
CLOPT = "-A -- -f C:\cnsroot.dat -M 0"For a complete description of the cns command and its options, see Chapter 2, “CORBA Name Service Reference.” For information about creating a configuration file, see Setting Up an Oracle Tuxedo Application in the Oracle Tuxedo online documentation.Once the server process for the CORBA Name Service is started, you can use the commands listed in Table 3‑1 to display the contents of the namespace and manage objects in the namespace. For a complete description of the commands and their options, see Chapter 2, “CORBA Name Service Reference.”
To create a persistence copy of the namespace and store the copy to a file, specify the -p option of the cns command when starting the server process for the CORBA Name Service. The CORBA Name Service creates a persistent storage file with the specified location and name.If the persistent storage file specified by the -p option already exists, the file is opened and processed. A backup of the persistent storage file is always made prior to the startup of the server process for the CORBA Name Service. The name of the backup copy of the persistent storage file is filename.BAK. If you want to reuse the name of the persistent storage file, you must delete or move the existing file and then restart the server process for the CORBA Name Service.If the persistent storage file is successfully created, an entry for the file is written to the ULOG file. The entry indicates the directory location and name of the file, whether or not the file was newly created, and the mechanism used to determine the name of the file (for example, specified, environmental, or default). If an error occurs when creating the persistent storage file, an entry is written to the ULOG file indicating the type of error that occurred.The CORBA Name Service allows you to compress the persistent storage file to remove unneeded information. The -c option of the cns command controls compression of the persistent storage file. The compression option processes the current information to produce a new compressed persistent storage file.
4. Removes all dangling bindings. Dangling bindings are bindings left in the namespace after the object the binding is associated with is deleted from the namespace. Dangling bindings occur when a CosNaming::NamingContext::destroy() method is performed on a naming context without the naming context being unbound from its parent context.The -c option can only be used if the -p option of the cns command is specified. For a complete description of the -c option of the cns command, see Chapter 2, “CORBA Name Service Reference.”An orphan context is a context that is not bound to any other context. The context may have never been bound or it may have been bound and the binding was destroyed either explicitly or as the result of a rebind. In the CORBA Name Service, orphan NamingContext objects are created in one of the following ways:
• Using the CosNaming::NamingContext::new_context method to create a new NamingContext object but never binding the new NamingContext object to the namespace.
• Using the CosNaming::NamingContext::rebind() or CosNaming::NamingContext::unbind() methods to unbind the NamingContext object from their last parent NamingContext object but never destroying the NamingContext object.Client applications and other namespaces federated to the NamingContext object can perform operations on orphan NamingContext objects as long as they maintain the object reference to the orphan NamingContext object.The current implementation of the namespace maintains the orphan NamingContext objects in a special LostandFoundContext object.Use the -d option of the cns command to delete orphan NamingContext objects from the namespace. The -d option unbinds and destroys all NamingContext objects identified as orphaned.The -d option can only be used if the -p option of the cns command is specified. For a complete description of the -d option of the cns command, see Chapter 2, “CORBA Name Service Reference.”The CORBA Name Service supports the concept of a federated namespace which means elements of a logical namespace may reside on multiple, disparate, and remote machines. In a federated namespace, a NamingContext object can be bound to one namespace using an object reference to a NamingContext object maintained by another namespace. The CORBA Name Service supports federation with implementations of the CORBA Name Service running on other machines as well as third-party name services. In order for the CORBA Name Service to federate with a third-party name service, the third-party name service must support the naming formats specified in the Object Management Group (OMG) Interoperable Name Service (INS) specification.Inbound federation is the ability to bind a NamingContext object which exists in a local Oracle Tuxedo namespace into a namespace on a remote name service. Once the namespaces are federated, the remote name service can perform operations on NamingContext objects in a the Oracle Tuxedo namespace. Inbound federation with a third-party name service is done using the Internet Inter-Orb Protocol (IIOP). Therefore, the IIOP Listener/Handler for the CORBA Name Service must be configured to support unoffical IIOP connections.To enable the unofficial connections on the IIOP Listener/Handler, use the -C parameter of the ISL command. The -C parameter determines how the IIOP Listener/Handler will behave when unofficial connections are made to it. To use inbound federation, specify the warn or none values for the -C parameter. A value of warn causes the IIOP Listener/Handler to log a message to the user log exception when an unofficial connection is detected; no exception will be raised. A value of none causes the IIOP Listener/Handler to ignore unofficial connections. For more information about the ISL command, see the Oracle Tuxedo Command Reference in the Oracle Tuxedo online documentation.Listing 3‑2 shows an example of the UBBCONFIG entry for the IIOP Listener/Handler that supports inbound federation.#
# Entry to start IIOP Listener/Handler
# that supports inbound federation
ISL
SRVGRP = SYS_GRP
SRVID = 5
MIN = 1
MAX = 1
CLOPT = "-A -- -n //blotto:2470 –C none"Outbound federation is the ability to bind a NamingContext object which exists in a remote name service into the namespace of a CORBA Name Service. Operations can then be performed on this NamingContext object using the CORBA Name Service. Outbound federation with a third-party name service is done using IIOP. Therefore, the IIOP Listener/Handler for the CORBA Name Service must be configured to support outbound federation.To enable outbound federation on the IIOP Listener/Handler, use the -O parameter of the ISL command. The -O parameter causes the IIOP Listener to allow outbound IIOP invocations to objects located in server applications not connected to a IIOP Handler. For more information about the ISL command, see the Oracle Tuxedo Command Reference in the Oracle Tuxedo online documentation.Listing 3‑3 shows an example of the UBBCONFIG entry for the IIOP Listener/Handler that supports outbound federation.ISL
SRVGRP = SYS_GRP
SRVID = 5
MIN =1
MAX = 1
CLOPT = "-A -- -n //blotto:2470 -O"To minimize the possibility that the CORBA Name Service will run out of resources due to a large number of unused binding iterators, use the -M option of the cns command to set the maximum number of binding iterators in the name service. Once the limit has been reached, requests for new binding iterators may result in the destruction of outstanding binding iterators. The CORBA Name Service uses a least-recently-used algorithm to select which binding iterators are deleted.If the server process for the CORBA Name Service is started with the -M option, the CORBA Name Service may destroy a binding iterator that is currently being used by an Oracle Tuxedo CORBA application so all Oracle Tuxedo applications need to be able to handle the CORBA::OBJECT_NOT_EXIST system exception when invoking on binding iterators.When using the cnsls, cnsbind, and cnsunbind commands in a secure Oracle Tuxedo CORBA application, you need to obtain the PrincipalAuthenticator object for the Oracle Tuxedo domain and log on to the domain with the appropriate security information.In order for a secure logon to occur, the Oracle Tuxedo domain must be configured with a security level of TOBJ_SYSAUTH or TOBJ_APPAUTH. The username for the cnsls, cnsbind, and cnsunbind commands is cnsutils. You need to use the tpusradd command to create a user named cnsutils. Depending on the Security level specified for the Oracle Tuxedo domain, the user password and/or the domain password may be defined in the UBBCONFIG file in the USER_AUTH and APP_PW environment variables. If these environment variables are not set and the Oracle Tuxedo domain has a security level of TOBJ_SYSAUTH or TOBJ_APPAUTH, the cnsls, cnsbind, and cnsunbind commands will prompt for a password.For more information about security levels and defining users in the Oracle Tuxedo security environment, see Using Security in CORBA Applications in the Oracle Tuxedo online documentation.