JMS entities like Destinations and Connection Factories (also collectively known as administered objects) are well defined in JMS Specifications. The roles of these objects as well as their APIs are well defined. However, JMS specifications do not state how to obtain an instance of these objects. It is left to the JMS Provider to provide instances of these objects to an application. FioranoMQ allows applications to use JNDI APIs to obtain instances of Administered objects. For additional information on JNDI, please refer to http://java.sun.com/products/jndi/
The use of JNDI allows the application code to be Standards Based without the need to import Fiorano specific classes. FioranoMQ provides a limited implementation of the directory server. This is done so that an end user need not configure information from a third party directory server for using FioranoMQ.
FioranoMQ also allows applications to store and retrieve administered objects in a third party external LDAP server. FioranoMQ allows its applications to create a new instance of an administered object (destination or queue) and uses it in all JMS operations. This requires using non-standard Fiorano specific APIs in the application.
Following topics are covered in this section:
The Naming Manager, a module within the FioranoMQ Server, provides all common Naming Services (lookup, bind, delete, list, and so on). Naming requests, originating from a JMS Application, are sent to the FioranoMQ server is internally forwarded to this module, which processes the request and responds accordingly. Administrative requests leading to creation or deletion of administered objects are also forwarded to this module.
The interface for this module is well defined and allows multiple implementations which differ mainly in the persistent media used for storing information. A FioranoMQ Administrator is free to plug in any implementation (or even write a new implementation and plug it in) of this interface.
File
This is the default implementation for Naming Manager. It stores information in a proprietary File (defaults to admin.datinrunfolderof the profile).
XML
This implementation stores information in clear text format in an XML file (admin.xml in the run folder of the profile).
LDAP
This implementation usesathirdpartyJNDI compliantNaming and Directory Service to persist information.
Cache
This implementation creates a "cache" of admin objects in memory. The cache can be used with any of the above implementations for storage purposes. Caching is beneficial in situations where there aren't frequent changes in the admin object store.
Salient Features
FioranoMQ can be configured to use any of the above Naming Manager implementations. The configuration here takes place off-line.
The JNDI implementation provided by FioranoMQ is limited and provides the implementation of only basic methods. It should not be considered a standalone JNDI implementation.