- What Is a Messaging System or Service?
- What Is the JMS API?
- Concepts of JMS Programming
- Summary
- Questions and Answers
This chapter is from the book
This chapter is from the book
This chapter is from the book
What Is the JMS API?
The JMS is a Java Application Programming Interface (API), which allows software applications, components, and objects to create, send, receive, and read messages. Sun Microsystems is a JMS vendor that markets an iPlanet product, but Sun designed and developed JMS specifications in collaboration with JMS vendors, not by itself. Sun also provides developers with reference implementations to test and apply specifications to your projects. In this book, I will use the JMS API Reference Implementation bundled with the Java 2 Platform Enterprise Edition (J2EE) version 1.3 or later to test sample applications instead of commercial JMS products. If you need more information about JMS products, refer to Appendix C, "Java Message Service (JMS) API Vendors." The JMS API enables communication that:
Is loosely coupled
Is asynchronous, which means that a JMS server delivers a message to the client, but the client does not have to read immediately
Is reliable, which means that a JMS server ensures that a message is delivered once and only once
Point-to-Point and Publish-and-Subscribe Messaging
As mentioned in the previous chapter, there are two major messaging types: point-to-point (p2p or PTP) and publish-and-subscribe (pub/sub). They are the fundamentals of MOM and are supported by JMS specifications. (JMS vendors are not required to support both types of messaging, although many of them do.)
Recall that in p2p messaging, the domain (or destination) is called a queue (see Figure 5.2). The sender sends the message to the queue, and the receiver (recipient) takes (or reads) the message from the queue whenever it is ready. Although this seems like peer-to-peer, there can be two or more senders for the same queue.
){kind=small}
Figure
5.2 The p2p messaging service.
This queue is stored in the messaging server or in a relational database if data persistence is required. JMS does not ban using direct messaging, but it uses a queue for p2p messaging.
A human resource application that sends a message to the accounting application about annual salary increases for workers in a factory plant in Wisconsin is an example of p2p messaging.
In the pub/sub messaging type, a messaging domain (destination) is called a topic, a sender is called a publisher, and a receiver is called a subscriber (see Figure 5.3). Publishers send the message to a topic. Subscribers receive all of the messages sent to that topic as long as they subscribe to the topic. In this model, there are one or more publishers and receivers. If one publisher sends a message to the topic, all subscribers receive a copy of the same message. You might need to use this messaging model to notify a group of applications using the same message. An example of the pub/sub messaging model is when a production application sends a message to a NewProduct topic, and subscribers to the NewProduct topic, such as a sales application and a marketing application, receive this message.
This model supports multiple senders and receivers, and applications do not need to act together. Senders called publishers send (publish) their messages at different times, independently from other senders to the topic. Receivers called subscribers also read (subscribe) the messages from the topic, independently from other receivers.
)
Figure
5.3 The pub/sub messaging service.
The JMS API and the J2EE Platform
Sun first released the JMS API in 1998. Its main purpose was to allow Java applications to work with MOM-based products. Because it was found very useful, many MOM vendors adopted and implemented the JMS API. In version 1.2 of the J2EE platform, vendors were not required to implement the JMS API. It was an add-on product, and vendors had to provide a JMS API interface. With version 1.3 of the J2EE platform, the JMS API is an integrated part of the platform. J2EE certified vendors, including Sun Microsystem's own application server product, "iPlanet," must support the JMS API. The JMS API in the J2EE platform version 1.3 has some valuable features:
Enterprise JavaBeans (EJBs) or an enterprise Web component can create, send, and synchronously receive a message.
Message-driven beans, which are new enterprise beans included with version 1.3 of the J2EE platform, allow asynchronous messaging.
Messages that are sent and received can participate in Java Transaction API (JTA) transactions.
Additionally, EJB container architecture provides support for distributed transactions and allows for the concurrent consumption of messages.
The JMS API makes developing enterprise applications easier for developers and allows loosely coupled, synchronous and asynchronous, reliable communications and interactions between J2EE components and other applications capable of messaging. You can develop enterprise applications with new message-driven beans for specific business events in addition to the existing business events.
Another technology, the J2EE Connector, exists within the J2EE platform version 1.3, and it provides tight integration between Java enterprise applications and enterprise information systems (EIS). The JMS API is different from connector technology because it provides loosely coupled interaction between J2EE applications and database servers or information application servers (IAS).