Creating Messaging
Applications with JMS
Chapter 8
Message-oriented-middleware (Asynchronous
communication)
●
An essential tool used by many developers in enterprises around the world.
●
By enabling asynchronous processing between loosely-coupled systems,.
●
Messaging allows developers to build applications that are more efficient, more easily scaled, and more
reliable.
●
Messaging solutions use a concept called queues, or destinations, to facilitate the transfer of data from
one application to another.
●
Developers use queues as an intermediary between applications.
●
Queues store a message's data as it is being transferred from sender to receiver.
Benefits of Asynchronous Communication
●
Using a queue, the sending application (sender) does not need to wait for a response from the
receiving application (receiver). Instead, using messaging, the sender places a message on a queue,
and the receiver retrieves the message from the queue, and then processes the message.
●
Messaging allows for loose coupling. Applications using messaging are said to be loosely coupled
together because the only requirement for them to communicate is a connection to the destination,
and an agreed upon message format. In a messaging system, application components can be
written in many different languages as long as the components adhere to the same message format.
●
The flexibility that this clean separation of applications provides also helps support scalability.
Synchronous Communication
Synchronous
Communication
Using a Queue for
Point-to-point
Messaging.
Using a Topic for
Publish-subscribe
Messaging
Using a Queue for Point-to-point Messaging
●
Point-to-point messaging is when two applications are connected using a queue, and each
message that a producer sends is received by a single consumer.
●
Consumers of a queue use a pull-based model to retrieve new messages.
●
A queue consumer typically must acknowledge successful processing of the message, or it is put
back onto the queue to be retried.
Using a Queue for Point-to-point Messaging
Using a Topic for Publish-subscribe Messaging
●
Publish-subscribe messaging is when multiple applications subscribe to a given topic, and any
message sent to that topic is duplicated and copied to each of the subscribers.
●
Topics are very similar to queues, with the only difference being the number of consumers.
●
Developers refer to consumers of a topic as subscribers.
●
When a new application subscribes to a topic, it then receives any new messages that are sent to
that topic, but it does not receive any previous messages sent to the topic prior to subscription.
●
Publish-subscribe messaging uses a push model, where the messaging provider is responsible for
sending incoming messages to all subscribers.
Using a Topic for Publish-subscribe Messaging
Durable subscription vs non-durable subscription
●
There are two types of subscriptions: durable and non-durable.
●
When using durable subscriptions, if the application disconnects from the topic temporarily, any
messages sent to the topic while the app is disconnected are saved, and delivered the next time the
durable subscriber reconnects.
●
Alternatively, a non-durable subscription does not save any messages received while the subscriber
is disconnected.
JMS Specification in JSR-343
Using Administered Objects for JMS
●
●
A good practice is to maintain JMS destinations and connection factories administratively in the server
configuration “standalone-full.xml” rather than in the application code itself.
The reason for this is that the connection factory and destination objects typically include
environment-specific configuration, such as hosts and ports, as well as potentially sensitive information
like user names or passwords. Also, This data may change frequently.
Components of a JMS Client
●
ConnectionFactory: is an administered object that a client uses to create a connection to the JMS
provider.
●
Destination: is an administered object that a client uses to specify the target address for messages it
sends, or the source address where it should receive messages. A destination can either be a queue or a
topic.
Components of a JMS Client
●
●
●
Connection: is the virtual connection to the JMS provider, and is typically created in the client by using
the JMS API to create a JMS context. It’s totally handled by the system administrator and doesn’t affect
the code.
Session: A JMS session is a single-threaded resource for either sending or receiving messages, and it is
created by a connection. The Session class is typically what creates the message listener, message
producer, and message objects.
Context: A JMS context is the combination of a session and a connection, providing both a direct
connection to the JMS provider as well as a single-threaded class that can be used to send and receive
messages to the provider. When writing a JMS client, typically a developer creates a JMSContext object
from the ConnectionFactory that was injected.
Components of a JMS Client
●
Message Producer: A JMS message producer object is created by a JMS context, and can be used to
send messages to a destination.
●
Message Consumer: A JMS message consumer object is created by a JMS context, and can be used to
receive messages from a destination synchronously.
Components of a JMS Message
●
Headers
Components of a JMS Message
●
Properties
○
●
additional values on a JMS message that are not provided by standard headers. Similar to headers,
properties are key-value pairs, with no limitations on the possible keys a developer can use.
Body
○
○
The JMS API includes six different types of message based on the object type of the message body.
Message, BytesMessage, StreamMessage, TextMessage, ObjectMessage, MapMessage.
Sample Code – JMSContext and Destination
Sample Code – Producer and Consumer
●
Producer
●
Consumer
Guided Exercise – Section 8.6
●
[student@workstation ~]$ lab jms-client setup
Message Driven Beans (MDBs) – Asynchronous
Communication
●
The Java EE specification includes message driven beans (MDBs) as a mechanism to enable
asynchronous consumption of messages from a JMS destination.
●
Unlike other Java beans, MDBs do not expose public methods or functionality for other beans to access
through dependency injection.
●
Instead, all communication with an MDB happens over JMS.
●
Each MDB is configured to listen on a specific JMS destination using an administered object.
MDB Life Cycle
●
●
●
●
●
●
●
The application server, JBoss EAP, is responsible for managing the life cycle of an MDB.
The application server defines a pool of MDBs, which enables concurrent processing of messages.
The server creates the MDBs in the pool automatically on startup.
When the destination that the MDB is listening on receives a new message, the application container
automatically invokes the onMessage method on one of the pre-created MDB instances.
The MessageListener interface, which all MDBs must implement, requires this onMessage method.
Once the MDB is finished processing, the MDB instance is returned to the pool to be reused.
Using a pool of MDBs improves application performance because when the destination receives
messages, the MDB class is already instantiated and ready to process the message immediately.
MDBs Listen to specific queues
MDB Properties
●
MDBs must be completely stateless.
●
MDBs can use injection to access other stateful resources, such as JMS provider connection
information, a database connection, or an instance of another EJB.
●
All instances of an MDB class must be equal, and have no relationship with any specific client,
enabling the application container to choose from them all, enabling concurrency.
How MDB differs from Message Consumer?
●
The developer must manually invoke the MessageConsumer, whereas an MDB is automatically
created.
●
The JMS consumer only allows synchronous checking for new messages and is typically single-threaded
unless the developer manually implements concurrency. In contrast, the MDB is asynchronous and
multi-threaded.
●
For these reasons, MDBs are a more robust solution for Java EE applications that need to consume
messages from a destination asynchronously.
The MessageListener Interface
Using Annotations to Configure an MDB
Guided Exercise – Section 8.8
●
[student@workstation ~]$ lab create-mdb setup
Lab Task – Section 8.9
●
[student@workstation ~]$ lab messaging-lab setup