Weblogic JMS (Java Message Service)

At the end of this chapter you will be able to:

Understand how WebLogic Server JMS is implemented

Configure JMS administered objects using the administration console

Configure persistent messages

Use the WLS administration console to monitor JMS

Message-Oriented Middleware

Message-oriented middleware refers to an infrastructure that supports messaging.

Typical message-oriented middleware architectures define these elements:
- Message structure
- The way to send and receive messages
- Scaling guidelines

Point-to-Point (PTP) Queue

Many producers can serialize messages to multiple receivers in a queue.

PTP Queue

Publish-Subscribe Topics

Publishing and subscribing to a topic decouple producers from consumers.

Publish subscribe

WebLogic Server JMS Features

WebLogic Server JMS supports:
- PTP and Pub/subdomains
- Guaranteed and transactional message delivery
- Durable subscribers
- Distributed destinations
- Recovery from failed servers

JMS Architecture: Connecting

JMS Architecture

JMS Architecture: Sending Messages

JMS Architecture

Transacted Messaging

A JMS client can use JTA to participate in a distributed transaction.

Alternatively, a JMS client can demarcate transactions local to the JMS Session, through a transacted session.

Participation in a transaction is optional.

Inclined to build a profession as Weblogic Developer? Then here is the blog post on, explore Weblogic Training

Administrative Tasks

Administrative tasks include these:
- Creating and monitoring JMS Servers
- Creating connection factories
- Creating and monitoring destinations
- Creating JMS stores
- Configuring thresholds and quotas
- Configuring durable subscriptions
- Managing JMS service fail-over

WLS JMS Server

In WLS, the messaging service is implemented through a JMS Server.

A JMS Server receives and distributes messages.

WLS JMS Server

Create a JMS Server

JMS Server

Target a JMS Server

JMS Server

Configure a JMS Server

JMS Server

JMS Resources

JMS resources are managed as system modules, application modules, or packaged JDBC resource modules.

JMS Server

Modular JMS Resource Configuration and Deployment...

JMS configurations in WebLogic Server are stored as modules
- Defined by an XML file that conforms to the Weblogic-jmsmd.xsd schema
- Similar to standard J2EE modules

An administrator can create and manage JMS modules as:
- Global system resources
- Global standalone modules
- Modules packaged with an enterprise application

An advantage of modular deployment is simplified migration between environments, such as:
- From development to integration
- From system test to production

You can migrate your application and the required JMS configuration:
- Without opening an EAR file
- Without extensive manual JMS reconfiguration

Connection Factory

A connection factory:
- Encapsulates connection configuration information
- Is used to create pre-configured connections
- Is stored in JNDI
- Can be targeted to servers or clusters

WLS provides a default connection factory that is bound in JNDI to weblogic.jms.ConnectionFactory.

When a new configuration is required, a new connection factory can be created.

JMS Connection factory

Configure Connection Factory: Default Delivery

JMS Connection factory

Configure Connection Factory: Client

JMS Connection factory

Configure Connection Factory: Transactions

JMS Connection factory

Configure Connection Factory: Flow Control

JMS Connection factory

Destination

A destination is a lightweight object stored in JNDI.

It is the target on a JMS Server for sending or receiving messages.

The JMS destination types are:
- Queue
- Topic

Create a Queue Destination…

JMS Connection factory

Threshold and Quota

A threshold and a quota can be set for Server and Destination objects.

A quota is a limit defined for JMS administered objects; it includes these values:
- The maximum number of bytes that can be stored
- The maximum number of messages that can be stored

A threshold is a limit that triggers message paging, flow control, and logged warnings, using:
- Upper and lower values for the number of bytes
- Upper and lower values for the number of messages

Configuring Thresholds and Quotas

Threshold and Quotas

Configuring Persistent Messaging

Durable Subscribers and Subscriptions

Durable subscribers register durable subscriptions to guarantee message delivery even if subscribers are inactive.

A subscriber is considered active if the Java object that represents it exists.

By default, subscribers are non-durable.

Administrators configure:
- Where messages are persisted
- Persistent connection factories and destinations

When to Use Persistent Messaging

Persistent messaging permits messages in memory to be written out to a persistent store.

Configure persistent messaging if:
- Development requires durable subscriptions (use durable subscribers in the application)
- You require that in-progress messages persist across server restarts

How a Durable Subscription Works

If a subscriber client is active, messages are delivered normally:

When the client becomes active again, its ID is used to retrieve and redeliver messages.

Durable subscription

Configure a Durable Subscription

To configure durable subscriptions, an administrator must:
- Create and configure a JMS store
- Configure connection factories or destinations as persistent
- Associate the JMS store with the JMS Server

The JMS store can be configured to use either:
- A file store
- A JDBC store (a connection pool)

Create a JMS File Store…

JMS

Create a JMS JDBC Store…

To configure JMS JDBC persistence:
- Create a JDBC DataSource.
- Create a JMS store and refer to the JDBC DataSource.
- Refer to the JMS store from the JMS Server configuration.