Hello there. In this lesson, we will try to understand messaging in Java. So, let's start. Today, in an environment where everyone and everything communicates with each other, software applications must also have the ability to send and receive messages in order to maintain their communication. Messaging solves many architectural challenges, such as reliability, scalability, concurrency, flexibility, and agility. Message-Oriented Middleware also known as MOM, which has been around for a while, uses a special vocabulary. When a message is sent, the software that stores the message and dispatches it is called a provider or sometimes, a broker. The message sender is called a producer and the location where the message is stored is called a destination. The component receiving the message is called a consumer. Any component interested in a message at that particular destination can consume it. In Java EE, the API that deals with these concepts is called Java Message Services (JMS). It has a lot of interfaces and classes that allow you to connect to a provider, create a message, send it, and receive it. JMS doesn't physically carry messages, it's just an API. It requires a provider that is in charge of handling messages.

When running in an EJB container, message-driven beans (MDBs) can be used to receive messages in a container managed way. At a high level a messaging architecture consists of four components. Provider, clients, messages, and administered objects. JMS is only an API, so it needs an underlying implementation to route messages, that is, the provider is also known as the message broker. The provider handles the buffering and delivery of messages. A client is any Java application or component that produces or consumes a message to or from the provider. Client is the generic term for producer, sender, publisher, consumer, receiver, or subscriber. Messages are the objects that clients send to or receive from the provider. A message broker must provide administered objects to the client either through JNDI look ups or injection. The messaging provider enables asynchronous communication by providing a destination where messages can be held until they can be delivered to a client. There are two different types of destinations, each applying to a specific messaging model. The point-to-point, also known as P2P model, and publish-subscribe (pub-sub) model.

Let's start examining these models with P2P. In the point-to-point model, the destination used to hold messages is called a queue. When using point-to-point messaging, one client puts a message on a queue and another client receives the message. Once the message is acknowledged, the message provider removes the message from the queue. In the P2P model, a message travels from a single producer to a single consumer. The model is built around the concept of message queues, senders, and receivers. A queue retains the messages sent by the sender until they are consumed and a sender and a receiver do not have timing dependencies. This means that the sender can produce messages and send them in the queue whenever he likes, and a receiver can consume them whenever he likes. Once the receiver is created, it will get all the messages that were sent to the queue even though sent before its creation. Each message is sent to a specific queue and the receiver extracts the messages from the queue. Queues retain all messages sent until they are consumed or expire. The P2P model is used if there is only one receiver for each message. Note that a queue can have multiple consumers, but once a receiver consumes a message from the queue, it is removed from the queue, and no other consumer can receive it.

In this figure, you can see one sender producing three messages. Remember that P2P doesn't guarantee messages are delivered in any particular order. The order is not defined. A provider might pick them in arrival order, randomly or some other way. In the publish-subscribe (pub-sub) model, the destination is called a topic. When using publish-subscribe messaging, a client publishes a message on a topic and all subscribers to that topic receive the message. In the publish-subscribe model, a single message is sent by a single producer to potentially several consumers. The model is built around the concept of topics, publishers, and subscribers. Consumers are called subscribers because they first need to subscribe to a topic. The provider manages the subscribing-unsubscribing mechanism as it occurs dynamically. The topic retains messages until they are all distributed to all subscribers. Unlike the P2P model, there is a timing dependency between publishers and subscribers. Subscribers do not receive messages sent prior to their subscription, and if the subscriber is inactive for a specified period, it will not receive past messages when it becomes active again.

Note that this can be avoided because the JMS API supports the concept of a durable subscriber. We will talk about these in following lessons. Multiple subscribers can consume the same message. The pub-sub model can be used for broadcast type applications in which a single message is delivered to several consumers. In this figure, the publisher sends three messages that each subscriber will receive in an unidentified order. Let's take a break here. In the next video, we will continue examining components with administered objects. See you in the next video.