Académique Documents
Professionnel Documents
Culture Documents
Page 1
Table of Contents
ATG INTRODUCTION
JMS INTRODUCTION
JMS Destinations
Message Persistence
7
7
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
17
18
19
20
20
21
21
24
27
27
REFERENCES
ATG
31
Page 2
Abbreviation
DAS
DAF
DSS
DPS
DRP
GSS
LM
Load Manager
CM
Connection Module
RMI
DCC
SBS
UDP
User Datagram Protocol alternative protocol to TCP/IP, (usually used for broadcasting)
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
Queue
Page 5
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
ATG
Page 8
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.
ATG
Page 11
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.
ATG
Page 13
messagePollSchedule
property
of
the
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.
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
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
ATG
Page 17
ATG
Page 18
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
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
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
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
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
ATG
Page 24
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
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
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.
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
ATG
Page 30
References
http://docs.oracle.com/cd/E24152_01/Platform.101/ATGPlatformProgGuide/html/s1201atgmessagesystem01.html
ATG
Page 31