Release 10.1A: OpenEdge Development:
Messaging and ESB

> ## Finding administered objects in JNDI or proprietary directories

> A JMS-administered object is an object created by a JMS administrator and registered with a directory (typically a JNDI-compliant directory) under a name that is meaningful to the JMS clients. The object contains JMS configuration information that is created by a JMS administrator and later used by JMS clients. Java Naming and Directory Interface (JNDI) is an interface for JMS administrators to create and configure administered objects and store them in a namespace.

> The SonicMQ-administered objects are:

> - `TopicConnectionFactory`

> - `QueueConnectionFactory`

> - `Topic`

> - `Queue`

> For example, the administrator creates a `TopicConnectionFactory` object, which contains all the JMS server connection parameters (communication protocol host and port), assigns it a name, and stores it in a JNDI directory. The client does not have to know the connection parameters to connect to the JMS server. The client finds the object by name in the directory and uses it to create connection objects. The administrator can change the connection parameters later without affecting client applications.

> The administrator can give the `Topic` and `Queue` objects meaningful aliases to shield the client from their internal names. For example, a topic with the internal JMS name of `sports.USA.Northeast.golf` could be stored in the directory under `northern.golfers`. For more information on administered objects, see the Java Message Service specification, SonicMQ Programming Guide , and SonicMQ Configuration and Management Guide .

> ##### Using the OpenEdge Adapter for the SonicMQ and the 4GL-JMS API with administered objects

> JMS does not impose any specific directory for storing administered objects (although it establishes the convention of using JNDI-compliant directories, such as LDAP). Also, the process of connecting to a JNDI server and obtaining an initial context is not standardized.

> Therefore, to use directory-stored JMS objects, you must implement a Java class, compile it, and install the class file on the OpenEdge Adapter for the SonicMQ host under the OpenEdge Adapter for the SonicMQ’s `CLASSPATH`. (For more information on `CLASSPATH`, see the "Setting the CLASSPATH" section.) The OpenEdge Adapter for the SonicMQ looks for that class when it starts up. If it finds the class, it creates an instance object of it and uses it to locate administered objects. If it does not find the class, the OpenEdge Adapter for the SonicMQ creates objects as required.

> ##### jmsfrom4gl.AdminObjectFinder class

> The following code is the skeleton of the `jmsfrom4gl.AdminObjectFinder` class. Use it as a template to create a class file and install it on the OpenEdge Adapter for the SonicMQ host; Unified Broker host for BrokerConnect, 4GL client host for ClientConnect, and AppServer or WebSpeed Transaction server host for the ServerConnect option.

> The `jmsfrom4gl.AdminObjectFinder` name is mandatory. The class and the `get...()` methods must be declared public. The `AdminObjectFinder` class must be part of the `jmsfrom4gl` package and placed in a directory called `jmsfrom4gl`. The directory that contains `jmsfrom4gl` must be on the `CLASSPATH` of the OpenEdge Adapter for SonicMQ. For example:

>     package jmsfrom4gl;
>     import javax.jms.TopicConnectionFactory;
>     import javax.jms.QueueConnectionFactory;
>     import javax.jms.Topic;
>     import javax.jms.Queue;
>     public class AdminObjectFinder
>     {
>       public TopicConnectionFactory getTopicConnectionFactory(String name)
>         throws Exception
>       {
>         TopicConnectionFactory factory = null;
>         // Write code to populate factory
>         return factory;
>       }
>       public QueueConnectionFactory getQueueConnectionFactory(String name)
>         throws Exception
>       {
>         QueueConnectionFactory factory = null;
>         // Write code to populate factory
>         return factory;
>       }
>       public Topic getTopic(String name)
>         throws Exception
>       {
>         Topic topic = null;
>         // Write code to populate topic
>         return topic;
>       }
>       public Queue getQueue(String name)
>         throws Exception
>       {
>         Queue queue = null;
>         // Write code to populate queue
>         return queue;
>       }
>     }

> Notes: The `brokerURL` startup parameter is used as the input parameter for the `getTopicConnectionFactory` and `getQueueConnectionFactory` methods. For example, if the 4GL application calls the setBrokerURL procedure passing in the input parameter `directory_factory_name`, the 4GL-JMS implementation on the server side calls the `getTopicConnectionFactory` method with `directory_factory_name` as the parameter.
> If the `getTopicConnectionFactory` and `getQueueConnectionFactory` methods are implemented, the `jmsServerName` startup parameter is ignored (since the identity of the server’s vendor is encapsulated in the object).
> It is sufficient to implement methods for those objects that should be obtained from the directory. For example, it is legal to have an `AdminObjectFinder` class with only the `getTopicConnectionFactory` method. The 4GL-JMS implementation looks for the methods dynamically and does not fail if the other methods are missing.
> If the object finder method returns null, the 4GL-JMS implementation tries to create the object as if the method is not there.
> For more information on `CLASSPATH`, see the "Setting the CLASSPATH" section.

Copyright © 2005 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095