Patch Bay comes preconfigured to use Local JMS and SQL JMS. This ensures that Oracle ATG Web Commerce products and demos work without any further configuration. If desired, you can configure Patch Bay to use your application server’s JMS provider or a third-party JMS provider, through 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 Oracle ATG Web Commerce’s CLASSPATH. See the Installation and Configuration Guide for information about modifying the Oracle ATG Web Commerce CLASSPATH.
The DMS configuration file must declare all providers before it declares message sources and 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>
If you specify multiple providers, each must have a unique provider-name.
Each <provider> tag can supply the following fields:
provider-name
Required, identifies the provider. The field can have any value that is unique among other providers in the system.
When message sources and 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 that are identified by JNDI names., as specified by the JMS provider documentation.
Some of these fields might be optional. For example, JMS providers that do not support XA do not require xa-topic-connection-factory-name and xa-queue-connection-factory-name.
supports-transactions
Set to true or false, to specify whether the JMS provider supports commit() and rollback().
supports-xa-transactions
Set to true or false, to specify whether the JMS provider supports XA transactions.
Note: If this field is set to true, you must also set xa-topic-connection-factory-name and xa-queue-connection-factory-name.
username
password
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.
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 and the topics and queues managed by a provider. These JNDI names are resolved against an InitialContext. Each provider obtains the InitialContext in its own way, as described by its documentation. Typically, a Dictionary is created with several properties, and is passed 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 as required 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(). Patch Bay calls this method to get the Context that it uses to resolve a 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 must be placed somewhere in the Nucleus hierarchy and its full Nucleus name must be supplied to the initial-context-factory.
