Home | About Us | Contact Us | Terms Of Use
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.
11. What are the core JMS-related objects required for each JMS-enabled application?
Each JMS-enabled client must establish the following:
A connection object provided by the JMS server (the message broker)
Within a connection, one or more sessions, which provide a context for message sending and receiving
Within a session, either a queue or ic object representing the destination (the message staging area) within the message broker
Within a session, the appropriate sender or publisher or receiver or subscriber object (depending on whether the client is a message producer or consumer and uses a point-to-point or publish/subscribe strategy, respectively)
Within a session, a message object (to send or to receive)
12. What are the different types of messages available in the JMS API?
Message, TextMessage, BytesMessage, StreamMessage, ObjectMessage, MapMessage are the different messages available in the JMS API.
13. What are the three components of a Message ?
A JMS message consists of three parts:
Message header
For message identification. For example, the header is used to determine if a given message is appropriate for a "subscriber"
Properties
For application-specific, provider-specific, and optional header fields
Body
Holds the content of the message. Several formats are supported, including TextMessage, which wrap a simple String, that wrap arbitrary Java objects (which must be serializable). Other formats are supported as well.
14. What are the types of messaging?
There are two kinds of Messaging.
Synchronous Messaging: Synchronous messaging involves a client that waits for the server to respond to a message.
Asynchronous Messaging: Asynchronous messaging involves a client that does not wait for a message from the server. An event is used to trigger a message from a server.
15. What are the various message types supported by JMS?
Stream Messages -- Group of Java Primitives
Map Messages -- Name Value Pairs. Name being a string& Value being a java primitive
Text Messages -- String messages (since being widely used a separate messaging Type has been supported)
Object Messages -- Group of serialize able java object
Bytes Message -- Stream of uninterrupted bytes
16. What is MDB and What is the special feature of that?
MDB is Message driven bean, which very much resembles the Stateless session bean. The incoming and out going messages can be handled by the Message driven bean. The ability to communicate asynchronously is the special feature about the Message driven bean.
17. What is messaging?
Messaging is a mechanism by which data can be passed from one application to another application.
18. What is point-to-point messaging?
With point-to-point message passing the sending application/client establishes a named message queue in the JMS broker/server and sends messages to this queue. The receiving client registers with the broker to receive messages posted to this queue. There is a one-to-one relationship between the sending and receiving clients.
19. What is publish/subscribe messaging?
With publish/subscribe message passing the sending application/client establishes a named topic in the JMS broker/server and publishes messages to this queue. The receiving clients register (specifically, subscribe) via the broker to messages by topic; every subscriber to a topic receives each message published to that topic. There is a one-to-many relationship between the publishing client and the subscribing clients.
20. What is the advantage of persistent message delivery compared to nonpersistent delivery?
If the JMS server experiences a failure, for example, a power outage, any message that it is holding in primary storage potentially could be lost. With persistent storage, the JMS server logs every message to secondary storage. (The logging occurs on the front end, that is, as part of handling the send operation from the message producing client.) The logged message is removed from secondary storage only after it has been successfully delivered to all consuming clients .