Java's implementation of an EMS in the Application Programming Interface (API) format is known as JMS.
JMS allows distributed Java applications to communicate with applications developed in any other technology that understands messaging through asynchronous messages. JMS applications contain a provider, clients, messages, and administrated objects.
Before JMS, each MOM vendor provided application access to its product through its product-specific (proprietary) API, making it available to different programming languages, including Java. JMS changed this notion by providing a standard, portable way for Java programs to send/receive messages through a MOM product. Any application written in JMS can be executed on any MOM that implements the JMS API standards. The JMS API is specified as a set of interfaces as part of the Java API. Hence, all the products that intend to provide JMS behavior will have to deliver the provider to implement JMS-defined interfaces. With programming patterns that allow a program to interface, you should be able to construct a Java application in line with the JMS standards by defining the messaging programs with client applications to exchange information through JMS messaging. Refer to the following diagram:
A JMS provider is a messaging server that supports the creation of connections (multithreaded virtual links to the provider) and sessions (single-threaded contexts for producing and consuming messages).
A JMS client is a Java program that either produces or consumes messages.
JMS messages are objects that communicate information between JMS clients and are composed of a header, some optional properties, and an optional body.
Administered objects are preconfigured JMS objects, such as a connection factory (the object a client uses to create a connection to a provider) and a destination (the object a client uses to specify a target for its messages).
JMS applications are usually developed in either the publish/subscribe or Point-To-Point paradigm.
As you may already know, there are quite a few enterprise messaging products available on the market today that are both open source and licensed. They have all contributed to the definition and development of the JMS concept. JMS defines a common set of features during the implementation of its products and the behavior expected by a matured enterprise application.
The following are the objectives of JMS, as highlighted in its specification:
- Defining a common collection of messaging concepts and features
- Minimizing the number of concepts a developer should learn to develop applications as EMS's
- Improving the application messaging portability
- Reducing the effort involved in implementing a provider
- Providing client interfaces for both Point-To-Point and pub/sub domains