Storing Administered Objects in a Naming/Directory Service


All TIBCO Enterprise Message Service administered objects implement the JNDI “Referenceable” interface. This means that when they are bound in a foreign naming/directory service, what is physically stored there is not the serialized object itself, but rather a “Reference” object that knows how to re-create the original object when the object is looked up.

There are two forms of Reference objects that are stored, and which form is used depends on the origin of the original object. If the original object was looked up in the TIBCO Enterprise Message Service server, then the Reference object that gets stored for the object contains a URL pointer to the originating server. When this object is looked up in the foreign naming/directory service, the JNDI provider follows the associated URL and retrieves the object from the TIBCO Enterprise Message Service server. Figure 1 illustrates this case.

Figure 1 Object lookup in TIBCO Enterprise Message Service server

In Figure 1, the following occurs:

  1. Client 1 requests a lookup of an object in TIBCO Enterprise Message Service server by way of the JNDI provider supplied in TIBCO Enterprise Message Service.
  2. The TIBCO Enterprise Message Service server returns the object to Client 1.
  3. Client 1 binds the object into a third-party service using a third-party JNDI provider. The object is stored as a URL reference to the actual object in the TIBCO Enterprise Message Service server.
  4. Client 2 requests a lookup of an object in the third-party service using the third-party JNDI provider.
  5. The URL reference is returned by the third-party JNDI provider.
  6. JNDI realizes that this is a reference, and further that it is a URL reference to the TIBCO Enterprise Message Service server. Therefore, it invokes the URL context factory of the TIBCO Enterprise Message Service JNDI provider which requests a lookup of the object in the TIBCO Enterprise Message Service server.
  7. The TIBCO Enterprise Message Service server returns the object to Client 2.

If however, the object was created locally by the client using the public constructor of the class, then the Reference object that is stored for the object contains whatever information is required to re-create the object locally. When this object is subsequently looked up in the foreign naming/directory service, the JNDI provider uses the information stored in the Reference object to instantiate the original object locally. All of this behavior happens automatically without any special interaction required of the client. Figure 2 illustrates this case.

Figure 2 Object created locally by the client

In Figure 2, the following occurs:

  1. Client 1 creates a new administered object using the constructor of the class.
  2. Client 1 binds the object into the third-party service using the third-party JNDI provider. The object is stored as a local reference.
  3. Client 2 requests a lookup of the object in the third-party service using the third-party JNDI provider
  4. The local reference is returned to the third-party JNDI provider.
  5. JNDI realizes that this is a local reference, and invokes the TIBCO Enterprise Message Service JNDI object factory associated with the reference, which creates a new instance of the object locally and returns it to Client 2.

This behavior occurs automatically without any special interaction from the client.

Storing objects as a URL reference requires that the TIBCO Enterprise Message Service server be up and running (at the same URL) when the object is looked up in the foreign naming/directory service. Storing objects created locally does not have this requirement, however, because there is no automatic synchronization between the foreign naming/directory service and the TIBCO Enterprise Message Service server. There is no guarantee that the object returned from a lookup is valid, that is, that it exists inside the TIBCO Enterprise Message Service server. Storing objects as a URL reference ensures that the returned object is always a valid object.

For an example of storing administered objects in both of these forms, refer to the tibjmsJNDIStore.java example included with TIBCO Enterprise Message Service.

All TIBCO Enterprise Message Service administered objects implement the javax.naming.Referenceable interface. Therefore, these objects cannot be directly bound, along with a javaCodebase attribute, into a directory service that follows the schema defined in RFC 2713, and subsequently looked up with a service provider that uses the javaCodebase attribute (such as Sun's LDAP service provider). To successfully look up a TIBCO Enterprise Message Service administered object bound with the javaCodebase attribute, the object must first be manually serialized, then the serialized object can be directly bound into the directory service.


TIBCO Enterprise Message Service™ Application Integration Guide
Software Release 4.3, February 2006
Copyright © TIBCO Software Inc. All rights reserved
www.tibco.com