The Nojndi mechanism

The Nojndi mechanism enables JMS programs (such as WAS SOAP/JMS support) that use JNDI interfaces to use the same URI format as MQ programs that do not use JNDI. Nojndi uses parsing (rather than a repository) to provide the appropriate JMS/WebSphere MQ objects.

The URI contains specific WebSphere MQ queue manager and queue names. These names are parsed and used directly by SOAP/WebSphere MQ support. SOAP/JMS support uses the initialContextFactory specification to decide which JNDI implementation to use. 'initalContextFactory=com.ibm.mq.jms.Nojndi' will direct it to the Nojndi, which is an implementation of the JNDI interface.

A conventional JNDI implementation looks up input strings in a repository. The repository looks up these inputs based on its configuration, and JNDI returns the result as Java(TM) objects. In the case of SOAP/JMS, the input strings are determined by the connectionFactory and destination in the URI, and the JNDI layer then returns the result as appropriate ConnectionFactory and Queue objects. Where the JMS implementation is JMS/WebSphere MQ, these will be objects of the subclasses MQConnectionFactory and MQQueue.

By contrast, the Nojndi implementation operates by parsing the input strings, and does not use a repository. This parsing matches the parsing performed by the SOAP/WebSphere MQ implementation. It is still fed input strings based on the connectionFactory and destination in the URI, and still produces as a result objects of the subclasses MQConnectionFactory and MQQueue. Thus the WAS Web services client will access the same MQ queue managers and queues as the SOAP/WebSphere MQ implementation. No change is needed to the client (other than the presence of 'nojndi.jar'), and it will still be able to use other JNDI based services (that do not use Nojndi) within the same session.