ATG Dynamo Messaging System

e-Com
ATG Dynamo Messaging System
ATG Dynamo Messaging

System
Pawan Modi
Modipawan8126@gmail.com
DYNAMO MESSAGING SYSTEM

Oracle ATG Web Commerce includes a number of JMS-related tools, which are known collectively as the
Dynamo Messaging System (DMS).
ATG
Page 1
Table of Contents
ATG INTRODUCTION
JMS INTRODUCTION
JMS Message Producers and Consumers
JMS Destinations
Message Persistence
7
7
JMS Message Formats

Message header
Message body
9
9
9
ATG DMS
10
Local JMS
Creating Local JMS Destinations
11
11
SQL JMS
Creating SQL JMS Destinations
SQL JMS Polling Interval
13
13
14
Patch Bay
Patch Bay Manager
Messaging Components
Patch Bay Initialization
15
15
15
16
Creating Message Sources
17
Creating Message Sinks
18
Creating Message Filters
19
Configuring Patch Bay

Declaring JMS Providers
Declaring Message Sources, Sinks, and Filters
Connecting to Destinations
Using Messaging Ports
Using the Message Registry
Using Patch Bay with Other JMS Providers
20
20
21
21
24
27
27
REFERENCES
ATG
31
Page 2
Abbreviation
DAS
Dynamo Application Server
DAF
Dynamo Application Framework
DSS
Dynamo Scenario Server
DPS
Dynamo Personalization Server
DRP
Dynamo Request Protocol Server
GSS
Global Scenario Server
LM
Load Manager
CM
Connection Module
RMI
Remote Method Invocation
DCC
Dynamo Control Center
SBS
Session Backup Server
UDP
User Datagram Protocol alternative protocol to TCP/IP, (usually used for broadcasting)
SNMP Simple Network Management Protocol, MIB packet services
ATG
Page 3
ATG Introduction
ATG is the worldwide leader in the E-commerce solutions. ATG product suite has enabled the vendors
to enable their e-commerce commercial capabilities.
ATG
Page 4
JMS Introduction
Java Message Service (JMS) defines a standard way for different elements of a J2EE application to
communicate with each other. With JMS, components do not access each other directly. Instead, a
component posts a message to a message broker, which then distributes the message to other
components. In general, the posting and delivery actions occur in separate transactions, and might even
occur in different processes, machines, or sites. This mechanism decouples the actions of the sending
and receiving components to so that the sender can continue with its work without having to wait for
the receiver to process the message. This decoupling is often called asynchronous processing.
The JMS API defines the interfaces for sending and receiving messages. It also defines the semantics for
message delivery and acknowledgement, and how message delivery should behave in a transactional
environment.
JMS message producer sends a message to a destination, where it is retrieved by one or more message
consumers. JMS defines two types of destinations, corresponding to two basic forms of messaging.
ATG
Topic - A destination used in publish/subscribe messaging. If a topic has several subscribed

listeners, each message published to that topic is delivered to all listeners.
Queue
- A destination used for point-to-point messaging. If a queue has several subscribed

receivers, each message is delivered to only one of the receivers. A different receiver might
be chosen for each message, possibly depending on some load balancing mechanism.
Page 5
JMS Message Producers and Consumers

