Java Message Service

Daniel Stollenwerk

1
 Java Message Service: Topic Objectives

After completing this session, you will be able to:

z name the participants involved in the Java Message
Service (JMS)
z explain the basic concepts of JMS
z implement an application for sending a message
z explain the transaction concept used for JMS

© SAP AG 2004 / Daniel Stollenwerk / Java Message Service & Message Driven Beans /
Java Message Service

2
 Asynchronous Messaging

Asynchronous messaging can be compared to e-mail

communication between people

Message-Oriented
Middleware
System 1 System 2

Benefits:
z Better performance: Avoid waiting for replies
z Loosely coupling of systems
z Connection of systems written in different languages

© SAP AG 2004 / Daniel Stollenwerk / Java Message Service & Message Driven Beans /
Java Message Service

„ Systems can communicate via messaging regardless of their implementation; they

only have to agree on a message format
Æ the message format is provided by the message-oriented middleware

3
 Java Message Service

The Java Message Service is a Message-Oriented Middleware

(MOM) and thus allows to decouple producers and consumers
of messages

The JMS API…

z …defines a vendor independent access to various

MOM (JMS based) systems

z …is part of the J2EE platform

z …is defined within the javax.jms package

© SAP AG 2004 / Daniel Stollenwerk / Java Message Service & Message Driven Beans /
Java Message Service

„ JMS was not designed from scratch, but influenced by existing messaging
technologies
‹ One target of JMS was to guarantee backward compatibility
‹ Some points in the specification are left open; JMS Providers may decide on their own if and
how they fulfill some „requirements“

4
 JMS Providers & Clients

JMS Providers provide an implementation of the JMS API

Æ Web Application Server

JMS Clients use the implementation and can be…

z …Producers (send messages)

z …Consumers (receive messages)

© SAP AG 2004 / Daniel Stollenwerk / Java Message Service & Message Driven Beans /
Java Message Service

„ Providers have to stick to Sun‘s specification, but like mentioned before there are
some points where they can decide what to do on their own
„ All applications using the functionalities offered by JMS providers are referred to
as Clients

5
 JMS Destinations

Queue Topic

z Point-To-Point z Publish-Subscribe

z One registered receiver per z Many receivers per message

message possible

z 2 kinds of subscription
„ Non-durable
„ Durable

z Durability by store-and-forward
messaging

z FIFO

© SAP AG 2004 / Daniel Stollenwerk / Java Message Service & Message Driven Beans /
Java Message Service

„ Queue and Topic are concepts which existed before JMS

„ Queues are always durable, i.e. (if the provider does not crash) they deliver every
message they receive. Topics are by default not durable. However, you may set
up durable subscriptions which assure that a message will be delivered to all
receivers regardless if they are online during the first delivery attempt or not.
In both cases durability is ensured by the store-and-forward principle, i.e.
messages are stored in a database and will be delivered at the next possible
opportunity.
„ Both Queues and Topics usually work according to FIFO.

6
 Messaging Models
Point-to-Point / Publish-Subcribe

Queue
Sender Queue
3 2 Receiver
5 4 1
Queue

Topic 1a Topic
Publisher Subscriber 1
2
3 Topic 1b
Topic
JMS Provider Subscriber 2
1 2 3

1. Messages to be sent
2. Messages waiting in the Queue
3. Messages being consumed
© SAP AG 2004 / Daniel Stollenwerk / Java Message Service & Message Driven Beans /
Java Message Service

„ The message numbers indicate a chronological order

„ Queue Messages:
„ Message 1 was sent first and thus is being consumed first.
„ Messages 2 and 3 were sent later and due to this are in the Queue right now.
„ Messages 4 and 5 will be sent to the Queue next.

„ Topic Messages:
‹ Messages 1a and 1b are copies of the original message 1. These copies are sent to all
applications which are subscribed for the topic.
‹ Message 2 will be sent to the according TopicSubscribers next
‹ Message 3 will be sent to the Topic next.

7
 Point-to-point Æ QueueBrowser

z QueueBrowsers can “see“ all

Queue messages on a Queue regardless
JMS Provider
of the order

z QueueBrowsers do NOT consume

messages, i.e. all messages will be
available for the according
Queue receivers
Browser
z A QueueBrowser starts at the end
of the Queue and can then iterate
over the messages; it cannot go
back

© SAP AG 2004 / Daniel Stollenwerk / Java Message Service & Message Driven Beans /
Java Message Service

„ A usual QueueReceiver either consumes a message or cannot read it. If you only
want to look at a message but still let a receiver get it, you will have to use a
QueueBrowser.

8
 Message Format

Header Administrative Information;

key-value-pairs Some may be
disabled to improve
performance

Properties Additional Information;

key-value-pairs

A Message of one of the following types:

• StreamMessage
• MapMessage
Body
• TextMessage
• ObjectMessage
• BytesMessage
• [Message (Æ has no body)]

© SAP AG 2004 / Daniel Stollenwerk / Java Message Service & Message Driven Beans /
Java Message Service

„ Some of the header fields may be disabled to gain a faster processing of the
messages. For example there is a unique ID generated for every message by
default. Switching this off may save some time if an application produces many
messages.
„ The type Message is useful if you only want to send a little information in form of
key-value-pairs because it has no body.

9
 Sending a message
Source code / 1

InitialContext iCtx = new InitialContext();

