Basics of Java Message Service - II

In previous Article, we have read about basics of JMS with some simple programs. Here we shall continue with the introduction of basic programming elements, and objects of JMS Design. These basic objects are required for every JMS program. So it is important to understand these from conceptual and working aspect.

These JMS objects are called Administered JMS objects. JMS API has come in existence to provide a standard for messaging service and to standardize the interfaces and working of various messaging service providers. But, as many of the service providers were already in market, so it was not possible to define a strict protocol. Hence, JMS defines a compratively flexible protocol which take care of client protability by providing the standard interface, however, at the same time given ample flexbility to service providers to continue with their existence implementation by just changing the interfaces. JMS Administered objects are the standard objects specified by JMS API which every service provider should implement. These are important to ensure client portability. Beyond these administered objects, service providers are free to provide their custom implementation.

Following is the list of important Administered Objects:

Object Type - Implementing Objects
  1. ConnectionFactory - TopicFactory, QueueFactory
  2. Connection - TopicConnection, QueueConnection
  3. Session - TopicSession, QueueSession
  4. MessageProducer - TopicProducer, QueueProducer
  5. MessageConsumer - TopicSubscriber, QueueConsumer
In brief, every JMS user needs to create a connection factory first. Connection Factory can be specific to Topic or Queue messaging module depending upon requirements. JMS API defines a separate concrete object for Topic/Queue messaging model correspodning to each interface. So once we have connection factor, it can be used to ask Connection. Connection is like a factory for session objects. Session is a kind of separate working area for each client of JMS. One connection may provide multiple sessions, and each session will have its separate working space. After getting session, next step will be to create message producer and message consumer. Session acts as factory for message producers and consumers, so it is used to create message producers and consumers. Once message producer and consumers are created, now, these can be used to produce and consume the messages. Certainly, if you want to use Topic Publish/Subscribe model, you need to use Topic type of objects or otherwise you will use Queue type of objects.

Basics of Java Message Service - I

In perivous article, we have read about basics of messaging system and come to know that how messaging can help in quite flexible and abstract integration of various software applications. Now let us move further towards basics of Java Message Service (JMS), which can help us to implement the messaging concepts read till now.

JMS is a Messaging Oriented Middleware. Middleware is the software used to connect more than one software applications (distributed also) in quite flexible manner. Middleware can be of two typs, RPC based and messaging based. RPC based Middleware is one which provided synchronous integration between two software applications. Whereas, Messaging based Middleware (MOM) is one which inetgrate two software applications asynchronously using messaging concept. Certainly nowadays, MOM are quite popular where client can not wait for response from service and hence want a asynchronous request processing. JMS comes in this category. JMS can also be used for synchronous communication with some efforts, however, that is not something for which JMS comes in existence. It is devised specially to strengthen and standardize the messaging oriented middleware software.

Before JMS, there were many messaging solutions in market from various Industry players, like from IBM, Progress Software and Fiorano etc. Problem was, these products were not following any standard specification. So suppose, today you find that Software A is meeting your requirement and use it for implementation. After one year, you met with some new requirements, and then found that A can not meet these requirements but B has these new features. But, now it was not easy to replace the messaging software due to lack of any standard API implementation. JMS has solved this problem by defining a standard to implement the messaging systems with an abstract API. Now, clients can easily switch from one to other vendor anytime as per requirement without disturbing the implementation of application.

Hence JMS is a specification which defines an API allowing java based applications to utilize the features of any JMS compliant MOM software, without sticking to any one implementation. It provides a right level of abstraction from proprietary implementation of MOM systems. JMS is not an actual product. Actual products are still coming from indepdent software product companies like IBM, Progress Software etc. However, now, these products are adhering to the protocol defined by JMS specification, and hence following a standard approach with many of their specific advance features like load balancing, persistence, fault tolerance and administration etc. JMS is also implemented in J2EE in form of Message Driven Beans. Hence it becomes a intrinsic part of J2EE specification now.