Jave Messaging Service (JMS) Interview Questions And Answers - DoAnswers.com

The Java Message Service (JMS) defines the standard for reliable Enterprise Messaging. Enterprise messaging, often also referred to as Messaging Oriented Middleware (MOM), is universally recognized as an essential tool for building enterprise applications. By combining Java technology with enterprise messaging, the JMS API provides a powerful tool for solving enterprise computing problems.

Enterprise messaging provides a reliable, flexible service for the asynchronous exchange of critical business data and events throughout an enterprise. The JMS API adds to this a common API and provider framework that enables the development of portable, message based applications in the Java programming language.

The JMS API improves programmer productivity by defining a common set of messaging concepts and programming strategies that will be supported by all JMS technology-compliant messaging systems.

The JMS API is an integral part of the Java 2, Enterprise Edition (J2EE) platform, and application developers can use messaging with components using J2EE APIs ("J2EE components").

Version 1.1 of the JMS API in the J2EE 1.4 platform has the following features:

1. Message-driven beans enable the asynchronous consumption of JMS messages.

2. Message sends and receives can participate in Java Transaction API (JTA) transactions.

3. J2EE Connector Architecture interfaces that allow JMS implementations from different vendors to be externally plugged into a J2EE 1.4 application server.

The addition of the JMS API enhances the J2EE platform by simplifying enterprise development, allowing loosely coupled, reliable, asynchronous interactions among J2EE components and legacy systems capable of messaging. As a developer, you can easily add new behavior to a J2EE application with existing business events by adding a new message-driven bean to operate on specific business events.

The J2EE platform's Enterprise JavaBeans (EJB) container architecture, moreover, enhances the JMS API in two ways:

1. By allowing for the concurrent consumption of messages

2. By providing support for distributed transactions, so that database updates, message processing, and connections to EIS systems using the J2EE Connector Architecture can all participate in the same transaction context.

Java Message Service: An interface implemented by most J2EE containers to provide point-to-point queueing and topic (publish/subscribe) behavior. JMS is frequently used by EJB's that need to start another process asynchronously.

For example, instead of sending an email directly from an Enterprise JavaBean, the bean may choose to put the message onto a JMS queue to be handled by a Message-Driven Bean (another type of EJB) or another system in the enterprise. This technique allows the EJB to return to handling requests immediately instead of waiting for a potentially lengthy process to complete.

2. Can two different JMS services talk to each other? For instance, if A and B are two different JMS providers, can Provider A send messages directly to Provider B? If not, then can a subscriber to Provider A act as a publisher to Provider B?

The answers are no to the first question and yes to the second. The JMS specification does not require that one JMS provider be able to send messages directly to another provider. However, the specification does require that a JMS client must be able to accept a message created by a different JMS provider, so a message received by a subscriber to Provider A can then be published to Provider B. One caveat is that the publisher to Provider B is not required to handle a JMSReplyTo header that refers to a destination that is specific to Provider A.

The point-to-point model is used when the information is specific to a single client. For example, a client can send a message for a print out, and the server can send information back to this client after completion of the print job.

JMS can be used to broadcast shutdown messages to clients connected to the Weblogic server on a module wise basis. If an application has six modules, each module behaves like a subscriber to a named ic on the server.

5. How does JSP handle run-time exceptions?Answers:You can use the errorPage attribute of the page directive to have uncaught run-time exceptions automatically forwarded to an error processing page. For example:

App server creates the server session and stores them in a pool - Connection consumer uses the server session to put messages in the session of the JMS. - Server session is the one that spawns the JMS session. - Applications written by Application programmers creates the message listener

Retrieve Home Object reference from Naming Service via JNDI. Return Home Object reference to the client. Create me a new EJB Object through Home Object interface. Create EJB Object from the Ejb Object. Return EJB Object reference to the client. Invoke business method using EJB Object reference. Delegate request to Bean (Enterprise Bean).

It is according to the specification that the message sent should be received in the same format. A non-java client cannot receive a message in the form of java object. The provider in between handles the conversion of the data type and the message is transferred to the other end.

JMS provide for two messaging models, publish-and-subscribe and point-to-point queuing.

You can use it in the context of mutithreading but it means JMS is not meant for Multithreading. Its basically meant for object communication.

It will be useful when you are writing some event based applications like Chat Server which needs a publish kind of event mechanism to send messages between the server to the clients who got connected with the server.

Moreover JMS gives Loosely-coupled kind of mechanism when compared with RMI which is tightly-coupled. In JMS there is no need for the destination object to be available online while sending a message from the client to the server. But in RMI it is necessary. So we can use JMS in place of RMI where we need to have loosely-coupled mechanism.