Java / JMS

JMS (Java Messaging Service) is a messaging standard that allows J2EE application components to create, send, receive, and read messages.

JMS defines an enterprise messaging Java API that makes it easy to write business applications that can exchange business data and events asynchronously and reliably in a vendor-agnostic manner.

JMS provides asynchronous messaging while RPC is synchronous.

In RPC the client who invokes the method need to wait for the method to complete the execution and return the control back to the invoker due to its synchronous nature. In JMS the message sender just sends the message to the destination and continues its own processing. The sender does not need to wait for the receiver to respond as JMS is asynchronous.

JMS provides two type of messaging.

• Synchronous
• Asynchronous

In synchronous messaging, client waits for the server to respond to a message before it continue its own processing.

In asynchronous messaging, client does not wait for a message from the server, instead it automatically creates an event to trigger when response received from server. For example, email and text messaging.

Asynchronous messaging.

Reliability. Ensures once and only once message delivery.

Loose coupling. JMS can be used in heterogeneous environments with decoupled systems that can communicate over system boundaries.

There are 2 types of messaging models that JMS provides,

• Point to Point,
• and Publish and Subscribe method.

In point to point communication (one producer and one consumer), the producers and consumers of the message are defined. The producers push the messages in the queues and the receivers retrieve them. It is highly reliable.

In publish and subscribe method (one producer and one or more consumer), the producers publish the message and the subscribers who have subscribed to that topic receive them. In this way, a message may be received, or processed, by multiple consumers. It is unreliable however very fast.

Queuing is used for one to one messaging and it supports point to point messaging model while topic is typically used for one to many messaging and it supports public subscribe model of messaging.

IBM's MQ Series is one of the most popular product used as Message Oriented Middleware. Some of the other products include SonicMQ, iBus etc.

All the J2EE compliant application servers come with its own implementation of JMS.

• JMS provider.
• JMS client.
• Messages.
• Administered objects.
• and Native clients.

The JMS provider handles data conversion, security of the messages and the client triggering. It specifies the level of encryption, security level of the message and the best-data type for the non-JMS client.

JMS can be used to broadcast shutdown messages to clients connected to the Weblogic server on module basis. If an application has many modules, each module behaves like a subscriber to a named topic on the server receive and process the message.

• Session.
• Connection.
• Message.
• Message Producer and Consumer.
• Connection factory and destination.

JMS administered object refers to the preconfigured JMS object created by an administrator for the use of JMS clients and placed in JNDI namespace.

A JMS session is a single-threaded context for sending and receiving JMS messages, could be locally transacted, non-transacted or distributed transacted.

Durable subscription enables the subscriber to receive all messages from a topic, while a non-durable subscription does not make any guarantees about messages sent by others when a client get disconnected by others.

The different types of messages available in JMS API are,

• StreamMessage,
• TextMessage,
• BytesMessage,
• ObjectMessage,
• and MapMessage.

JMS has no support for email operations.

Message is a light weight message having only header and properties and no payload. If receivers are to be notified about an event, and no data needs to be exchanged then using Message can be very efficient.

Byte message is a stream of uninterrupted bytes. It contains an array of primitive bytes in its payload. For the transfer of data between two applications in their native format, byte message is used, which may be not possible with other message types.

StreamMessage carries a stream of Java primitive types as it's payload. Unlike ByteMessage, there are restrictions on the way the data is read to avoid erroneous output. StreamMessage prevents reading a long value as short, something that is allowed in case of BytesMessage. SreamMessage enforces a set of strict conversion rules which actually prevents reading of one primitive type as another.

TextMessage contains instance of java.lang.String as its payload. Thus it is very useful for exchanging textual data. It can also be used for exchanging complex character data such as an XML document.

An ObjectMessage object is used to send a message that contains a serializable object in the Java programming language ("Java object").

A MapMessage holds name-value pair as its payload thus it is similar to the java.util.Properties object of Java. The values can be Java primitives or its wrappers.

An application or process/component that produces and/or receives messages.

JMS producer is a JMS client that creates and sends messages.

JMS consumer is a JMS client that receives messages.

A staging area that contains messages that have been sent and are waiting to be read. Note that, contrary to what the name queue suggests, messages don't have to be delivered in the order sent. If the message driven bean pool contains more than one instance then messages can be processed concurrently and thus it is possible that a later message is processed sooner than an earlier one. A JMS queue guarantees only that each message is processed only once.

A distribution mechanism for publishing messages that are delivered to multiple subscribers.

Messaging is a method of communication between software components or applications. A messaging system is a peer-to-peer facility: A messaging client can send messages to, and receive messages from, any other client. Each client connects to a messaging agent that provides facilities for creating, sending, receiving, and reading messages.

Messaging enables distributed communication that is loosely coupled.

Messaging is different from electronic mail (e-mail), which is a method of communication between people or between software applications and people. Messaging is used for communication between software applications or software components. Messaging is a mechanism by which data can be passed from one application to another application.

JMS is the ideal high-performance messaging platform for intrabusiness messaging, with full programmatic control over quality of service and delivery options.

