Messages sent to a queue remain in the queue until the message consumer for that queue consumes them. The JMS API provides a QueueBrowser object that allows you to browse the messages in the queue and display the header values for each message.

The JMS API provides no mechanism for browsing a topic. Messages usually disappear from a topic as soon as they appear: If there are no message consumers to consume them, the JMS provider removes them.

The two administered objects in JMS are connection factories and destinations. These two objects are created administratively.

A JMS connection factory is the object a client uses to create a connection to a provider. A connection factory encapsulates a set of connection configuration parameters that has been defined by an administrator. Each connection factory is an instance of the ConnectionFactory, QueueConnectionFactory, or TopicConnectionFactory interface.  A connection factory is injected as a resource into ConnectionFactory in the JMS client program that tries to produce or consume message.

@Resource(lookup = “jms/DemoConnectionFactory”)

private static ConnectionFactory connectionFactory;

A destination is the object a client uses to specify the target of messages it produces and the source of messages it consumes. In the PTP messaging domain, destinations are called queues. In the pub/sub messaging domain, destinations are called topics. A JMS application can use multiple queues or topics (or both). In addition to injecting a connection factory as a resource in the JMS client program, a destination is also injected as shown below:

@Resource(lookup = “jms/DemoQueue”)

private static Queue queue;

@Resource(lookup = “jms/DemoTopic”)

private static Topic topic;

A JMS message has three parts – A header, properties and a body.

1. A JMS message header contains a number of predefined fields like JMSDestination, JMSMessageID, JMSPriority etc. that contain values used by both clients and providers to identify and route messages.

2. Message properties can be used if we want to send values in addition to those provided by header fields.

3. The JMS API defines five message body types which helps in sending and receiving data in different forms:
   • TextMessage – Message body contains a text message an object of java.lang.String.
   • MapMessage – Message body contains a set of name-value pairs, with names as String objects and values as primitive types.
   • BytesMessage – Message body contains a stream of uninterpreted bytes which is used for literally encoding a body to match an existing message format.
   • StreamMessage – Message body contains a stream of primitive values, filled and read sequentially.
   • ObjectMessage – Message body contains a Serializable Java object.
   • Message – Message body contains nothing. This is composed of header fields and properties only. This message type is useful when a message body is not required.

The basic building blocks of a JMS application are:

• Administered Objects – Objects that are managed administratively rather than programmatically. The two administered objects are connection factories and destinations.
• Connections – Connection object represents a connection with the JMS provider.
• Sessions – Session object is used to send and receive messages.
• Message Producers – Producer is an object that is created by session to send a message to the destination.
• Message Consumers – Consumer is an object that is created by session for reading/consuming the messages from the destination.
• Messages – Message is an object that is used for communication between producers and consumers.

Messaging products are inherently asynchronous. However in JMS, messages can be consumed in either of the two ways:

• Synchronously: A subscriber or a receiver explicitly fetches the message from the destination by calling the receive The receive method can block until a message arrives or can time out if a message does not arrive within a specified time limit.

• Asynchronously: A client can register a message listener with a consumer. A message listener is similar to an event listener. Whenever a message arrives at the destination, the JMS provider delivers the message by calling the listener’s onMessage method, which acts on the contents of the message.

In a publish/subscribe (pub/sub) product or application, clients address messages to a topic. Publishers and subscribers are generally anonymous and can dynamically publish or subscribe to the content hierarchy. The system takes care of distributing the messages arriving from a topic’s multiple publishers to its multiple  subscribers. Topics retain messages only as long as it takes to distribute them to current subscribers.

Pub/sub messaging has the following characteristics:

• Each message can have multiple consumers.
• Publishers and subscribers have a timing dependency. A client that subscribes to a topic can consume only messages published after the client has created a subscription, and the subscriber must continue to be active in order for it to consume messages.

Use pub/sub messaging when each message can be processed by more consumers.

A point-to-point (PTP) product or application is built on the concept of message queues, senders, and receivers. Each message is addressed to a specific queue, and receiving clients extract messages from the queues established to hold their messages. Queues retain all messages sent to them until the messages are consumed or expire.

PTP messaging has the following characteristics:

• Each message has only one consumer.
• A sender and a receiver of a message have no timing dependencies. The receiver can fetch the message whether or not it was running when the client sent the message.
• The receiver acknowledges the successful processing of a message.

Use PTP messaging when every message you send must be processed successfully by one consumer

JMS supports two messaging domains:

1. Point-to-Point Messaging Domain –  A point-to-point (PTP) product or application is built on the concept of message queues, senders, and receivers.
2. Publish/Subscribe Messaging Domain – In a publish/subscribe (pub/sub) product or application, clients address messages to a topic.

A JMS application is composed of the following parts:

• A JMS provider is a messaging system that implements the JMS interfaces and provides administrative and control features. An implementation of the Java EE platform includes a JMS provider.
• JMS clients are the programs or components, written in the Java programming language, that produce and consume messages. Any Java EE application component can act as a JMS client.
• Messages are the objects that communicate information between JMS clients.
• Administered objects are preconfigured JMS objects created by an administrator for the use of clients. The two kinds of JMS administered objects are destinations and connection factories, described in JMS Administered Objects.

The Java Message Service is a Java API that allows applications to create, send, receive, and read messages. The JMS API minimizes the set of concepts a programmer must learn in order to use messaging products but provides enough features to support sophisticated messaging applications.

The JMS API enables communication that is not only loosely coupled but also:
• Asynchronous: A JMS provider can deliver messages to a client as they arrive; a client does not have to request messages in order to receive them.
• Reliable: The JMS API can ensure that a message is delivered once and only once. Lower levels of reliability are available for applications that can afford to miss messages or to receive duplicate messages.