A method of communication between software components or applications is done by "Messaging".
A D V E R T I S E M E N T
A messaging system is a peer-to-peer facility: A messaging client can send messages to, and receive messages from, any other client known as server. Each client will have connections to all messaging agents that provide facilities for creating, sending, and receiving messages.
Elements of JMS:
JMS consists of several elements, some of them are listed below with their functionality.
JMS provider : An implementation of the JMS interface to an Message Oriented Middleware (MOM). Providers are implemented as either a Java JMS implementation or an adapter to a non-Java MOM.
JMS client : A Java-based application or object that produces and/or consumes the messages.
JMS consumer : A JMS client that receives messages.
JMS message : An object that contains the data being transferred between JMS clients.
JMS queue : A staging area that contains messages that have been sent and are waiting to be read. As the name queue suggests, the messages are delivered in the order sent. A message is removed from the queue once it has been read.
JMS topic : A distribution mechanism for publishing messages that are delivered to multiple subscribers.
JMS models:
The two models which are supported by JMS API are: point-to-point or queuing model and publish and subscribe model. In the point-to-point or queuing model, the producer posts messages to a particular queue and the consumer reads messages from the queue which are posted by producer. Here, the producer knows the destination of the message(the consumer) and posts the message directly to the consumer's queue.
And the publish/subscribe model supports publishing messages to a particular message topic. In this model, neither the publisher nor the subscriber know about each other. Zero or more subscribers may register the interest in receiving messages on a particular message topic. A good example for it is "anonymous bulletin board".
Defferent API's used in JMS are:
The JMS API are provided in the Java package javax.jms package. The defferent types of interfaces which are used in JMS and thier descriptions are listed as below:
ConnectionFactory interface : The administered object that a client uses to create a connection to the JMS provider. The code does not need to be changed if the underlying implementation changes, the JMS clients access the connection factory through portable interfaces. Administrators configure the connection factory in the Java Naming and Directory Interface(JNDI) namespace so that JMS clients can look them up. Users will use either a queue connection factory or topic connection factory, depending on the type of message.
Connection interface : Once a connection factory is obtained, the connection to a JMS provider can be created. The connection represents a communication link between the application and the messaging server. Connections allow users to create sessions for sending and receiving messages from a queue or topic, depending on the connection type.
Destination interface : The administered object that encapsulates the identity of a message destination, which is where the messages are delivered and consumed. It is either a topic or a queue. The users discover them using JNDI, and while JMS administrator creates these objects. Like the connection factory, the administrator can create two types of destinations: queues for Point-to-Point and topics for Publish/Subscribe.
MessageConsumer interface : An session creates the object. It receives messages sent to a destination. The consumer can receive messages blocking(synchronously) or non-blocking(asynchronously) for both queue and topic-type messaging.
MessageProducer interface : The object created by a session that sends messages to a destination. The user can create a sender to a specific destination or create a generic sender that specifies the destination at the time the message is sent.
Message interface : An object that is sent between consumers and producers that is, from one application to another. The message has three main parts: First, a message header (required): Contains operational settings to identify and route messages. Second, a set of message properties (optional): Contains additional properties to support compatibility with other providers or users. It can be used to create custom fields or filters (selectors). Third, A message body (optional): Allows users to create five types of messages (text message, map message, bytes message, stream message, and object message).
Session interface : Represents a single-threaded context for sending and receiving messages. A session is single-threaded so that messages are serialized, meaning that messages are received one-by-one in the order sent. The main advantage of a session is that it supports transactions. If the user selects transaction support, the session context holds a group of messages until the transaction is committed, then delivers the messages. Before committing the transaction, the user can cancel the messages using a rollback operation. A session allows users to create message producers to send messages, and message consumers to receive messages.