The JMS API defines a set of interfaces for creating message producers and consumers. There are
separate interfaces for producers and consumers, and for objects that communicate with topics and
queues. These interfaces are all part of the javax.jms package.
QueueSender
QueueReceiver
TopicPublisher
TopicSubscriber
In addition to implementing one of these interfaces, the producer or consumer must also obtain a
ConnectionFactory, find destinations, obtain a JMS Connection, and create JMS Session etc.
ATG
Page 6
JMS Destinations
JMS defines two types of destinations, topics and queues. The use of destinations provides much of the
flexibility in JMS. If a new application needs to send messages to or receive messages from an existing
application, it can publish or subscribe to the destinations used by that application.
The new application does not need to be aware of the message producers and consumers in the original
application, just the destinations. This means that message producers and consumers can be added to
or removed from one application without affecting other applications, as long as the destinations
remain the same.
Each destination is maintained by a single JMS provider, which typically maintains many destinations.
The creation and management of destinations within a JMS provider is usually an administrative or
configuration operation. If a message is sent to a destination, that destinations JMS provider is
responsible for receiving the message and passing it on to subscribers waiting for messages from that
destination.
Different providers might use different mechanisms to accomplish this. For example, Oracle ATG Web
Commerces SQL JMS uses an SQL database to store and deliver messages, for applications that require
the messaging system to be highly reliable. Other JMS providers might use file or memory-based
storage.
Message Persistence
Queue destinations typically are persistent. If a message is sent to a queue but no receiver is online, the
message is kept in the queue, waiting for a receiver to connect and start reading from the queue. After a
message is delivered to a single receiver, it is removed from the queue.
Topics, however, are non-persistent by default. If a message is sent to a topic, it is delivered to all
subscribers to that topic that are currently online, and then removed. Any subscriber that is offline does
not receive the message. If no subscribers are currently online, the message is simply removed from the
topic without being delivered anywhere.
But some applications require the flexibility of a topic, but also the persistence offered by a queue. For
example, suppose an application requires a message to be delivered to several subscribers, but it is not
acceptable for a subscriber to miss any of the messages if it goes offline. JMS addresses this need
through the use of durable subscriptions. A message consumer that has a durable subscription to a topic
can go offline, then reconnect later and pick up any messages that were sent to the topic in its absence.
Durable versus non-durable is a property of each individual subscriber but not the characteristic of the
topic as a whole. A topic can have a mix of subscribers, some durable and some non-durable.
Durable and non-durable subscribers are created through the JMS API. Creating a durable subscriber
requires specifying a name that the topic uses to identify the subscriber. Each durable subscriber to a
topic must have a name that is unique for that topic. If a subscriber disconnects, the JMS provider holds
ATG
Page 7

any subsequent messages under that name. If the subscriber then reconnects using the same durable
subscription name, the messages held under that name are delivered to the subscriber.
ATG
Page 8
JMS Message Formats

