The  Java Message Service specification 1.0.2 states that JMS is a set of interfaces and associated semantics that define how a JMS client accesses the facilities of an enterprise messaging product.
Prior to JMS, each MOM vendor provided application access to their product through a proprietary API, often available in multiple languages, including the Java language. JMS provides a standard, portable way for Java programs to send and receive messages through a MOM product. Programs written with JMS will be able to run on any MOM that implements the JMS standard.

The key to JMS portability is the fact that the JMS API is provided by Sun as a set of interfaces. Products that want to provide JMS functionality do so by supplying a provider that implements these interfaces.
As a developer, you build a JMS application by defining a set of messages and a set of client applications that exchange those messages.

JMS objectives

To better understand JMS, it helps to know the objectives set by the authors of the JMS specification.

There are many enterprise messaging products on the market today, and several of the  companies that produce these products were involved in the development of JMS.

These existing systems vary in capability and functionality. The authors knew that JMS would be too complicated and unwieldy if it incorporated all of the features of all existing systems. Likewise, they believed that they could not limit themselves to only the features that all of the systems had in common.

The authors believed that it was important that JMS include all of the functionality required to implement “sophisticated enterprise applications.”

READ  Developing a JMS program

The objectives of JMS, as stated in the specification, are to:

*  Define a common set of messaging concepts and facilities.
*  Minimize the concepts a programmer must learn to use enterprise messaging.
*  Maximize the portability of messaging applications.
*  Minimize the work needed to implement a provider.
*  Provide client interfaces for both point-to-point   and pub/sub domains. “Domains” is the

JMS term for the messaging models discussed earlier. (Note: A provider need not implement both domains.)

What JMS does not provide

The following features, common in MOM products, are not addressed by the JMS specification. While acknowledged by the JMS authors as important for the development of robust messaging applications, these features are considered JMS provider-specific.

JMS providers are free to implement these features in any manner they please, if at all:

* Load balancing and fault tolerance
* Error and advisory system messages and notification
* Administration
* Security
* Wire protocol
* Message type repository