Entering content frame

Background documentation Naming System Architecture Locate the document in its SAP Library structure

Naming System Architecture

This graphic is explained in the accompanying text
 


The graphic above shows the different layers of the naming system architecture. The first one is the client source, which uses the JNDI API to get InitialContext object. At JNDI Registry Service startup, a new instance of com.sap.engine.system.InitialContextFactoryBuilderProxy is set as a default factory builder in the javax.naming.spi.NamingManager. The NamingManager uses it to get a new instance of the InitialContextFactory specified by the client. The getInitialContext method of the factory returns an instance of a ClientContext or OffsetClientContext, depending on the environment properties used. The OffsetClientContext is used only by application clients running on the same server where the JNDI Registry Service is used. It is a ClientContext ( OffsetClientContext extends ClientContext), in which all operations are performed with names formed with a certain prefix, which depends on the application settings.

A ClientContext instance is used by all other clients (remote clients, services, applications running on a different server node). The ClientContext class represents the client side implementation of the naming context operations. It keeps an instance of:

·        the ServerContextInface ( ServerContextImpl, if the client is running on the server, or ServerContextInface_Stub, if the client is a remote one), which represents the server side implementation of the naming context operations.

·        a hash map called LROTable (which contains all non-serializable objects), against the whole path of contexts (from the root context of the JNDI Registry Service to the context in which the object has to be placed), plus the name of the object itself.

In the ClientContext, every object to be bound is serialized and passed to the ServerContextImpl, where checks are made for the correctness and type (local or replicated) of the operation, and the object is placed in the storage. The ServerContextImpl is also connected with the naming cache. During every lookup operation, the name is first looked up from the cache and then in the repository. The CacheCommunicatorImpl is registered as a message listener. It performs the communication among the JNDI Registry services running on different server processes in cluster. It is used to notify the cluster about the changes in cache that which concern the global objects, and to replicate the global objects within the cluster.

 

 

Leaving content frame