The JMS API defines the standard form of a JMS message, which should be portable across all JMS
providers. Because the JMS API was designed to accommodate many existing providers, the resulting
message form encompasses a wide variety of features. A JMS message consists of two parts.
Message header
Message body
Message header
The header contains system-level information common to all messages, such as the destination and the
time it was sent, while the body contains only application-specific data. The header can also contain
some application-specific information, stored as keyword/value properties.
The most important header value is the JMSType. This is a String that is used to identify what kind of
message is being sent. Handlers often examine the JMSType to see how they should handle an incoming
message.
The header is useful for specifying message selectors. When a receiver subscribes to a destination, it can
specify a message selector, which acts as a filter for weeding out messages the receiver does not want
to see. The message selector must be specified in terms of the messages header. For example, a
receiver can specify a message selector saying that it wants to see only messages whose JMSType is
atg.das.Startup.
Message body
To accommodate the various data formats of existing providers, JMS defines five distinct message body
types. In the JMS API, these translate into five Java interfaces, each subclassing the javax.jms.Message.
ATG
Page 9
ATG DMS
Oracle ATG Web Commerce includes a number of JMS-related tools, which are known collectively as the
Dynamo Messaging System (DMS). The main parts of DMS are Two JMS providers i.e. Local JMS and
SQL JMS.
Local JMS is built for high-speed low-latency synchronous messaging within a single process.
SQL JMS is more robust, and uses an SQL database to handle communication between
components within the same Oracle ATG Web Commerce application, or components running in
different processes.
Patch Bay is an API and configuration system layered on top of JMS. Patch Bay is designed to ease the
development of messaging applications in Oracle ATG Web Commerce. The Patch Bay API allows
Nucleus components to send and receive messages. The configuration system uses an XML file to specify
how these components should be connected.
Patch Bay also maintains a Message Registry that the Oracle ATG Web Commerce user interfaces use to
present lists of possible notifications to users. Oracle ATG Web Commerce registers the messages that it
sends with the Message Registry. Applications can also register their own messages, which then appear
in the Oracle ATG Web Commerce user interfaces.
The different DMS pieces can be used independently. For example, you can use Local JMS, SQL JMS, or
both, with or without Patch Bay. You can use a third-party JMS provider, or use the JMS implementation
provided with your application server, also with or without Patch Bay.
ATG
Page 10
Local JMS
Local JMS is a JMS provider supplied with Oracle ATG Web Commerce. Messages sent through Local JMS
can travel only between components in the same Oracle ATG Web Commerce process. Local JMS
delivers messages synchronously. This means that when a component sends a message, the sending
component blocks until the receiving components receive and process the message. The entire message
sending and receiving process occurs within a single thread. As a result, both the sending and receiving
of the message occurs in the same transaction.
Local JMS does no queuing. When a message is sent, Local JMS immediately finds out who the receivers
are and calls the appropriate methods on the receivers to deliver the message, waiting for each receiver
to process the message before delivering the message to the next receiver. Only when the message has
been delivered to all receivers does control return to the sender. In this way, Local JMS works more like
Java Bean events than like typical JMS implementations; when a Java Bean fires an event, it actually calls
a method on several registered listeners.
Local JMS is also non-durable; all messages are non-persistent. If a message is sent to a queue
destination that has no listeners, the message disappears. Also, durable subscriptions to topic
destinations act exactly like non-durable subscriptionsif a subscriber is not listening to a topic, it
misses any messages sent to that topic whether it is subscribed durably or not.
Local JMS implements synchronous, extremely high-performance messaging. Local JMS is most often
used to pass data around to various components within a single request.
Creating Local JMS Destinations

In Local JMS there are 2 ways to create JMS destinations.
1. Create destinations by setting the localJMSQueueNames and localJMSTopicNames properties of
the /atg/dynamo/messaging/MessagingManager component
For Example:
localJMSQueueNames+=/Orders
localJMSTopicNames+=/RegistrationEvents,/FinancialEvents
When a Nucleus-based application starts up, it creates these destinations. To access a Local JMS
destination in your code, you use JNDI references like shown here.
For Example:
localdms:/local{queue-or-topic-name}
localdms:/local/Orders.
ATG
Page 11

2. Create Local JMS destinations using DMS configuration file. These destinations are specified by
name, separated into topics and queues.
When a Nucleus-based application starts up, it create these destinations with the JNDI names
localdms:/local/MyApp/RegistrationEvents,
localdms:/local/MyApp/FinancialEvents,
and
localdms:/local/MyApp/Orders.
ATG
Page 12
SQL JMS
Local JMS discussed above is synchronous but many messaging applications require messaging to be
asynchronous. When a sender sends a message asynchronously, the message is handed off to the JMS
provider, and the sender continues on with its work. Asynchronous messaging is useful for processes
that can be broken down into separate stages, where each stage might take an unknown amount of
time. For example, ATG Commerce uses asynchronous messaging to process an order.
Another key difference between Local JMS and SQL JMS is message persistence. Local JMS stores no
state, so if the system fails, all messages are lost. SQL JMS uses an SQL database for persistence of
messages. This ensures that messages are not lost in the event of system failure, and enables support
for persistent queues and durable subscriptions.
To deliver messages, SQL JMS polls the database periodically, checking the appropriate tables to see if
any new messages were written. If so, those messages are delivered to the appropriate message
receivers and then removed from the database. This all occurs in transaction, so if a failure occurs or the
transaction rolls back, the messages are all returned to the database, again guaranteeing that messages
do not get lost.
Note: In SQL JMS, the sending of a message and the receiving of a message occur in separate
transactions. A sender might send a message in a transaction that later commits successfully. This does
not mean that the receiver has successfully received the message. It just means that SQL JMS has
successfully delivered the message to its destination. At some point in the future, receipt of the message
is placed in another transaction. The message is then removed from the database when that second
transaction successfully commits.
SQL JMS uses standard JDBC drivers to communicate with the database. This allows SQL JMS to operate
in a distributed environment, where an Oracle ATG Web Commerce server and the database are located
on different machines. SQL JMS can also run on multiple Oracle ATG Web Commerce servers at once, all
utilizing the same database. This enables multiple Oracle ATG Web Commerce servers to use SQL JMS to
communicate with each other.
Connection factory for all SQL JMS topic and queue connections (including XA connections) is the
Nucleus component /atg/dynamo/messaging/SqlJmsProvider.
Creating SQL JMS Destinations