JavaMail provides lowest common denominator, slow, but human-readable messaging using infrastructure already available on virtually every computing platform.

• Use JNDI to locate administrative objects.
• Locate a single ConnectionFactory object.
• Locate one or more Destination objects.
• Use the ConnectionFactory to create a JMS Connection.
• Use the Connection to create one or more Session(s).
• Use a Session and the Destinations to create the MessageProducers and MessageConsumers needed.
• Perform your communication.

A JMS application can have one or more JMS clients that exchange messages.

Bytes Message stores data in bytes. Thus the message is one contiguous stream of bytes. While the Stream Message maintains a boundary between the different data types stored because it also stores the type information along with the value of the primitive being stored. Bytes Message allows data to be read using any type. Thus even if your payload contains a long value, you can invoke a method to read a short and it will return you something. It will not give you a semantically correct data but the call will succeed in reading the first two bytes of data. This is strictly prohibited in the Stream Message. It maintains the type information of the data being stored and enforces strict conversion rules on the data being read.

• App server creates the server session and stores them in a pool.
• Connection consumer uses the server session to put messages in the session of the JMS.
• Server session is the one that spawns the JMS session.
• Applications written by Application programmers creates the message listener.

The enterprise JavaBeans components and web components can send or receive JMS message asynchronously. In addition, the application clients can also receive message asynchronously. Using message-driven beans, JMS provider can optionally implement the processing of messages. Message-driven beans are a type of enterprise bean that enables the asynchronous consumption of messages.

The operation of sending and receiving message is performed as distributed operation, which allows JMS operations and database accesses within a single transaction.

Yes. After the message is received from Topic or Queue, the message may be converted into a non-java client according to its specification and delivered.

Hi there, thanks for your question. We have Ack (acknowledge) and Nak (not acknowledge) mechanism which may be utilized for this scenario.

When your application does receive a JMS message, process it and finally, it may acknowledge the queue so that it may not receive it again anymore. When the application goes down and it may not acknowledge so QUEUE will replay the message. Hope this helps.

The below answer is taken from Oracle website as this is best fit.

The Java Transaction API (JTA) provides a client API for delimiting distributed transactions and an API for accessing a resource's ability to participate in a distributed transaction. A JMS client may use JTA to delimit distributed transactions. A JMS provider can optionally support distributed transactions via JTA.

The Java Transaction Service (JTS) can be used with the JMS API to form distributed transactions that combine message sends and receives with database updates and other JTS aware services. These services should be handled automatically when a JMS client is run from within an application server such as a J2EE server; however, it is also possible for JMS clients to program them explicitly.

Exclusive type queues, allow multiple consumers to connect however always one becomes active and continue to consume message from the queue. When the active consumer crashes, one of the standby consumers become active and continue to consume/process messages from the queue. Exclusive queues facilitate fault tolerance.

Non-Exclusive queues, allow multiple consumers to connect and also allow them to consume messages in round-robin fashion. Non-Exclusive queue enable load-balancing.

Solace PubSub+ event brokers support the below message delivery modes.

At most once delivery: brokers provide 2 options Direct and non-persistent message delivery/

Atleast once delivery, brokers provide this mode through persistent( or guaranteed) messaging.

Transacted delivery, Solace event brokers supports seession based and XA transactions.

Direct messaging is ideal for high-speed applications that can accept occasional message loss. Producers publish messages to a topic, received by event broker and delivered to consumers with matching topic subscriptions. Direct messages are not persisted nor acknowledged when received.

Persistent (Guaranteed) messaging is never lost; it is persisted in the broker's message spool and acknowledged back to the producers. The publishing is guaranteed in this way. Also, the receiving is guaranteed; Messages are delivered to consumers that are bound to the endpoints that have received the guaranteed messages. Those messages are persisted on the event broker until they expire, or the consuming client acknowledges the messages, indicating they have been consumed.

Message promotion refers to a situation where producer sends DIRECT messages however consumer receives it from a guaranteed message endpoint. These messages are non-persistent where the publisher is never back pressured, consumers, receive the data in the most fault-tolerant(persistent) way.

In this scenario, the consumers receive events using a QUEUE endpoint with mapped topics (or topic subscription). The consumer application will NEVER miss any message even if it's slow/offline, the messages will accumulate in the queue endpoint.

Message demotion is the situation where the producer sends Persistent messages, and there are consumers that want to receive these messages but can tolerate lost messages. These consumers can add a topic subscription matching these messages, and receive them in real-time as Direct messages.

The producer application is sending mission-critical data, but some consumers of this data are not mission-critical, and should never be allowed to affect the publishers.

Message Replay is a feature that allows an event broker to resend messages to new or existing clients that request them, hours or even days after those messages were first received by the event broker. With replay enabled, event brokers store persistent messages in a replay log.

You can use request-reply messaging with Guaranteed Messages when you require a response to each published message from the consuming client that receives those messages. A request-reply messaging model differs from a traditional pub/sub or P2P model, where a message is published to a Topic or Queue and a client can consume the message without providing a reply message in response to the publisher.