Using the CORBA Name Service

     Previous  Next    Open TOC in new window  Open Index in new window  View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Managing an Oracle Tuxedo Namespace

This topic includes the following sections:

Note: The Oracle Tuxedo CORBA Java client and Oracle Tuxedo CORBA Java client ORB were deprecated in Tuxedo 8.1 and are no longer supported. All Oracle Tuxedo CORBA Java client and Oracle Tuxedo CORBA Java client ORB text references, associated code samples, should only be used to help implement/run third party Java ORB libraries, and for programmer reference only.
Note: Technical support for third party CORBA Java ORBs should be provided by their respective vendors. Oracle Tuxedo does not provide any technical support or documentation for third party CORBA Java ORBs.

 


Installing the CORBA Name Service

You install the CORBA Name Service when you install Oracle Tuxedo. For complete information about installing Oracle Tuxedo, see Installing the Oracle Tuxedo System.

 


Starting the Server Process for the CORBA Name Service

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 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 CORBA Name Service Reference.

Table 3-1 Commands for Managing an Oracle Tuxedo Namespace
Command
Description
cns
Starts the server process for the Oracle Tuxedo namespace.
cnsbind
Binds application objects and naming context objects to the Oracle Tuxedo namespace.
cnsls
Displays the contents of an Oracle Tuxedo namespace.
cnsunbind
Removes bindings from an Oracle Tuxedo namespace.

 


Making the Namespace Persistent

The CORBA Name Service keeps two copies of the information in a namespace. One copy is kept in-memory. Access to this copy is fast and optimized for name resolution. The other copy is optionally saved to persistent storage allowing the state and structure of the namespace to be saved and restored.

The primary goal of making a namespace persistent is to keep a current representation of the in-memory naming information maintained by the currently running instance of the namespace. By maintaining a persistent copy of the namespace, the CORBA Name Service can recreate current naming information in case the server process of the CORBA Name Service is terminated. A new instance of the server process for the CORBA Name Service can be configured to read the persistent storage file to recreate the last recorded naming information.

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.

Since the server process for the CORBA Name Service recreates the structure of the namespace from the persistent storage file at startup, the startup time is directly proportional to the size of the persistent storage file.Very large persistent storage files (on the order of hundreds of megabytes) can result in the server process for the CORBA Name Service taking several seconds or even minutes to recreate the namespace at startup.

 


Compressing the Persistent Storage File

The persistent storage file contains information about all operations affecting the in-memory copy of the namespace. Over time, the persistent storage file can contain more information than is necessary to recreate the structure and state of the current namespace. In fact, the persistent storage file can grow quite large even though the structure of the namespace stays the same size.

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.

When the server process for the CORBA Name Service is started, the compression operation performs the following:

  1. Processes the in-memory structure of the namespace.
  2. Overwrites the existing persistent storage file.
  3. Deletes all bind and rebind entries which were removed from the namespace by unbind, rebind, or destroy operations.
  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 CORBA Name Service Reference.

 


Removing Orphan NamingContext Objects

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:

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 CORBA Name Service Reference.

 


Federating the Namespace

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.

The following topics explain how to support inbound and outbound federation as well as federation with third-party name services.

Inbound Federation

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.

Listing 3-2 UBBCONFIG File Entry for an 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

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.

Listing 3-3 UBBCONFIG File Entry for an IIOP Listener/Handler That Supports Outbound Federation
#                                       
# Entry for IIOP Listener/Handler
# that supports outbound federation
#
ISL   
              SRVGRP = SYS_GRP
              SRVID  = 5
              MIN   =1
              MAX    = 1
              CLOPT   = "-A -- -n //blotto:2470 -O"

Federation Across Oracle Tuxedo Domains

Federation across multiple CORBA Name Service server processes running in different Oracle Tuxedo domains requires the use of Domain Gateways to allow for inter-domain communication. For more information about configuring a domain gateway, see the “Configuring Multiple Domains (Oracle Tuxedo System)” section in the Administration topic.

 


Managing Binding Iterators

The OMG INS specification allows the collection of outstanding binding iterators. Since binding iterators require explicit destruction by client applications, there is the chance that binding iterators will not be deleted properly.

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.

 


Using the CORBA Name Service in Secure Oracle Tuxedo Applications

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.


  Back to Top       Previous  Next