In SQL JMS, create destinations using the requiredQueueNames and requiredTopicNames properties of
the /atg/dynamo/messaging/SqlJmsProvider component.
For example
requiredQueueNames+=MyApp/Orders
requiredTopicNames+=MyApp/RegistrationEvents,MyApp/FinancialEvents
ATG
Page 13

When SQL JMS starts, it looks at these lists of queue and topic names. It then looks into the dms_queue
and dms_topic tables and adds any topic or queue names that are not already in those tables.
To access an SQL JMS destination in your code, you use JNDI references.
For Example
sqldms:/{queue-or-topic-name}
sqldms:/MyApp/RegistrationEvents
SQL JMS Polling Interval

SQL JMS works through polling. At periodic intervals it performs a query on the database to see if there
are any messages waiting to be delivered to its local clients. By default, this polling occurs at 20 second
intervals. This means that messages have an average latency of 10 second.
Decreasing the polling interval decreases the average latency. However, decreasing the polling interval
also increases the frequency of queries from each client, thereby increasing the database load. This can
add up to a significant load on the database.
So if the database load is too high, the administrator should increase the polling interval on the Oracle
ATG Web Commerce servers to decrease the number of queries each server is making. This increases
latency, making some messages take longer to get from sender to receiver, but decreases the load on
the database.
The
polling
interval
is
set
in
the
/atg/dynamo/messaging/SqlJmsProvider component.
messagePollSchedule
property
of
the
messagePollSchedule=every 20 sec in 10 sec

Note: While latency is affected by the polling interval, overall system throughput should remain
unchanged. Each time a query performs a poll, it reads in all messages waiting for that client. For
example, if a message is being sent every second, and the polling interval is set to 20 seconds, every poll
reads 20 messages, yielding an effective throughput of 1 message/second, with an average latency of 10
seconds. But if the polling interval is set to 30 seconds, the average latency increases to 15 seconds, but
every poll reads 30 messages, again yielding a throughput of 1 message/second.
ATG
Page 14
Patch Bay
Patch Bay is designed to simplify the process of creating JMS applications. Patch Bay includes a
simplified API for creating Nucleus components that send and receive messages, and a configuration file
where you declare these components and your JMS destinations. When a Nucleus-based application
starts up, it examines this file and automatically creates the destinations and initializes the messaging
components. This means your code does not need to handle most of the JMS initialization tasks, such as
obtaining a ConnectionFactory, obtaining a JMS Connection, and creating a JMS Session.
Patch Bay Manager

