Java Message Service (JMS)

A publish-subscribe model is based on the message topic concept: Publishers send messages in a topic, and all subscribers of the given topic receive these messages.

One of the principal advantages of JMS messaging is that it's asynchronous. Thus not all the pieces need to be up all the time for the application to function as a whole.

Both synchronous and asynchronous.

JMS provides for two messaging models, publish-and-subscribe and point-to-point queuing.

A point-to-point model is based on the concept of a message queue: Senders send messages into the queue, and the receiver reads messages from this queue. In the point-to-point model, several receivers can exist, attached to the same queue. However, (Message Oriented Middleware)MOM will deliver the message only to one of them. To which depends on the MOM implementation.

The class files should place into WEB-INF/classes folder and the JSP files should place within a separate folder.

Java Message Service: An interface implemented by most J2EE containers to provide point-to-point queueing and topic (publish/subscribe) behavior. JMS is frequently used by EJB's that need to start another process asynchronously.

For example, instead of sending an email directly from an Enterprise JavaBean, the bean may choose to put the message onto a JMS queue to be handled by a Message-Driven Bean (another type of EJB) or another system in the enterprise. This technique allows the EJB to return to handling requests immediately instead of waiting for a potentially lengthy process to complete.

Publish/subscribe (pub/sub). This model allows a client (publisher) to send messages to a JMS topic. These messages are retrieved by other clients (subscribers) (it may happen so that a topic has no subscribers) asynchronously. Pub/sub model requires a broker distributing messages to different consumers.

With publish/subscribe message passing the sending application/client establishes a named topic in the JMS broker/server and publishes messages to this queue. The receiving clients register (specifically, subscribe) via the broker to messages by topic; every subscriber to a topic receives each message published to that topic. There is a one-to-many relationship between the publishing client and the subscribing clients.

A preconfigured JMS object (a resource manager connection factory or a destination) created by an administrator for the use of JMS clients and placed in a JNDI namespace

The main parts of JMS applications are:

--ConnectionFactory and Destination

--Connection

--Session

--MessageProducer

--MessageConsumer

--Message

Synchronous messaging involves a client that waits for the server to respond to a message. So if one end is down the entire communication will fail.

One or more JMS clients that exchange messages.

JMS specification defines a transaction mechanisms allowing clients to send and receive groups of logically bounded messages as a single unit of information. A Session may be marked as transacted. It means that all messages sent in a session are considered as parts of a transaction. A set of messages can be committed (commit() method) or rolled back (rollback() method). If a provider supports distributed transactions, it's recommended to use XAResource API.

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.

A JMS message contains three parts. a header, an optional properties and an optional body.

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

1. Use JNDI to locate administrative objects.

2. Locate a single ConnectionFactory object.

3. Locate one or more Destination objects.

4. Use the ConnectionFactory to create a JMS Connection.

5. Use the Connection to create one or more Session(s).

6. Use a Session and the Destinations to create the MessageProducers and MessageConsumers needed.

7. Perform your communication.

Point-To-Point (PTP). This model allows exchanging messages via queues created for some purposes. A client can send and receive messages from one or several queues. PTP model is easier than pub/sub model.

A durable subscription gives a subscriber the freedom of receiving all messages from a topic, whereas a non-durable subscription doesn't make any guarantees about messages sent by others when a client was disconnected from a topic.