This section gives an overview of JMS.A JMS application is comprised of the following elements:
Administered objects. An administrator of a messaging system provider creates objects that are isolated from the proprietary technologies of the provider.
Providers of MOM products differ significantly in the mechanisms and techniques they use to implement messaging. To keep JMS clients portable, objects that implement the JMS interfaces have to be isolated from the proprietary technologies of a provider.
The mechanism for doing this is administered objects. These objects, which implement JMS interfaces, are created by an administrator of the provider’smessaging system and are placed in the JNDI namespace.
The objects are then retrieved by JMS programs and accessed through the JMS interfaces that they implement. The JMS provider must supply a tool that allows creation of administered objects and their placement in the JNDI namespace.
There are two types of administered objects:
While the administered objects themselves are instances of classes specific to a provider’s implementation, they are retrieved using a portable mechanism (JNDI) and accessed through portable interfaces (JMS). The JMS program only needs to know the JNDI name and the JMS interface type of the administered object; no provider-specific knowledge is required.
JMS defines a set of high-level interfaces that encapsulate various messaging concepts. In turn, these interfaces are further defined and customized for the two messaging domains — PTP and pub/sub.
The high-level interfaces are:
The following table identifies the domain-specific interfaces inherited from each high-level interface.