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 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.
- Publishing and subscribing to a topic decouples producers from consumers.
WebLogic Server JMS Features
- WebLogic Server JMS supports:
- PTP and Pub/sub domains
- Guaranteed and transactional message delivery
- Durable subscribers
- Distributed destinations
- Recovery from failed servers
JMS Architecture: Connecting
JMS Architecture: Sending Messages
- 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.
- 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.
Create a JMS Server
Target a JMS Server
Configure a JMS Server
- JMS resources are managed as system modules, application modules, or packaged JDBC resource modules.
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
- 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.
Configure Connection Factory: Default Delivery
Configure Connection Factory: Client
Configure Connection Factory: Transactions
Configure Connection Factory: Flow Control
- 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:
Create a Queue Destination…
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
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.
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…
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.
- The required infrastructure (tables, and so on) is created automatically.
Assign a Store to a JMS Server
Persistent Connection Factory
Monitoring JMS in WLS
Statistics for JMS Objects
- Statistics are provided for the following JMS objects:
- JMS servers
Monitor JMS Servers…
In this chapter, we learned how to:
- Understand messaging concepts
- Understand WebLogic Server’s JMS support
- Configure JMS servers, queues, and topics
- Monitor JMS servers, queues, and topics