Understanding Weblogic JMS ( Java Message Service )

Understanding Weblogic JMS ( Java Message Service ) 

I would be going to cover below as well as many more topics in my this post 

Weblogic JMS Basic
Weblogic JMS Clustering and High Availability
Weblogic JMS Queue, Topic, Connection Factory, Distributed Queue, Distributed Topic
Weblogic JMS Modules, Submodules
Weblogic JMS server

Basic Concepts


What is JMS and it's relation with weblogic

An enterprise messaging system enables applications to communicate with one another through the exchange of messages

A message is a request, report, and/or event that contains information needed to coordinate communication between different applications 

WebLogic JMS is an enterprise-class messaging system that is tightly integrated into the WebLogic Server platform

The Java Message Service (JMS) is a standard API for accessing enterprise messaging systems. Specifically, JMS:

1.  Enables Java applications sharing a messaging system to exchange messages

2.  Simplifies application development by providing a standard interface for creating, sending, and receiving messages

Basic Flow

So, from above picture, it's clear WebLogic JMS accepts messages from producer applications and delivers them to consumer applications.

Basic JMS components are

1. JMS Server
2. JMS Modules
3. JMS Modules Subdeployments
4. Connection Factory
5. Queue, Topic
6. Distributed Queue, Distributed Topic
7. Persistent Store

JMS Server

JMS servers are environment-related configuration entities that act as management containers for JMS queue and topic resources within JMS modules that are specifically targeted to JMS servers. A JMS server’s primary responsibility for its targeted destinations is to maintain information on what persistent store is used for any persistent messages that arrive on the destinations, and to maintain the states of durable subscribers created on the destinations. 

You can assign/target a JMS server to one and only one Weblogic server

JMS Modules

It’s a group of  configuration resources like queues, topics, and connections factories, distributed queue, distributed topic etc.

You can target JMS module to either individual Weblogic server or to a cluster

JMS Subdeployments

You can define it under a JMS module, it’s a group of JMS resources like queue, topic, connection factory etc which you can deployed on individual or clustered managed servers.

Persistent Store

See my this post

http://weblogicserveradministration.blogspot.com/2011/05/weblogic-persistent-store.html

Below JMS resources are defined under a particular subdeployments (under a particular JMS Module)

Connection Factory

A connection factory is an object that a JMS client (a Java program that uses the JMS API) uses to create a connection with a JMS provider like Weblogic JMS.

A connection factory supports concurrent use, enabling multiple threads to access the object simultaneously. You can use the preconfigured default connection factories provided by WebLogic JMS, or you can configure one or more connection factories to create connections with predefined attributes that suit your application.

Default connection factories, which you can look up using the following JNDI names:

§  weblogic.jms.ConnectionFactory

§  weblogic.jms.XAConnectionFactory

You only need to create a user-defined a connection factory if the settings of the default factories are not suitable for your application. 

It can be targeted to a server(s), cluster, JMS server (s)

By default it select the same target ( server(s), cluster ) as you defined for the JMS module under which you are defining this connection factories and this option disabled by default, means you cannot change target here.

To target it to a server(s), cluster or JMS server(s) by choice, during creation of the connection factory, select “advance targeting” option, Create a subdeployments, and select the targets where you want to deploy this connection factory

Recommended target is the same default one which is selected for parent JMS module

Queue

A single queue can be assigned to one and only one JMS server

To assign a queue to a JMS server, either first creates subdeployments with your targeted JMS server, and during creation of queue select  this  subdeployments, OR during creation of a queue, you have choice to create subdeployments.

Topic

A single topic can be assigned to one and only one JMS server

To assign a topic to a JMS server, either first creates subdeployments with your targeted JMS server, and during creation of topic select this subdeployments, OR during creation of a topic, you have choice to create subdeployments

Distributed Destinations

Distributed queue and Distributed Topic

A distributed queue represents a group of physical queues. If a QueueSender is created using the JNDI name of a distributed queue, any message sent from that QueueSender is delivered to only one physical queue destination. A decision is made every time a message is sent determining which member will get the message. This decision is based on a load-balancing algorithm provided by WebLogic. The default load-balancing scheme is a Round Robin, but you can use a Random load-balancing scheme to distribute messages to destination members at random.

When a QueueReceiver is created using a distributed queue name, it will connect to a physical queue member and, unlike a QueueSender, remain pinned to that destination until the QueueReceiver loses connection.

A distributed topic represents a group of physical topics. JMS client applications can create topic message producers and consumers using a distributed topic name. Your application doesn't know how many physical destination members the distributed topic has, which eliminates any special programming considerations when using this kind of clustered JMS resource.

When the TopicPublisher created with a distributed topic name publishes a message, the message is automatically sent to all members of the distributed topic so all subscribers get the message. Messages are forwarded to all topic member destinations even if a TopicPublisher is created using the JNDI name of a physical topic destination and not the distributed topic JNDI name.

Like connection factory, Distributed queue or topic can be targeted to server(s), cluster, JMS server(s)

By default it select the same target ( server(s), cluster ) as you defined for the JMS module under which you are defining this distributed queue or topic and this option disabled by default, means you cannot change target here.

To target it to a server(s), cluster or JMS server(s) by choice, during creation of the distributed queue or topic, select “advance targeting” option, Create a subdeployments, and select the targets where you want to deploy this distributed queue or topic

Recommended target is the cluster or same default one which is selected for parent JMS module

Note: - you can’t target a distributed queue or topic across different clusters.

Basic architecture is as below