Show TOC Start of Content Area

Procedure documentation Binding Objects  Locate the document in its SAP Library structure

Use

The naming service maintains a set of bindings, which relate names to objects. Binding an object means adding a name to the naming service and associating that name with a Java object.

JNDI Registry Service functionality can be used for storing and locating resources by server-side components and applications as well as standalone remote clients.

Depending on the type of objects (serializable; nonserializable, or remote) that are stored, the result from the bind and lookup operations in the naming system varies for the different types of clients.

Prerequisites

You have obtained an initial context instance.

Procedure

Use one of the following methods to associate an object to a name:

      Context.bind()

      Context.rebind()

and one of the following methods to associate the object to a set of attributes and a name:

      DirContext.bind()

      DirContext.rebind()

If there is an object already associated with the name specified as the method parameter, the bind () method throws NameAlreadyBoundException, while the rebind () method replaces the existing binding with the new object provided.

If you want to remove a binding, use the unbind() method.

Example

Depending on the object type passed as a method argument, the underlying naming system represents the object instance in a way that is suitable for storing it in the memory repository.

JNDI Registry Service provides different handling and support for each of the three different types of objects:

  1. Serializable objects - a Java object is serializable if its class or any of its super classes implement either the java.io.Serializable interface or its subinterface, java.io.Externalizable. A serializable object can be represented as a byte sequence which contains information identifying its class and the values set in its fields during the serialization of the object. Deserialization is the process of creating an object instance out of a byte sequence. If you apply consecutively the serialization and deserialization processes over a serializable object instance, you get a copy of the initial object instance, that is, a new instance of the same type initialized with the same field values.

Syntax

try {

// create InitialContext to access JNDI Registry Service naming system.

// InitialContext creation depends on the type of the client

  Context ctx = new InitialContext();

     

// Create instance of the object you want to bind

  Object serialObj = "Strings are serializable objects";

     

// define name to associate the object with

  String name = "serializable_binding";

     

// use bind or rebind method to associate the object with the name

  ctx.bind(name, serialObj);

     

  System.out.println("Bound object [" + serialObj + "] to name [" + name + "]");

} catch (NamingException e) {

  e.printStackTrace

}

The object passed to the bind () method is serializable. No matter if the client is running on the server process or if it is a standalone application, the object is serialized to byte array; sent to the server process (in case of an external standalone client) and stored in the JNDI Registry Service repository. Then, this object becomes available for lookup with the name specified from any client.

Note

External clients that look up this object should have its class definition and the classes referred by it in their class path to perform successful deserialization of the object.

More information about serializable objects:

http://java.sun.com/products/jndi/tutorial/objects/storing/serial.html

  1. Remote objects – objects that according to the Java Remote Method Invocation (RMI) mechanism can be invoked from one Java Virtual Machine (JVM) and executed remotely on another JVM. Remote objects must implement the java.rmi.Remote interface. When a method of such an object is invoked, the arguments are marshaled and sent from the caller JVM to the remote one where they are unmarshaled and used in the method invocation. The result of the method invocation is marshaled and sent back to the JVM that initiated the call; there it is unmarshaled and returned to the caller.

Remote objects can be made available to applications running on foreign JVMs by binding them in the JNDI Registry Service naming system. If a server-side component binds a remote object with a name in the JNDI Registry Service, any standalone application running on a foreign JVM can look up that object by name; get a reference to it called a stub, and invoke methods on the stub that will be executed on the server-side JVM where the object implementation resides.

Syntax

//For the remote object implementation we need a remote interface which extends //java.rmi.Remote interface.

 

public interface Timer extends Remote {

  public String getTime() throws RemoteException;

}

 

// The remote object implementation follows.

public class TimerImpl implements Timer {

  public TimerImpl() throws RemoteException {

  }

 

  public String getTime() throws RemoteException {

    return (new java.util.Date()).toString();

  }

}

 

//The next step is to create an instance of the remote object and bind it with a //name in the naming system.

try {

 // create InitialContext to access JNDI Registry Service naming system.

 // InitialContext creation depends on the type of the client

 Context ctx = new InitialContext();

  

 // Create instance of the object you want to bind

 Timer timer = new TimerImpl();

  

 // define name to associate the object with

 String name = "remote_timer";

  

 // use bind or rebind method to associate the object with the name

 ctx.bind(name, timer);

  

 System.out.println("Bound object [" + timer + "] to name [" + name + "]");

} catch (NamingException e) {

  e.printStackTrace();

}

When the object bound is a remote one, its implementation stays on the JVM of the application that created an instance and bound it in the naming service.

It is not sent to the server process where the JNDI Registry Service repository resides in case of external client usage. Only connection information for the client JVM is sent to the JNDI Registry Service repository so that with a lookup operation, the remote protocol is able to connect the stub to the remote implementation. The default remote protocol used by JNDI Registry Service is P4.

The most common case is when the remote object implementation is provided by a server-side client and looked up by external standalone clients or applications running in foreign AS Java clusters. In this case, remote clients invoke methods on the stub returned by the lookup operation which are executed on the server process where the object implementation is provided.  

Note

To look up such an object from a remote JVM, you must have the remote interface of this object in the class path.

  1. Nonserializable objects – neither serializable nor remote objects, which, if bound in JNDI Registry Service, become available only to components or applications running on the same JVM as the provider of the object. The lookup of such objects returns the same instance of the object that was initially bound in the naming system by the object provider. So all the components or applications that look up this object get a reference to one and the same instance and concurrently invoke methods over that instance. Such nonserializable objects should provide methods that support concurrent access. This pattern can be used for factory objects.

Syntax

try {

// create InitialContext to access JNDI Registry Service naming system.

// InitialContext creation depends on the type of the client

  Context ctx = new InitialContext();

        

// Create instance of the object you want to bind

  Object nonSerialObj = new Object();

        

// define name to associate the object with

  String name = "non_serializable_binding";

        

// use bind or rebind method to associate the object with the name

  ctx.bind(name, nonSerialObj);

        

  System.out.println("Bound object [" + nonSerialObj + "] to name [" + name + "]");

} catch (NamingException e) {

  e.printStackTrace();

}

Note

If a nonserializable object is bound by a server-side component, it is not visible outside of the server process, that is, no external standalone client will be able to look it up.

 

 

 

 

End of Content Area