Patch Bay is represented in Nucleus as the component /atg/dynamo/messaging/MessagingManager,
which is of class atg.dms.patchbay.PatchBayManager. Patch Bay is configured with a properties file like
all other nucleus components. The properties file controls the general behavior of the Patch Bay system;
it configures such things as the transaction manager used by Patch Bay and logging behavior.
In addition to the properties file, the MessagingManager uses an XML file called the DMS configuration
file to configure the individual parts of the Patch Bay system, such as JMS providers, message sources
and sinks, and destinations. The definitionFile property of the MessagingManager component names
the DMS configuration file.
Messaging Components
Patch Bay API includes Java interfaces that messaging components must implement in order to send and
receive messages.
Message source - A component that can send messages. A message source must implement the
atg.dms.patchbay.MessageSource interface.
Message sink - A component that can receive messages. A message sink must implement the
atg.dms.patchbay.MessageSink interface.
Message filter - A component that implements both interfaces, and can send and receive
messages.
All message sources, sinks, and filters must have global scope.
Note: Unlike standard JMS, Patch Bay does not have separate interfaces for objects that communicate
with topics and those that communicate with queues. A message source can send messages to both
topics and queues, and a message sink can receive messages from topics and queues.
In addition to your sources and sinks, you must also define standard JMS destinations. Patch Bay cannot
connect a message source directly to a message sink. Instead, the two must be connected through a JMS
destination.
ATG
Page 15
Patch Bay Initialization

Patch Bay defines a simple life cycle for message sources, sinks, and filters. When Patch Bay is started, it
resolves each of the Nucleus names. If the referenced components are not yet created, they are created
at this time according to the standard Nucleus name resolution procedure.
Message Sink Initialization

As soon as message sinks are resolved by nucleus, message sinks should be prepared to receive
messages, which can start receiving at any time.
Message Source Initialization

Message sources follow a slightly more complicated protocol. After a message source is resolved in
Nucleus, Patch Bay calls MessageSource.setMessageSourceContext() on the component. This provides
the component with a context object that it can use to create and send messages. At this point, Patch
Bay initializes the various JMS providers and makes sure that the messaging infrastructure is up and
running.
It
then
walks
through
each
of
the
message
sources
and
calls
MessageSource.startMessageSource() on each one. After this call, the message sources can start
sending messages.
Message Filter Initialization

Message filters are combinations of message sources and message sinks. They implement both
interfaces, and must follow the protocols for both. This means that a message filter must be able to
receive messages as soon as it has been initialized, but should not initiate the sending of messages
before setMessageSourceContext() and startMessageSource() are called.
Note: There is one situation where message filters behave differently. A typical operation for a message
filter is to receive a message, then to send another message in response. In this case, it is acceptable for
the message to send a message in response to a received message, even if startMessageSource() has not
yet been called (although setMessageSourceContext() must be called first in all cases). It is still not
acceptable for a message filter to initiate a message before startMessageSource() has been called, but it
is fine for the message filter to send a message in response to a received message.
ATG
Page 16
Creating Message Sources

A message source must implement the atg.dms.patchbay.MessageSource interface. Through this
interface, the message source is assigned a MessageSourceContext that it can use to create and send
messages.
The following example demonstrates how to do this.
ATG
Page 17
Creating Message Sinks

A message sink must implement the atg.dms.patchbay.MessageSink interface. This interface defines a
single method, receiveMessage, which is called to notify the message sink that a message is being
delivered. This method might be called simultaneously by many threads, so the message sink should be
coded accordingly.
The following is a simple example of how a message sink might handle a message.
ATG
Page 18
Creating Message Filters

Message filters must implement both the MessageSource and the MessageSink interface. A message
filter typically implements receiveMessage by manipulating the message in some way, then sending a
new message, like this.
This filter takes in TextMessages, and then sends them out again with period (.) replaced by forward
slash (/) in the text. Notice that the mStarted flag is not consulted as shown for the message source,
because a message filter is allowed to send out messages in response to incoming messages
regardless of whether it has been started or stopped.
ATG
Page 19
Configuring Patch Bay

Patch Bay is represented in Nucleus as the component /atg/dynamo/messaging/MessagingManager.
The definitionFile property of the component MessagingManager names the XML file that configures
Patch Bay. The value of this property is /atg/dynamo/messaging/dynamoMessagingSystem.xml
Declaring JMS Providers

