Managing a WebLogic Enterprise Namespace


	Corporate Info \| News \| Solutions \| Products \| Partners \| Services \| Events \| Download \| How To Buy
	http://www.oracle.com/technology/documentation/index.html \| Site Map \| Search \| PDF Files \| Contact \| Glossary

WebLogic Enterprise Doc Home \| Naming \| Previous Topic \| Next Topic \| Contents \| Index

This topic includes the following sections:

Installing the CORBA Name Service

You install the CORBA Name Service when you install the WebLogic Enterprise product. For complete information about installing the WebLogic Enterprise product, see the BEA Weblogic Enterprise Installation Guide.

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 WebLogic Enterprise 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 WebLogic Enterprise domain. Listing 3-1 shows an example of the UBBCONFIG entry for the server process for the CORBA Name Service.

Listing 3-1 UBBCONFIG File Entry for CORBA Name Service

...
#
#Server process for WLE CORBA Name Service
#
	"drive:\ns\server\cns.exe
		SRVGRP = SYS_GRP
		SRVID = 6
		RESTART = N
	CLOPT = "-A -- -f drive:\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 the Administration Guide.

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 a WebLogic Enterprise Namespace

Command
Description

cns

Starts the server process for the WebLogic Enterprise namespace.

cnsbind

Binds application objects and naming context objects to the WebLogic Enterprise namespace.

cnsls

Displays the contents of a WebLogic Enterprise namespace.

cnsunbind

Removes bindings from a WebLogic Enterprise namespace.

Command	Description
cns	Starts the server process for the WebLogic Enterprise namespace.
cnsbind	Binds application objects and naming context objects to the WebLogic Enterprise namespace.
cnsls	Displays the contents of a WebLogic Enterprise namespace.
cnsunbind	Removes bindings from a WebLogic Enterprise 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:

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

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 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 Weblogic Enterprise 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 WebLogic Enterprise 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 Commands, System Processes, and MIB Reference.

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 Commands, System Processes, and MIB Reference.

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 WebLogic Enterprise Domains

Federation across multiple CORBA Name Service server processes running in different WebLogic Enterprise 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 (WLE 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 a WebLogic Enterprise application so all WebLogic Enterprise 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 WebLogic Enterprise Applications

When using the cnsls, cnsbind, and cnsunbind commands in a secure WebLogic Enterprise application, you need to obtain the PrincipalAuthenticator object for the WebLogic Enterprise domain and logon to the domain with the appropriate security information.

In order for a secure logon to occur, the WebLogic Enterprise 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 WebLogic Enterprise 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 WebLogic Enterprise 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 WebLogic Enterprise security environment, see Using Security.

Table 3-1 Commands for Managing a WebLogic Enterprise Namespace