This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
The Java Message Service (JMS) is the standard Java API for enterprise messaging systems. It is a common messaging API and can be used across different types of messaging systems. A Java application connects to an enterprise messaging system using the JMS API. After connecting to an enterprise messaging system, the application uses the facilities of the underlying enterprise messaging system to create messages and to communicate asynchronously with one or more peer applications.
It allows two applications to work together so that they can perform some new form of transaction. JMS and XML, when combined, support the client/server technologies well. They promote reusable integration strategies which can be applied to a wide range of projects. Along with migration and data transformation tools, the integration projects employ some sort of messaging infrastructure. Examples include Progress SonicMQ and IBM MQSeries. These messaging systems allow applications to exchange data as well as events while remaining physically separated. Data and events are exchanged in the form of messages using topics and queues. They provide an abstraction which decouples the participating applications.
Multiple enterprise applications and EISs use adapters to plug in to these message brokers. These adapters are specific to each EIS and enterprise application and developed for a specific message broker product. A J2EE application-that is, an application deployed and operational on a J2EE application server-can access this message broker using a standard JMS provider.
Fig: J2EE Application Server Integration Approach
JMS is an asynchronous message-based interface. It can also be used to access business logic distributed among disparate systems. It enables the following functions:
Point to point and publish/subscribe mechanisms: In point-to-point mechanism, messages are pushed to other applications without their requesting it explicitly. The message will be sent to every other application connected on the other side. Where as in publish-subscribe, the receiver must subscribe to the type of messages they must receive and the message will be sent to only those that are subscribed.
Rhythm independence: Besides functioning in asynchronous mode, JMS frameworks offer the capability of simulating a synchronous request/response mode so that source and target systems do not have to wait for each other and work simultaneously..
Guaranteed information delivery: JMS frameworks offer a transactional mode which ensures message delivery. But the time taken for such transactions could be undetermined
Interoperability between heterogeneous frameworks: The source and destination applications can operate in heterogeneous environments and do not have to handle communication and execution related problems in their respective frameworks.
The JMS API specifies a set of Java interfaces that are part of the common facilities in the javax.jms package.
The Destination interface: It encapsulates the representation of a destination address. An application sends or publishes a message to a destination. Examples of destinations are message queues or topics. A destination is configured as an administered object in the JNDI namespace.
The ConnectionFactory interface: This interface represents a factory of connections to an enterprise messaging system. When instantiated, a ConnectionFactory instance is first configured with the configuration required for creating connections to the messaging system. It is then registered in the JNDI namespace. An application looks up a ConnectionFactory instance and uses it to create a connection to the enterprise messaging system. In this sense, the JMS programming model is similar to the Connector architecture-based application programming model.
The Connection interface: It represents an active connection to an enterprise messaging system. Once a connection is established, a Java application can use the messaging facilities of the connected messaging system.
The Session interface: It represents a single-threaded context for producing and consuming messages. Note that a Session instance can be specified as transacted. A transacted session enables an application to use a transaction model for producing and consuming messages.
The JMSMessage interface: Encapsulates the representation of a message. Each JMS message is composed of header (a set of standard fields) and body sections. The JMS specification lists the standard header fields, which can include destination of the message, delivery mode, message identifier, timestamp, and priority. In addition to the standard fields, a message header can contain application-specific and JMS provider-specified fields. The data in the message body can be described by one of these types: StreamMessage, MapMessage, TextMessage, ObjectMessage, or BytesMessage.
The MessageProducer interface: It is used by a Java application to send messages to a destination. If a Java application creates a MessageProducer without supplying a destination, it must pass a destination as input to each message sent.
The MessageConsumer interface: It is used by a Java application to receive messages from a destination. A Java application can receive messages synchronously by using the synchronous receive option, or it can have a JMS provider deliver the message asynchronously through a MessageListener. A Java application can configure a message selector to filter the messages that are delivered to a consumer.
In addition to these interfaces, JMS specifies the Java interfaces that extend the common interfaces for supporting both publish-subscribe and queue-based point-to-point messaging domains.