Before reading this post, please go through my previous at “JMS Administered Objects and JMS Message” to understand some JMS Basic concepts.
In this post we are going to discuss about JMS Architecture that is how JMS Systems interact each other Asynchronously.
Post Brief TOC:
- JMS API Architecture
- Common Steps in a Messaging System
- High-Level JMS Architecture
- Low-Level JMS Architecture
- JMS API Architecture
The following diagram shows a Typical Messaging System/JMS System Architecture in detail:
Both JMS Messaging models( P2P Model and Pub/Sub model) follow the same Architecture. They only differ in Destination types, which are used to exchange messages.
Common Steps in a Messaging System:
- System Administrator uses JMS Provider provided Admin Console and configures all required administered objects like ConnectionFactory and Destinations in JNDI Repository of JMS Provider.
- Application Developer writes Producer and Consumer application and deploy it into Server.
- When client access JMS Sender component(program), JMS Sender lookups Administered Objects from JMS Provider JNDI Register and send messages to the Destination (example Queue).
- JMS Destination (either Queue or Topic) holds all JMS Messages (which are sent by JMS Sender) until they are consumed by Consumer.
- When client access JMS Receiver component(program), JMS Receiver lookups Administered Objects from JMS Provider JNDI Register and receive messages from the Destination (example Queue).
- If the Messaging system(that is Server) crashes for some reasons, then System Administrator uses JMS Provider Admin Console to monitor, find the root cause of the problem, and restore messages into JMS Destinations.
- If there are any undelivered JMS Messages in Destinations (because of some Message Contract between Messaging systems), then System Administrator uses JMS Provider Admin Console to fix those message contract issues and re-send them into Destinations so that target Consumer can receive those messages and process them.
- If we use Durable or Persistent Destinations, then JMS Server uses JMS Stores to store undelivered messages.
- Durable or Persistent Destination stores messages until they deliver to all Subscribers and receive ACK from them.
- JMS Stores may be some kind of Flat Data files or some JMS Servers uses some kind of databases to store messages. Flat Data files may be XML files or text files.
In Java EE 7 based applications, JMS Clients (JMS Sender or Receiver) do not lookup administered objects from JMS Provider.
Instead, JMS Provider will inject them into JMS clients at required places by using Dependency Injection. We will discuss on this technique in advanced topics.
High-Level JMS Architecture
Typical JMS Applications have the following High-Level Architecture.
JAVA Sender Application uses JMS API to create Connection with JMS Server, create JMS Message and Send those to Destination.
In the same way, JAVA Receiver Application uses JMS API to create Connection with JMS Server, receive JMS Message and Send ACK (Acknowledgement) to Sender.
Low-Level JMS Architecture
Typical JMS Applications have the following Low-Level Architecture.
As shown in the above diagram, we can use same JMS Application in any JMS Provider with some minimal configurations at Server side.
JMS API Architecture
JMS API follows almost similar architecture. First Creating Connection with JMS Server then preparing Message/Receiving Message, process Message and closing Connection.
The JMS Sender API Architecture
The JMS Receiver API Architecture
We will discuss JMS Sender and Receiver API in-depth in my coming posts.
That’s it all about JMS Architecture. We will discuss some more JMS Concepts in my coming posts.
Please drop me a comment if you like my post or have any issues/suggestions.