The basic building blocks of JMS programming models are,
JMS application consists of two parts.
A) Connection factories
The above two objects are used to maintained administratively rather than programmatically. The management of these objects with other administrative tasks is totally different from provider to provider because the technology underlying these objects is too different from one implementation of the JMS API to another. A client application can run with little one no change on more than one implementation of the JMS API because JMS API because JMS client access these objects through interfaces that are portable. The administrator configures administrated objects through JNDI namespace a d JMS clients access them by using resource injection.
A) Connection factories
A JMS connection factory object helps a client uses to create a connection provider and it encapsulate a set of connection configuration parameters that has been defined by an administrator. For each connection factory provide an instance of the connectionFactory, QueueConnectionFactory or TopicConnectionFactory interface.
Resource JNDI name is <tt>jndiname/ConnectionFactory and assign into a ConnectionFactory.
</tt>@Resource(lookup = "jndiname/ConnectionFactory") private static ConnectionFactory connectionFactory;
A destination objects helps a client uses to define the target of messages it produces and the source of messages it consumes. In the PTP messaging domain, destinations are called queues and the pub/sub messaging domain, destinations are called topics. A JMS application can use multiple queues or topics (or both). Destination objects are specific to one domain or the other.
Eg: – The resource (queue and topic) names are mapped to destination resources created in the JNDI namespace.
@Resource(lookup = "jms/Queue") private static Queue queue; @Resource(lookup = "jms/Topic") private static Topic topic;
A JMS connection encapsulates a virtual connection with a JMS provider and it is an open TCP/IP socket between a client and a provider service daemon. For creating one or more session we are using JMS connection.
Syntax: – Connection connection = connectionFactory.createConnection();
We should close all connections before an application completes. Otherwise it leads to resources not to be released by the JMS provider error. Closing a connection means it closes its sessions and their message producers and message consumers.
Syntax: – connection.close();
A single threaded context for producing and consuming messages is called a session. We are using the session for crating the following ones.
After creating a connection object we create a session. The session implements the session interface.
Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
The first argument means that the session is not transacted; the second means that the session automatically acknowledges messages when they have been received successfully.
For creating the transacted session we use the below syntax
Session session = connection.createSession(true, 0);
Here, the first argument indicates that the session is transacted and the second indicates that message acknowledgment is not specified for transacted sessions.
A JMS message producer object is created by a session. It is used for sending messages to a destination. It implements MessageProducer interface.
Eg: – The below codes shows how to create a producer for a Destination object, a Queue object, or a Topic object.
MessageProducer producer = session.createProducer(dest); MessageProducer producer = session.createProducer(queue); MessageProducer producer = session.createProducer(topic);
We can create an unidentified producer by defining null as the argument to createProducer and use an overloaded send method that specifies the destination as the first parameter.
MessageProducer anon_prod = session.createProducer(null); anon_prod.send(dest, message);
After creating the message producer we send messages by using send method.
A JMS message consumer object is created by session. It helps for receiving messages sent to a destination and it implements the MessageConsumer interface. A message consumer permits a JMS client to register interest in a destination with a JMS provider. The JMS provider handles the delivery of messages from a destination to the registered consumers of the destination.
MessageConsumer consumer = session.createConsumer(dest); MessageConsumer consumer = session.createConsumer(queue); MessageConsumer consumer = session.createConsumer(topic);
Message delivery does not begin until you start the connection you created by calling its start method.
connection.start(); Message m = consumer.receive(); connection.start(); Message m = consumer.receive(1000); // time out after a second
We are using message listener for consume a message asynchronously.
A message listener object is acts as an asynchronous event handler for messages. It implements the MessageListener interface and this interface consists of one method called onMessage helps to define the actions to be taken when a message arrives. We register the message listener with a specific MessageConsumer by using the setMessageListener method.
Listener myListener = new Listener(); consumer.setMessageListener(myListener);
After the message listener registration, call the start method on the Connection to begin message delivery.
The JMS message selector helps the messaging application needs to filter the messages it receives. That is it permits a message consumer to define the messages it is interested in. A message selector is a String that contains an expression. The message selector selects any message that has a NewsType property that is set to the value ‘Sports’ or ‘Opinion’.
NewsType = ’Sports’ OR NewsType = ’Opinion’
The JMS message is simple but highly flexible. It permits to create messages that match formats used by non-JMS applications on heterogeneous platforms. A JMS message has three parts.
A JMS message header consists of a number of predefined fields that contain values that both clients and providers use to identify and to route messages each header fields are associated with setter and getter methods which are documented in the description of the Message interface. These are the predefined header fields.
We can create and set properties for messages if you need values in addition to those provided by the header fields and use properties for handle compatibility with other messaging systems, or you can use them to create message selectors. We use either predefined properties or of user-defined properties is optional.
The JMS API defines five message body formats or message types, which permits to send and to receive data in many different forms and provide compatibility with existing messaging formats.
TextMessage message = session.createTextMessage(); message.setText(msg_text); // msg_text is a String producer.send(message);
JMS Queue Browsers
The JMS API provides an object that permits you to browse the message in the queue and display the header value for each message.
QueueBrowser browser = session.createBrowser(queue)