WAS v8.5 > WebSphere applications > Naming and directory > Naming
Namespace logical view
The namespace for the entire cell is federated among all servers in the cell. Every server process contains a name server. All name servers provide the same logical view of the cell namespace.
The various server roots and persistent partitions of the namespace are interconnected by a system namespace. We can use the system namespace structure to traverse to any context in a cell's namespace.
A logical view of the namespace in a multiple-server installation is shown in the following diagram.
The bindings in the preceding diagram appear with solid arrows, labeled in bold, and dashed arrows, labeled in gray. Solid arrows represent primary bindings. A primary binding is formed when the associated subcontext is created. Dashed arrows show linked bindings. A linked binding is formed when an existing context is bound under an additional name. Linked bindings are added for convenience or interoperability with previous WebSphere Application Server versions.
A cell namespace is composed of contexts which reside in servers throughout the cell. All name servers in the cell provide the same logical view of the cell namespace. A name server constructs this view at startup by reading configuration information. Each name server has its own local in-memory copy of the namespace and does not require another running server to function. There are, however, a few exceptions. Server roots for other servers are not replicated among all the servers. The respective server for a server root must be running to access that server root context.
Namespace partitions
There are five major partitions in a cell namespace:
- System namespace partition
- Server roots partition
- Cell persistent partition
- Node persistent partition
- Applications partition
- System namespace partition
- The system namespace contains a structure of contexts based on the cell topology. The system structure supports traversal to all parts of a cell namespace and to the cell root of other cells, which are configured as foreign cells. The root of this structure is the cell root. In addition to the cell root, the system structure contains a node root for each node in the cell. We can access other contexts
of interest specific to a node from the node root, such as the node persistent root and server roots for servers configured in that node.
All contexts in the system namespace are read-only. We cannot add, update, or remove any bindings.
- Server roots partition
- Each server in a cell has a server root context. A server root is specific to a particular server. We can view the server roots
for all servers in a cell as being in a transient read/write partition
of the cell namespace. System artifacts, such as EJB
homes for server applications and resources, are bound under the server root context of the associated server. A server application can also add bindings under its server root. These bindings are transient.
Therefore, the server application creates all required bindings at application startup, so they exist anytime the application is running.
Server-scoped configured name bindings are relative to a server's server root.
- Cell persistent partition
- The root context of the cell persistent partition is the cell persistent root. A binding created under the cell persistent root is saved as part of the cell configuration and continues to exist until it is explicitly removed. Applications that need to create additional persistent bindings of objects generally associated with the cell can bind these objects under the cell persistent root.
It is important to note the cell persistent area is not designed for transient, rapidly changing bindings. The bindings are more static in nature, such as part of an application setup or configuration, and are not created at run time.
Cell-scoped configured name bindings are relative to a cell's cell persistent root.
- Node persistent partition
- The node persistent partition is similar to the cell partition
except that each node has its own node persistent root. A binding created under a node persistent root is saved as part of that node configuration and continues to exist until it is explicitly removed.
Applications that need to create additional persistent bindings of objects associated with a specific node can bind those objects under that particular node's node persistent root. As with the cell persistent area, it is important to note the node persistent area is not designed for transient, rapidly changing bindings. These bindings are more static in nature, such as part of an application setup or configuration, and are not created at run time.
Node-scoped configured name bindings are relative to a node's node persistent root.
- Applications partition
- The Java EE 6 specification introduces module, application, and global namespaces. Java URL JNDI names that have the prefixes java:module, java:app,
and java:global can access the respective namespaces.
In some situations, the namespaces are only locally accessible, and in other situations the namespaces are remotely accessible.
The applications partition contains namespaces that are remotely accessible.
The root of the java:global namespace is the applications root context. The roots of other namespaces are under the com.ibm.ws.AppNameSpaces subcontext. For example, the java:app root context for the application, MyApp, is bound with the name, MyApp/root relative to com.ibm.ws.AppNameSpaces. Module and component namespaces are only accessible remotely when the module is a client module in a server-deployed mode or in a federated mode. For example, the java:module root context for the server-deployed client module MyClientModule in the application MyApp is bound with the name MyApp/MyClientModule/root relative to com.ibm.ws.AppNameSpaces. The component namespace, which contains comp/env bindings, for that same module is bound under MyApp/MyClientModule/ClientComponent/root relative to com.ibm.ws.AppNameSpaces.
Application resources–such as EJB references, resource references, and environment entries–with java:global names are bound into the java:global namespace when the defining application is installed. The application does not need to be running for those name bindings to be available to other applications.
Related concepts:
Naming
Configured name bindings
Configuration documents
Related
Use naming
Reference:
Lookup names support in deployment descriptors and thin clients
Initial context support