You can use the Patch Bay configuration file to enable Patch Bay to work with a 3rd-party JMS provider. Configuring a 3rd-part provider is done through the standard Patch Bay tags. Consult the provider’s documentation to determine the values to use.

In addition, you must add the client libraries for the JMS provider to Dynamo’s CLASSPATH. See the ATG Installation and Configuration Guide for information about modifying the Dynamo CLASSPATH.

You declare the provider in the DMS configuration file before any message sources or sinks. For example:

<?xml version="1.0" ?>








Multiple providers can be specified in the system, as long as each has a unique provider-name. Each <provider> tag can supply the following fields:


This field is required, and is used to identify the provider. The field can have any value, as long as that value is unique among all the providers in the system.

When message-sources and message-sinks define input and output-destinations, those destinations are associated with a provider-name. This provider-name must match the provider-name declared for the provider that is handling a particular destination.


A JMS provider is accessed through ConnectionFactories, which are identified by JNDI names. The JMS provider should provide documentation about the names to be used to access those ConnectionFactories.

It is not necessary for all these fields to be present. For example, some JMS providers do not support XA, so the xatopicconnectionfactoryname and xaqueueconnectionfactoryname are not defined for those providers.


This field should be defined as either true or false, indicating if the JMS provider supports the use of commit() and rollback(). Most JMS providers support this, but the provider’s documentation should provide the definitive answer.


This field should be defined as either true or false, indicating if the JMS provider supports XA transactions. Not all JMS providers support this, but the provider’s documentation should provide the definitive answer.

Note: If this is set to true, xatopicconnectionfactoryname and xaqueueconnectionfactoryname should be provided as well.


Many JMS providers require that clients log in to the JMS system using a username and password. If these fields are defined, their values are used to log in when creating JMS connections.


Many JMS providers have a notion of a client identifier, which allows the provider to remember who a client is even if that client is disconnected and later reconnects. This allows the JMS provider to queue up messages for the client while the client is disconnected. When the client reconnects, it uses the same client identifier it had previously, and the JMS provider knows to deliver the messages queued up for that client.

This field is optional, but it should be filled in if there are multiple clients running against the same JMS provider. In this case, each client should be assigned a unique clientid.


JNDI names are used to identify the connection factories, as well as the topics and queues managed by a provider. These JNDI names are resolved against an InitialContext. Each provider has a different way of obtaining the InitialContext, which should be included in the provider’s documentation. In most cases, a Dictionary must be created containing several properties, and the InitialContext is created by passing that Dictionary to the InitialContext’s constructor.

For example, a JMS provider might say that the InitialContext must be created using this code:

Hashtable h = new Hashtable ();
h.put (Context.INITIAL_CONTEXT_FACTORY, "...");
h.put (Context.PROVIDER_URL, "...");

Context ctx = new InitialContext (h);

In order for Patch Bay to create the InitialContext in the way prescribed by the provider, this code must be packaged into a Nucleus component, and the name of the Nucleus component must be supplied as the initialcontextfactory.

The Nucleus component must implement the interface atg.dms.patchbay.JMSInitialContextFactory, which defines a single method createInitialContext. Whenever Patch Bay needs to resolve a JNDI name, it calls this method to get the Context that it uses to resolve the JNDI name.

The code for that Nucleus component might look like this:

import javax.naming.*;
import atg.dms.patchbay.*;

public class MyInitialContextFactory
  implements JMSInitialContextFactory
  public Context createInitialContext (String pProviderName,
                                 String pUsername,
                                 String pPassword,
                                 String pClientId)
    throws NamingException
      Hashtable h = new Hashtable ();
      h.put (Context.INITIAL_CONTEXT_FACTORY, "...");
      h.put (Context.PROVIDER_URL, "...");

    return new InitialContext (h);

The arguments passed to createInitialContext are taken from the provider’s other configuration values. Some JMS providers might need this information when creating the InitialContext.

This Nucleus component needs to be placed somewhere in the Nucleus hierarchy and its full Nucleus name should be supplied to the initialcontextfactory.

loading table of contents...