Configure namespace bindings for WebSphere Java EE applications

Configure namespace bindings

Instead of creating namespace bindings from a program, we can configure namespace bindings using the administrative console. Name servers add these configured bindings to the namespace 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 namespace. One major use of configured bindings is to provide fixed qualified names for server application objects.

Assemble and deploy the 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 server objects of the other application during assembly or deployment. For more information on qualified names, refer to the topic on lookup names support in deployment descriptors and thin clients.

A deployed application requires qualified fixed names if the application is accessed by thin client applications or by Java EE client applications or server applications running in another server process.

When we configure a namespace binding, we 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 following form:
cell/persistent/fixedName
The fixedName is an arbitrary fixed name.

We can configure namespace bindings, and thus qualified fixed names, for the following objects:

A string constant value
An enterprise bean (EJB) home installed on a server in the cell
A CORBA object available from a CosNaming name server
An object bound in a WebSphere Application Server namespace that is accessible using a JNDI indirect lookup

We do not need to restart any processes in order for their namespace to reflect new namespace bindings or changes to existing namespace bindings. Namespace updates occur immediately after we save the configuration changes. On managed nodes, the namespace updates occur when the configuration changes are synchronized to the node.
To view or configure a namespace binding for an object of a deployed application, complete the following:

Tasks

Go to the Name space bindings page.
In the administrative console, click Environment > Naming > Name space bindings.

Select the desired scope.
The scope determines where in the namespace binding is created. It also affects which name servers contain the binding in the namespace that they manage. Regardless of the scope, a namespace 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 namespace bindings created with the selected scope are visible in the collection table on the page. By changing the scope, we can see and create bindings in other scopes.

Select a scope.
For a new namespace binding, refer to the following table 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 namespace binding is not specific to any particular node or server, or if we do not want the binding to be associated with any specific node, cluster or server. For example, we 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 all processes in the cell that contain a name server, specifically in administrative agent, deployment manager, node agent, and application server processes. 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 namespace binding is specific to a particular node, or if we 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 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 namespace binding is specific to a particular cluster, or if we 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.

Click Apply.

Create a new namespace binding.

Open the New Name Space Binding wizard.
On the Name space bindings page, click New.

On the Specify binding type page, select the binding type.
The namespace binding can be for a constant string value, an EJB home, a CORBA CosNaming NamingContext or CORBA leaf node object, or an object that we can look up indirectly using JNDI.

On the Specify basic properties page, specify the binding identifier and other properties for the binding.
For property descriptions, refer to the following:

String binding settings
EJB binding settings
CORBA object binding settings
Indirect lookup binding settings

Optional: On the Other context properties page, specify new properties to be passed to the javax.naming.InitialContext constructor.
This step applies to indirect lookup bindings only.

On the Summary page, verify the settings and click Finish.
The name of the new binding is displayed in the collection table on the Name space bindings page.
Optional: Edit a previously created binding.

From the collection table on the Name space bindings page, click the name of the binding to edit.
Edit the binding properties as desired. Step 3(c) provides links to property descriptions.
Click OK.

Cell-scoped bindings are created under the cell persistent root context. Node-scoped bindings are created under the node persistent root context for the specified node. Server-scoped bindings are created under the server root context for the selected server. Cluster-scoped bindings are created under the server root context for each member of the selected cluster.

Subtopics

Name space binding collection
Configure a name binding of an EJB, a CORBA CosNaming NamingContext, a CORBA leaf node object, an object that we can look up using JNDI, or a constant string value.
Specify binding type settings
Select the type of namespace binding that we want.
String binding settings
View or configure a string binding.
EJB binding settings
Configure a new enterprise bean (EJB) binding, or to view or edit an existing EJB binding.
CORBA object binding settings
Configure a new name binding of a CORBA object binding, or to view or edit an existing CORBA object binding.
Indirect lookup binding settings
Configure a new indirect lookup name binding, or to view or edit an existing indirect lookup binding.
Other context properties settings
Specify properties to be passed to the javax.naming.InitialContext constructor for an indirect JNDI lookup name binding. Completion of this page is optional. The properties are in addition to the basic properties specified for an indirect namespace binding.

Related:

Naming
Namespace federation
Configured name bindings
Install enterprise application files with the console
Lookup names support in deployment descriptors and thin clients

Scope	Description
Cell	Cell-scoped bindings are created under the cell persistent root context. Select Cell if the namespace binding is not specific to any particular node or server, or if we do not want the binding to be associated with any specific node, cluster or server. For example, we 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 all processes in the cell that contain a name server, specifically in administrative agent, deployment manager, node agent, and application server processes. 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 namespace binding is specific to a particular node, or if we 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 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 namespace binding is specific to a particular cluster, or if we 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.