11.4 Distributed CosNaming
One of the advantages of the distributed nature of CosNaming in WAS is that it removes the bottleneck of having a single name server for all naming lookups. Each WebSphere process, such as deployment manager, node agent and appserver, hosts its own ORB, NameService and local name space. Lookups are made by accessing the NameService in the most convenient process. They are not bottlenecked through a single server process in the cell.
The WAS naming architecture uses CORBA CosNaming as its foundation. The CosNaming architecture has been changed to support a distributed and federated collection of CosNaming servers. Each deployment manager, node agent, and appserver is a CosNaming server and is responsible for managing the names of the objects that are bound locally. Objects are bound into the local context. Lookups start in the local process and end in the process where the target object is located. This reduces the dependency of the WAS network on a single name server for all lookups.
A single, logical name space exists across the cell. The separate name spaces of each server process are linked and federated via context links in the cell name space. It is possible to navigate to specific subcontexts, as every server cluster and non-clustered server has its own context stored in a level of the cell name space.
The contents of the federated name space are mostly transient, built from configuration data read from the XML configuration files on the startup of each server process. Persistent roots are provided at the cell and node level of the name space to provide locations where objects can be persistently bound. These bindings are persisted to XML files on the file system.
Each separate server process has its own bootstrap port, thereby reducing bottlenecks.