QueueConnectionFactory queueConnectionFactory = Queue

(QueueConnectionFactory) Connection
Factory
iCtx.lookup("java:comp/env/jms/QConnFactory");

QueueConnection queueConnection = Queue

queueConnectionFactory.createQueueConnection(); Connection

QueueSession queueSession =
queueConnection.createQueueSession(true, 0); Queue
//true -> session is transacted; 0 -> acknowledgement Session
not specified

Queue queue = Queue

(Queue)iCtx.lookup("java:comp/env/jms/myQueue");

Queue
QueueSender queueSender = Sender
queueSession.createSender(queue);
© SAP AG 2004 / Daniel Stollenwerk / Java Message Service & Message Driven Beans /
Java Message Service

„ JNDI paths are SAP specific

„ For sending a message to a Topic you would need some other objects; from JMS
1.1 on the unspecific classes may be used for creation of all objects.
See the following table for the according objects:
‹Sending to a Queue | Sending to a Topic ||
Generic (from JMS 1.1 on)
-------------------------------------------------------------------------------------------------------------------
Queue | Topic || Destination
QueueConnectionFactory | TopicConnectionFactory ||
ConnectionFactory
QueueConnection | TopicConnection ||
Connection
QueueSession | TopicSession || Session
QueueSender | TopicPublisher || Producer

10
 Sending a message
Source code / 2

1 Message message = queueSession.createMessage(); Queue

Connection
Factory
message.setStringProperty("name", "value");
//...
Queue
Connection
2 queueSender.send(message);
Queue
Session

1
Queue
Sender

2
Queue

© SAP AG 2004 / Daniel Stollenwerk / Java Message Service & Message Driven Beans /
Java Message Service

„ In the first step the message is created; in the second one it is being sent to the
Queue
„ Between the first and the second step properties for the Message can be set
„ There is a circle connection between the Queue and the QueueSender; this is
because the Queue object is used for creating the sender and due to this the
messages are sent to the according Queue.

11
 Sending a message
Logical names and Mapping
QueueConnectionFactory queueConnectionFactory =
Source Code (QueueConnectionFactory)
initialContext.lookup("java:comp/env/jms/QConnFactory");

<resource-ref>
Standard
<res-ref-name>jms/QConnFactory</res-ref-name>
deployment ...
descriptor </resource-ref>

Vendor <resource-ref>
<res-ref-name>jms/QConnFactory</res-ref-name>
deployment <res-link>QueueConnectionFactory</res-link>
descriptor </resource-ref>

© SAP AG 2004 / Daniel Stollenwerk / Java Message Service & Message Driven Beans /
Java Message Service

„ In the source code you use logical names for JMS objects. These logical names
have to be mapped to real objects.
„ You have to declare a resource-ref for the ConnectionFactory and a resource-env-
ref for the Destination.
Æ Both have to be declared in the standard deployment descriptor (ejb-jar.xml)
and mapped in the vendor specific one (ejb-j2ee-engine.xml).

12
 Transactions

Sessions may be specified as transacted.

Finishing a transaction automatically starts the next.

Æ call commit() / rollback() on your session

Sending Receiving
App App
4 3

6 5 2 1
Transaction A1 Transaction B1
JMS Provider
Session A Session B

© SAP AG 2004 / Daniel Stollenwerk / Java Message Service & Message Driven Beans /
Java Message Service

„ Transactions usually do not span sending AND receiving messages

Æ if they would, that would mean that the sending app had to wait for the receiving
app…
„ If a sending app uses a transacted session it will be assured that either all or no
messages are delivered to the provider; once they reached the provider the
transaction does not play a role any more.
„ If a receiving app uses a transacted session it will be assured that it either gets all
messages it needs or none at all. The Provider hands the messages over to the
session, it does not matter to it if the session is transacted or not.
„ The numbers indicate a timely order:
‹ Messages 1 and 2 were sent first. The receiving app‘s session is specified as transacted and
that‘s why both messages are sent in a transaction
‹ Messages 3 and 4 were delivered to the JMS Provider. To the broker it does not matter
whether they were sent as a transaction or not.
‹ Messages 5 and 6 are being sent by the sending app, which also uses a transacted session.

13
 Acknowledgement

If a session is not transacted, there are three ways to realize the

acknowledgement:
z AUTO_ACKNOWLEDGE
the session acknowledges the message receipt
Æ clients have to be prepared to receive the last message
more than once
z DUPS_OK_ACKNOWLEDGE
lazy acknowledgement; may result in duplicate messages
Æ clients have to be prepared to receive multiple
messages more than once
z CLIENT_ACKNOWLEDGE
the client acknowledges; the acknowledgement of one
message automatically acknowledges all other messages

Flag: JMSRedelivered (message header) for resent messages

© SAP AG 2004 / Daniel Stollenwerk / Java Message Service & Message Driven Beans /
Java Message Service

„ Regarding the definition also AUTO_ACKNOWLEDGE could be supplied if

DUPS_OK_ACKNOWLEDGE is chosen. So in SAP‘s implementation both are
handled the same way.

14
 Java Message Service: Topic Summary

You should now be able to:

z name the participants involved in the Java Message
Service (JMS)
z explain the basic concepts of JMS
z implement an application for sending a message
z explain the transaction concept used for JMS

© SAP AG 2004 / Daniel Stollenwerk / Java Message Service & Message Driven Beans /
Java Message Service

15