Question 16 :
What are the three components of a Message ?
A jms message has three components
1. A header
2. Properties (Optional)
3. A body (Optional)
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.
Question 17 :
What is the difference between queue and topic?
A connection is created between the client and the server from a connection factory. Connections can be shared by several threads. The user credentials are supplied at this level. It is probably common for a client application to share access to a single connection to the server (unless different security credentials are required for different destinations). A session is created from a connection. The session may only be used by one thread at one time. The user credentials are inherited from the parent connection.
It is probably common for each MessageProducer (TopicPublisher or QueueSender) or MessageConsumer (TopicSubscriber or QueueReceiver) to have their own session due to the threading restriction. You can look at it like a tree. At the top you have a connection factory, beneath this you have your connections and then beneath the connections you have sessions. The leaves of the tree are the JMS actors (MessageProducers and MessageConsumers).
Both work on 2 different comminication models. Queue is point-to-point and topic is publish-subscriber.
In queues, one message can be consumed by only one client. But in the topics, one message can be consumed by many clients. Both are separate domains in MOM.
Queue represent Point-To-Point domain and Topic represent Pub/Sub domain
A point-to-point (PTP) product or application is built around the concept of message queues, senders, and receivers. Each message is addressed to a specific queue, and receiving clients extract messages from the queue(s) established to hold their messages. Queues retain all messages sent to them until the messages are consumed or until the messages expire.
In a publish/subscribe (pub/sub) product or application, clients address messages to a topic. Publishers and subscribers are generally anonymous and may dynamically publish or subscribe to the content hierarchy. The system takes care of distributing the messages arriving from a topic's multiple publishers to its multiple subscribers. Topics retain messages only as long as it takes to distribute them to current subscribers.
Question 18 :
What are the types of messaging?
There are two kinds of Messaging. Synchronous messaging involves a client that waits for the server to respond to a message. 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.
Question 19 :
What is the difference between Point to Point and Publish/Subscribe ?
In point-to-point, messages are sent via queues. Messages are put onto the queues by the message producers (the clients). The message consumer is responsible for pulling the message from the queue. Point-to-point is typically used when a given message must be processed (received) only once by a given consumer. In this way, there is only one consumer of the given message.
In publish-and-subscribe, messages are sent through topics. Messages are published to topics by the message producers. The messages may be received by any consumers that subscribe to the given topic. In this way, a message may be received, or processed, by multiple consumers.
Question 20 :
Why doesn't the JMS API provide end-to-end synchronous message delivery and notification of delivery?
Some messaging systems provide synchronous delivery to destinations as a mechanism for implementing reliable applications. Some systems provide clients with various forms of delivery notification so that the clients can detect dropped or ignored messages. This is not the model defined by the JMS API. JMS API messaging provides guaranteed delivery via the once-and-only-once delivery semantics of PERSISTENT messages. In addition, message consumers can insure reliable processing of messages by using either CLIENT_ACKNOWLEDGE mode or transacted sessions. This achieves reliable delivery with minimum synchronization and is the enterprise messaging model most vendors and developers prefer. The JMS API does not define a schema of systems messages (such as delivery notifications). If an application requires acknowledgment of message receipt, it can define an application-level acknowledgment message.