By default, Patch Bay is configured to use Local JMS and SQL JMS. These providers and the connection
factories they use are specified through Nucleus components of
classatg.dms.patchbay.JMSProviderConfiguration.
For example, to configure SQL JMS, Oracle ATG Web Commerce includes a component of this class
named/atg/dynamo/messaging/DynamoSQLJMSProvider. The properties file for this component
includes these lines.
You generally should not need to modify any of these settings for Local JMS or SQL JMS.
You can declare JMS providers at the top of the Patch Bay configuration file, using tags that correspond
to the properties of JMSProviderConfiguration.
ATG
Page 20

You can also designate a JMS provider as the default provider in Patch Bay by setting the
defaultJMSProvider property of the /atg/dynamo/messaging/MessagingManager component to point to
the component that configures the provider. By default, this property points to the
DynamoSQLJMSProvider component, which configures SQL JMS.
Declaring Message Sources, Sinks, and Filters

One of the functions of the DMS configuration file is to name all message sources, sinks, and filters
existing in the system. As described earlier, these elements are globally scoped Nucleus services that
implement the appropriate interfaces. Each element should be declared with its Nucleus name.
For example
Any number of sources, sinks, and filters can be specified, in any order
Connecting to Destinations
After a message source, sink, or filter has been declared in the configuration file, it must be hooked up
to JMS in order for its messages to go anywhere, or for it to receive messages. As discussed earlier, a
messaging component is never connected directly to another component. Instead, a messaging
component is hooked up to a JMS destination, maintained by one of the JMS providers registered with
Patch Bay. Messaging components communicate with each other by hooking up to the same
destination. if message source A sends messages to destination D, and message sink B receives
messages from destination D, messages flow from A to B.
ATG
Page 21

Whenever a destination is specified in the DMS configuration file, it must specify which provider owns
that destination. The destination must also be named by its JNDI name, using the prefix appropriate to
that destinations provider. Oracle ATG Web Commerce includes two providers: Local JMS and SQL JMS.
The following table specifies the required information for each provider.
The following illustrates how a message source is connected to a destination in the DMS configuration
file. In this case, the destination is managed by Local JMS, and is called localdms:/local/TestMessages.
The important part of this example is the output-destination definition. This definition says that
messages coming out of this Nucleus component should be directed to the topic called
localdms:/local/TestMessages, managed by JMS provider local.
ATG
Page 22

This says that each message coming out of the component is sent to a destination in Local JMS, and a
destination in SQL JMS. The messages are sent in the order specified.
Message sinks shown below are configured in much the same way. This configuration says that
messages sent to either topic in either provider are passed to the TestMessageSink1 component, using
the MessageSink.receiveMessage() call.
Notice that the sqldms input-destination specifies a durable-subscriber-name. This means that the
connection to the topic should be made using a durable subscription, with the given durable subscriber
name. If messages are sent to this topic while the subscriber is off-line, those messages are held under
this name. When the subscriber starts up, the messages held under that name are passed to the
message sink.
ATG
Page 23

The durable-subscriber-name is optional. If it is not supplied, the subscription is non-durable, meaning
that the message sink misses any messages sent to the topic while the message sink server is off-line.
Durable subscriptions are probably used whenever SQL JMS is used, as most applications that require
the robust persistence of SQL JMS also probably want the functionality of durable subscriptions.
Using Messaging Ports

In the Patch Bay configuration, a component can be configured to send its messages to a destination (or
group of destinations), or to receive its messages from a destination (or group of destinations).
Sometimes, however, you might want a component to have more control over where its messages are
going. For example, a message filter might read in a message and then resend that message to one of
several outputs based on some aspect of the message, such as its JMSType.
ATG
Page 24

