JNDI Registry Service  

 

The JNDI Registry Service is a connected set of contexts of the same type performing naming-related operations. In addition to all common naming functionality, the JNDI Registry Service provides some specific features.

Features

Information collection

The JNDI Registry Service stores the data in a nonpersistent storage. Stopping the AS Java ensures that all stored objects will be removed from the naming system. After restarting the AS Java, the objects have to be rebound.

Tree-like structure

The naming contexts and bound objects are arranged in a hierarchy. The hierarchical structure ensures better organization of information. In every context, bindings or other contexts called subcontexts can be placed. The client gets an abstraction called a “root context” as a result of the get InitialContext operation. The root context is the starting point for all operations in the naming system.

Security

The JNDI Registry Service uses the SAP AS Java Security Service to ensure maximum server security. User authentication is performed during theget InitialContext operation. Depending on the permissions the users have, they can get an initial context and perform all operations; perform a lookup operation only; or they will not be able to get an initial context object at all.

The naming system uses the Security Provider Service for authentication when obtaining an initial context. The following security roles are available:

jndi_get_initial_context – this security role is checked in the getInitialContext operation. If users who want a new initial context do not have permission to get it, an exception is thrown. The default user group mapped to this role is All.

jndi_all_operations – this security role is checked after the jndi_get_initial_context role.If the client is mapped to this role, it gets an initial context and permission to perform all naming operations in this context. Otherwise, the client gets a context in which only lookup operation is allowed. The default user group mapped to this role is Administrators.

Global Objects

The JNDI Registry Service enables each naming operation to be replicated in the cluster – the so called global operations. Thus, in all server processes naming systems, objects appear with the same name and data. These global objects can be accessed from the whole cluster. The default behavior of naming operations for server-side users (services and applications) is local execution, that is, no replication is made in the cluster. The external (remote) clients perform global naming operations, that is, the operations are replicated in the whole cluster.

Client-server Communication

The JNDI Registry Service uses the P4 protocol for client-server communication.

When you perform a naming operation in the naming system, you need a context instance. The proper context is returned by the chosen factory according to the type of the client and the properties set in the environment.

If the client is running on the server side, the factory does not use the P4 Provider Service to get a new context instance. If, however, the client is a remote one, the P4 Provider Service provides the connection between the client side and the server side.

More information: RMI-P4 Overview

Load Balancing

The JNDI Registry Service uses the AS Java P4 Provider Service to make the connection between the client side and one of the server processes in the cluster. This server process is chosen by the load balancing mechanism of the P4 Provider Service.

Nonserializable Objects

All bindings in the naming system consist of an object name, serialized object data, and attributes (if provided). Only serializable objects can be kept in the naming storage. The JNDI Registry Service provides an opportunity for nonserializable objects also to be bound in the naming system, but their data is kept on the client side and they are available only to the client that has bound them.

Redirection

Each remote client is using the naming service of one of the server processes in the AS Java cluster through a context instance. This instance is connected to the naming system of this server process and all naming operations are performed there. In case this server process goes down, the next naming operation is directed to another server process.