Learning the JMS Fundamentals

JMS provides a unified API for J2EE enterprise applications to create, send, receive, and process messages using any MOM products. These MOM products, also known as JMS providers, implement JMS API so that Java applications can use the JMS API (interfaces and classes) in a vendor-neutral manner. This allows applications to communicate with each other using messages through any JMS provider. Communications between applications occur in an asynchronous manner, which means that a sender sends a message and does not wait for the response, but continues the flow of execution. This is similar to sending an e-mail message, and you don't have to wait for a reply. The difference between JMS messages and e-mail messages is that JMS is used between applications, whereas e-mail is between users or humans.

Because messaging is peer-to-peer, all users of JMS are referred to as JMS clients. A JMS application consists of a set of application-defined messages and a set of JMS clients that exchange them. Each message consists of a header, which is used for routing purposes, and a body that holds the message content. Messages contain formatted data that describes specific business actions, and through the exchange of these messages, each application tracks the progress of the enterprise.

A destination is a logical channel that encapsulates the addresses of both the sending and receiving endpoints, like a queue or a topic. JMS providers either broadcast a message from a destination to many clients, or send a message to a single client. Similar to our local post office, a JMS provider optionally supports the guaranteed delivery of messages, but does not guarantee the order in which they are received. In many systems, such as financial applications, messages are required to be delivered once and only once. Messages can be delivered based on priority, expiration time, or whether acknowledgment is required.