Each of those outputs is then configured in Patch Bay to go to a separate set of destinations. In Patch
Bay, those outputs are called ports.
The author of a messaging component chooses the names of the ports that are used by that component.
Whenever a message source (or filter) sends a message, it must specify the name of the port through
which the message is sent. This means that the port names used by the component are hard-coded into
the component.
In Patch Bay, each of a components output ports can be attached to a different set of destinations.
For example:
In this example, it is assumed that TestMessageSource1 is sending messages through at least two ports
i.e. Normal and Emergency. Patch Bay then directs messages coming out of those two ports to different
destinations.
Normal messages go to localdms:/local/NormalMessages.
Emergency messages go to localdms:/local/EmergencyMessages.
ATG
Page 25

If TestMessageSource1 sends a message through some other port name, that message goes nowhere.
A MessageSource must be coded to specify which port it wants a message to use. The port is specified in
both the createMessage and sendMessage methods. For example, following sample sends a
TextMessage through the Normal port.
Notice that the message source does not need to declare what ports it uses. It just sends a message out
using a name, and if Patch Bay has destinations hooked up to that name, the message is sent to those
destinations. It is the responsibility of the message source developer to provide documentation as to
what output ports it uses and in what situations.
Message sinks can also make use of ports. Whenever a message is received, the receiveMessage
method passes in the name of the port through which the message arrived. For example, the DMS
configuration might look something like this.
ATG
Page 26

If a message arrives from localdms:/local/TestMessages, the receiveMessage method is passed
LowPriority as the name of the port. But if a message arrives from sqldms:/PersistentTopic1, the
receiveMessage methods are passed HighPriority. An input port can have many input destinations. If a
message arrives from any of those destinations, it is passed in with the name of its associated input port.
Again, the message sink need not declare what ports it uses. However, the message sink developer
should document what port names the message sink expects to see.
Ports provide another level of flexibility available through Patch Bay, but they should be used with care
because they push some of the hookup responsibility into the messaging component code.
Using the Message Registry

Patch Bay provides a Message Registry, which is a facility that maps message types to the data carried
by those message types. The data in the Message Registry can then be accessed at runtime through a
set of APIs. Application construction tools, such as the ATG Control Center, make use of this data to
present lists of available message types or types of data associated with each message type.
The Message Registry works only for Oracle ATG Web Commerce messages. The important points to
note here is.
The messages are identified by JMSType.
They are ObjectMessages.
The object in the message is a bean whose class is always the same for a given JMSType.
The Message Registry maps the JMSType string to the class of bean held by messages of that type. For
example, messages with JMSType atg.dcs.Purchase are ObjectMessages containing objects of type
atg.dcs.messages.PurchaseMessage.
Using Patch Bay with Other JMS Providers

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 servers JMS provider or a third-party JMS provider, through standard
Patch Bay tags. Consult the providers documentation to determine the values to use.
In addition, you must add the client libraries for the JMS provider to Oracle ATG Web Commerces
CLASSPATH.
The DMS configuration file must declare all providers before it declares message sources and sinks.
For Example
ATG
Page 27
If you specify multiple providers, each must have a unique provider-name. Each <provider> tag can
supply the following fields.
provider-name
This field 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.
Connection Factory
JMS provider is accessed through ConnectionFactories that are identified by JNDI names as specified by
the JMS provider documentation. There are four connection factories available. They are as follow.
ATG
topic-connection-factory-name
Page 28
queue-connection-factory-name
xa-topic-connection-factory-name
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-queueconnection-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. Typically, a Dictionary is created with several properties, and is passed to
the InitialContexts constructor.
For example, a JMS provider might say that the InitialContext must be created using this code.
ATG
Page 29

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.
ATG
Page 30
References
http://docs.oracle.com/cd/E24152_01/Platform.101/ATGPlatformProgGuide/html/s1201atgmessagesystem01.html
ATG
Page 31

ATG Dynamo Messaging System

Загружено:

Сведения о документе

Авторское право

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

ATG Dynamo Messaging System

Загружено:

Авторское право:

e-Com