BEA Weblogic Server System

Administration
Module 7 – Java Message Service (JMS)
Objectives

• At the end of this module you will be able to:

– Describe how messages are sent in WebLogic
Server JMS
– Configure JMS administered objects using the
console
– Configure persistent messages
– Use the WLS Administration Console to
monitor JMS
Road Map

1. WebLogic Server JMS Administration

– Messaging Fundamentals
– Point-To-Point (PTP) and Publish/Subscribe
/Pub/Sub) Domain
– Configuring JMS Objects
– Fine-tunning WLS JMS
2. Persistent Messaging
3. Monitoring JMS in WLS
4. Recovering from Failed Servers
5. Configuring Messaging Bridges
Message-Oriented middleware

• Message-oriented middleware is used to refer to

an infrastructure that supports messaging.
• Typical message-oriented middleware
architectures define:
– Message structure
– How to send/receive messages
– Scaling guidelines
Types of Msg-Oriented Middleware

• Message-oriented middleware software falls into

categories that define which client receives a
message.
• WLS-supported categories:
– Point-To-Point (PTP)
– Publish-Subscribe (Pub/Sub)
The Point-To-Point Domain

• The PTP domain allows one client (called a

producer) to send messages to another client
(called a receiver).
PTP Queues

• Many producers can serialize messages to

multiple receivers in a queue.
The Publish/Subscribe Domain

• Message producers (called publishers),

disseminate data to multiple consumers (called
subscribers).
Pub/Sub Topics

• Publishing and subscribing to a topic decouples

producers from consumers.
WebLogic Server JMS features

• WLS implements the JMS 1.1 specification.

• WebLogic Server JMS Supports:
– PTP and Pub/Sub domains
– Guaranteed and transactional message delivery
– Durable subscribers
– Distributed destinations
– Recovery from failed servers
– Server-side consumer session pools
– Limited clustering
JMS Architecture: Connecting
JMS Architecture: Sending Messages
Transacted Messaging

• JMS Clients can use JTA to participate in a

distributed transaction.
• Alternatively JMS Clients can demarcate
transactions local to the JMS Session through a
transacted session.
• Transactional participation is optional.
Administrative Tasks

• Administrative tasks consist of:

– Creating connection factories
– Creating and monitoring JMS servers
– Creating and monitoring JMS destinations
– Creating various JMS stores
– Configuring thresholds and quotas
– Configuring durable subscriptions
– Managed JMS service fail-over
WLS JMS Server

• In WLS the messaging service is implemented

through a JMS Server.
• A JMS Server is responsible of receiving
messages and distributing them.
Create a JMS Server
Configure a JMS Server
Blocking Send Policy

• When a producer sends a message, the destination is checked

against the space quota.
• The JMSConnectionFactoryMBean or the
weblogic.jms.extensions.WLMessageProducer can set
SendTimeout:
– The maximum length of time, in millis, that a sender is
clocked, if there is not enough available space (no quota) on a
destination.
– 0..Long.MAX_VALUE (ms)
– 0 means no blocking
– The default is 10
• The blocking send policy is first-in, first-out (FIFO) or preemptive
Target JMS Server
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.
Create a Connection Factory
Connection Factory Transactions
Connection Factory Flow Control
Destination

• A destination is a lightweight object stored in

JNDI.
• It’s the target on a MOM server for sending or
receiving messages.
• The JMS destination types are:
– Queue
– Topic
Create a Queue destination
Create a Topic destination
Thresholds and Quotas

• Thresholds and Quotas can be set for Server and

Destination objects.
• Quotas are limits that can be defined for JMS
administered objects and include:
– Maximum number of bytes that can be stored
– Maximum number of messages that can be stored
• Thresholds are limits that trigger events when reached
and include:
– Upper and lower values for number of bytes
– Upper and lower values for number of messages
Configure a Threshold and Quota
Message Expiration Policy

• An expiration policy defines an alternate action that is

taken when a message expires.
• The Discard action removes the message; the action is
not logged
• The Log action removes the message; the action writes a
configurable entry to the server log.
• The Redirect action redirects the message to the
ErrorDestination; the message receives a new Expiration
Time of zero (it does not expire again).
Configure Redelivery Attributes
Distributed Queues
Distributed Topics
Configure a Distributed Destination
Target a Distributed Destination
Distributed Destination Threshold and Quota
Section Review

• In this section, we learned how to:

– Identify message oriented middleware
domains (PTP, Pub/Subs)
– Understand WLS JMS messaging for the PTP
and Pub/Subs domains
– Administer JMS from the console
– Fine-tune WLS JMS with thresholds and
quotas
– Use distributed destinations
Road Map

1. WebLogic Server JMS Administration

