67 lines
6.0 KiB
HTML
67 lines
6.0 KiB
HTML
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||
|
|
<html>
|
||
|
|
<head>
|
||
|
|
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
|
||
|
|
<LINK rel="stylesheet" type="text/css" href="../../../rzahg/ic.css">
|
||
|
|
|
||
|
|
<title>Name space logical view</title>
|
||
|
|
</head>
|
||
|
|
|
||
|
|
<BODY>
|
||
|
|
<!-- Java sync-link -->
|
||
|
|
<SCRIPT LANGUAGE="Javascript" SRC="../../../rzahg/synch.js" TYPE="text/javascript"></SCRIPT>
|
||
|
|
|
||
|
|
<h5><a name="jndinsview"></a>Name space logical view</h5>
|
||
|
|
|
||
|
|
<p>The name space for the entire cell is federated among all servers in the cell. Every server process, including the node agents, and application servers, contains a name server. All name servers provide the same logical view of the cell name space. The various server roots and persistent partitions of the name space are interconnected by a system name space. You can use the system name space structure to traverse to any context in a the cell's name space. A logical view of the name space is shown in this diagram.</p>
|
||
|
|
<p><img src="rzaiz587.gif" width="567" height="403" alt="" border="0"></p>
|
||
|
|
<p><strong>Note:</strong> Express has only one cell, node, and server.</p>
|
||
|
|
|
||
|
|
<p>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.</p>
|
||
|
|
|
||
|
|
<p>A cell name space 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 name space. A name server constructs this view at startup by reading configuration information. Each name server has its own local in-memory copy of the name space 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. </p>
|
||
|
|
|
||
|
|
<p><strong>Name space partitions</strong></p>
|
||
|
|
|
||
|
|
<p>There are four major partitions in a cell name space:</p>
|
||
|
|
<p>
|
||
|
|
<ul>
|
||
|
|
<li><a href="#system">System name space partition</a></li>
|
||
|
|
<li><a href="#server">Server roots partition</a></li>
|
||
|
|
<li><a href="#cell">Cell persistent partition</a></li>
|
||
|
|
<li><a href="#node">Node persistent partition</a></li>
|
||
|
|
</ul>
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<a name="system"></a>
|
||
|
|
<p><strong>System name space partition</strong></p>
|
||
|
|
|
||
|
|
<p>The system name space contains a structure of contexts based on the cell topology. The system structure supports traversal to all parts of a cell name space 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. You 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.</p>
|
||
|
|
|
||
|
|
<p>All contexts in the system name space are read-only. You cannot add, update, or remove any bindings.</p>
|
||
|
|
|
||
|
|
<a name="server"></a>
|
||
|
|
<p><strong>Server roots partition</strong></p>
|
||
|
|
|
||
|
|
<p>Each server in a cell has a server root context. A server root is specific to a particular server. You can view the server roots for all servers in a cell as being in a transient read/write partition of the cell name space. System artifacts 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.</p>
|
||
|
|
|
||
|
|
<!--<p>A server cluster is composed of many servers that are logically equivalent. Each member of the cluster has its own server root. These server roots are not replicated across the cluster. In other words, adding a binding to the server root of one member does not propagate it to the server roots of the other cluster members. To maintain the same view across the cluster, you should create all user bindings under the server root by the server application at application startup so that the bindings are present under the server root of each cluster member.</p>-->
|
||
|
|
|
||
|
|
<p>Server-scoped bindings are relative to a server's server root.</p>
|
||
|
|
|
||
|
|
<a name="cell"></a>
|
||
|
|
<p><strong>Cell persistent partition</strong></p>
|
||
|
|
|
||
|
|
<p>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. </p>
|
||
|
|
|
||
|
|
<p>It is important to note that 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.</p>
|
||
|
|
|
||
|
|
<a name="node"></a>
|
||
|
|
<p><strong>Node persistent partition</strong></p>
|
||
|
|
|
||
|
|
<p>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.</p>
|
||
|
|
|
||
|
|
<p>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 that 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.</p>
|
||
|
|
|
||
|
|
</body>
|
||
|
|
</html>
|