Instead of creating name space bindings from a program, you can configure name space bindings using the administrative console. Name servers add these configured bindings to the name space view by reading the configuration data for the bindings. Configured bindings are created each time a server starts, even when the binding is created in a transient partition of the name space. One major use of configured bindings is to provide fixed qualified names for server application objects. Assemble and deploy your application onto an application server. If the application is a client to an application running in another server process, specify qualified jndiName values for the other application's server objects during assembly or deployment. For more information on qualified names, refer to Lookup names support in deployment descriptors and thin clients.
When you configure a name space binding, you create a qualified fixed name for a server object. A fixed name does not change if the object is moved to another server. A qualified fixed name with a cell scope has the form:
cell/persistent/fixedName
where fixedName is an arbitrary fixed name.
You can configure name space bindings, and thus qualified fixed names, for the following objects:
To view or configure a name space binding for an object of a deployed application, complete the following:
In the administrative console, click Environment > Naming > Name Space Bindings.
The scope determines where in the name space the name space binding is created. It also affects which name servers contain the binding in the name space that they manage. Regardless of the scope, a name space binding is accessible from all name servers in the cell. However, the scope can affect whether the lookup can be resolved locally by a name server or whether the name server must make a remote call to another name server to resolve the binding.
Only name space bindings created with the selected scope are visible in the collection table on the page. By changing the scope, you can see and create bindings in other scopes.
If you are creating a new name space binding, refer to the table below as a guide in selecting a scope:
| Scope | Description |
|---|---|
| Cell | Cell-scoped bindings are created under the cell persistent
root context. Select Cell if the name space binding is not specific
to any particular node or server, or if you do not want the binding to be
associated with any specific node,
cluster or server. For example, you can use cell-scoped bindings to create
fixed qualified names for enterprise beans. Fixed qualified names do not have
any node, cluster or server
names embedded within them.
Cell-scoped bindings are created in the deployment manager process, and all node agent and application server processes, in the cell. Therefore all name servers in the cell can resolve those bindings locally. No remote invocations to other name servers are necessary to resolve the bindings. |
| Node | Node-scoped bindings are created under the node persistent
root context for the selected node. Select Node if the name space binding
is specific to a particular node, or if you want the binding to be associated
with a specific node.
Node-scoped bindings are created in the node agent and all application server processes in the selected node. Therefore, all name servers in the node can resolve those bindings locally. No remote invocations to other name servers are necessary to resolve the bindings. However, name servers in other nodes must make remote calls to the node agent in the selected node in order to resolve the bindings. For example, in order for a name server running in node node1 to resolve the name cell/nodes/node2/persistent/nodeScopedConfiguredBinding, the name server must make a remote call to the node agent running in node2. Any name server running in node2 can resolve that name without invoking any other name servers. |
| Server | Server-scoped bindings are created under the server
root context for the selected server. Select Server if a binding is
to be used only by clients of an application running on a particular server,
or if you want to configure a binding with the same name on different servers
which resolve to different objects. Note that two servers can have configured
bindings with the same name but resolve to different objects.
Server-scoped bindings are created in the process of the selected application server. Therefore, the name server running in the selected application server can resolve those bindings locally. No remote invocations to other name servers are necessary to resolve the bindings. However, all other name servers in the cell must make remote calls to the selected server in order to resolve the bindings. For example, in order for the name server running in server1 in node node1 to resolve the name cell/nodes/node1/servers/server2/serverScopedConfiguredBinding, it must make a remote call to server2 in node1. Only the name server in server2 in node1 can resolve that name without invoking any other name servers. |
| Cluster | Cluster-scoped bindings are created under the server
root context for all members in the selected cluster. Select Cluster if
the name space binding is specific to a particular cluster, or if you want
the binding to be associated with a specific cluster.
Cluster-scoped bindings are created in all member processes of the selected cluster. Therefore, the name server running in each member of the selected cluster can resolve those bindings locally. No remote invocations to other name servers are necessary to resolve the bindings. However, all other name servers in the cell must make remote calls to the node agent in the selected node in order to resolve the bindings. For example, in order for a name server running in any member of cluster1 to resolve the name cell/clusters/cluster2/clusterScopedConfiguredBinding, it must make a remote call to some member in cluster2. Only the name servers in cluster2 members can resolve that name without invoking any other name servers. Server-scoped bindings in cluster members override cluster-scoped bindings with the same binding name. However, cluster members generally should all be configured identically, and server-scoped bindings should not be required for individual cluster members. |
On the Name Space Bindings page, click New.
The name space binding can be for a constant string value, an EJB home, a CORBA CosNaming NamingContext or CORBA leaf node object, or an object that you can look up indirectly using JNDI.
For property descriptions, refer to the following:
This step applies to indirect lookup bindings only.
The name of the new binding is displayed in the collection table on the Name Space Bindings page.