2. Configure Persistent Messaging
– Persistent and Non persistent Messages
– Persistent Backing Stores using the console
– Durable Subscriptions
– Durable Subscriptions using the console
3. Monitoring JMS in WLS
4. Recovering from Failed Servers
5. Configuring Messaging Bridges
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 Work

• If subscriber client is active, messages are

delivered normally:

• When client becomes active again, its ID is used

to retrieve messages and redelivered.
Configuring Durable Subscriptions

• To configure durable subscriptions administrators need

to:
– Create and configure a JMS Store
– Configure connection factories or destinations to be
persistent
– Associate the JMS Store with JMS Server
• JMS Store can be configured to use either:
– A file store
– A JDBC store (connection pool)
– File persistent store is much faster than JDBC.
Create a JMS File Store
Create a JMS JDBC Store

• To configure JMS JDBC persistence:

– Create a JDBC connection pool
– Create a JMS Store and refer to the JDBC
connection pool
– Refer to the JMS Store from the JMS Server
configuration
• The required infrastructure (tables, and so on)
is created automatically
…Create a JMS JDBC Store
Assign a Store to a JMS Server
Persistent Connection Factory
Configure a Persistent Destination
Section Review

• In this section we discussed:

– The differences between persistent and non-
persistent messages
– How to configure persistent backing stores
using the console
– Managing durable subscriptions
Road Map

1. WebLogic Server JMS Administration

2. Configure Persistent Messaging
3. Monitoring JMS in WLS
– Using the admin console to track JMS
statistics
4. Recovering from Failed Servers
5. Configuring Messaging Bridges
Statistics for JMS Objects

• Statistics are provided for the following JMS

objects:
– JMS Servers
– Connections
– Sessions
– Destinations
– Message producers and message consumers
– JMS Stores
Monitor JMS Servers
…Monitor JMS Servers
Monitor JMS for a WebLogic server
Section Review

• In this section we discussed:

– Statistics that can be monitored for JMS
– Using the Administration Console to view JMS
statistics
Road Map

1. WebLogic Server JMS Administration

2. Configure Persistent Messaging
3. Monitoring JMS in WLS
4. Recovering from Failed Servers
– Distributed Destinations
– Configuring Migratable Services
– Migrating a JMS Service
5. Configuring Messaging Bridges
Failover Issues

• Failover is not automatic and requires

administrator intervention.
• A manual failover involves migrating:
– An entire JMS server
– A persistent store
– A Transaction log
• WLS provides a migratable JMS service that
attempts to deliver outstanding JMS messages.
JMS Migratable Targets

• JMS is an exactly-once service: each JMS Server

can be active on one WLS server in a cluster.
• An administrator can specify a migratable target
within a cluster.
• A JMS Server and each target destination can
migrate to another server, within a cluster.
Configuring Migratable JMS Service

• To configure a migratable JMS service:

– Create a WLS cluster
– Configure a migratable target for the cluster
– Deploy a JMS server to the migratable targe
Configure a Migratable Target
Target JMS Server to a Migratable Target
Migrate Services
Migrate JMS Data

• For the JDBS store:

– If it is on the failed server, migrate the database to
the new server and change the connection pool URL
– If it is not on the failed server, no changes are
required
• For the file store
– Migrate to new server
– Ensure that the pathname is the same on the new
server as original one
• For transactions, also migrate the transaction logs
(discussed later)
Section Review

• In this section, we learned how to:

– Configure migratable services
– Migrate a JMS Service
Road Map

1. WebLogic Server JMS Administration

2. Configure Persistent Messaging
3. Monitoring JMS in WLS
4. Recovering from Failed Servers
5. Configuring Messaging Bridges
– What is a Messaging Bridge?
– Configuring Messaging Bridges
Messaging Bridge

• WLS can interoperate with third-party JMS

providers using a messaging-bridge.
• A messaging bridge:
– Is also know as a JMS Bridge
– Transfers messages between JMS providers
– Permits configuration of quality of service
(QOS), messaging filtering, transaction
semantics, and connection policies
– Use bridge adapters to communicate with
configured destinations
Configure a Bridge Destination
Configure a Messaging Bridge
Configure other Attributes
Bridge Configuration Considerations

• When bridging to other WLS instances:

– If both servers are in one domain, they must have the
same security identities
– If they are in different domains, the security
interoperability mode must be configured
• When bridging to a third-party JMS provider, you must put
the information in the WLS CLASSPATH and your PATH.
Section Review

• In this section, we learned how to:

– Identify a messaging bridge
– Configure a messaging bridge
Lab Exercise 8!!!

• Configure JMS Resources

– Refer to the lab guide for more details.
– Ask the instructor for any clarification.
– The instructor will determine the stop time.
Module Review

• In this module we discussed:

– Messaging concepts
– WebLogic Server’s JMS support
– Configuring JMS servers, queues and topics
– Monitoring JMS servers, queues and topics
– Configuring messaging bridges