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. You will need to 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" ?> <dynamo-message-system> <patchbay> <provider> <provider-name> companyMessaging </provider-name> <topic-connection-factory-name> /newProvider/TopicConnectionFactory </topic-connection-factory-name> <queue-connection-factory-name> /newProvider/QueueConnectionFactory </queue-connection-factory-name> <xa-topic-connection-factory-name> /newProvider/XATopicConnectionFactory </xa-topic-connection-factory-name> <xa-queue-connection-factory-name> /newProvider/XAQueueConnectionFactory </xa-queue-connection-factory-name> <supports-transactions> true </supports-transactions> <supports-xa-transactions> true </supports-xa-transactions> <username> someUser </username> <password> somePassword </password> <client-id> local </client-id> <initial-context-factory> /myApp/jms/InitialContextFactory </initial-context-factory> </provider> <message-source> ... </message-source> ... </patchbay> </dynamo-message-system>
Multiple providers may be specified in the system, as long as each has a unique provider-name. Each <provider> tag may supply the following fields:
provider-name
This field is required, and is used to identify the provider. The field may 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.
topic-connection-factory-name
queue-connection-factory-name
xa-topic-connection-factory-name
xa-queue-connection-factory-name
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 xa-topic-connection-factory-name and xa-queue-connection-factory-name will not be defined for those providers.
supports-transactions
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 will support this, but the provider’s documentation should provide the definitive answer.
supports-xa-transactions
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 that if this is set to true, xa-topic-connection-factory-name and xa-queue-connection-factory-name should be provided as well.
username
password
Many JMS providers require that clients log in to the JMS system using a username and password. If these fields are defined, then their values will be used to log in when creating JMS connections.
client-id
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 client-id.
initial-context-factory
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 initial-context-factory.
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 will call this method to get the Context that it will use 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 may 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 initial-context-factory.
