More JMS Questions
Question:What are different types of messaging?
Answer: There are two kinds of Messaging:
Synchronous Messaging: In Synchronous messaging, there is a client that waits for the server to respond to a message.
Asynchronous Messaging: In Asynchronous messaging, there is a client that does not wait for a message from the server rather an event is used to trigger a message from a server.
Question:What are the core JMS-related objects required for each JMS-enabled application?
Answer:Every JMS-enabled client has to 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 topic 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)
Question: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?
Answer: As per JMS specification,one JMS provider cannot 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.
Question:Why doesn't the JMS API provide end-to-end synchronous message delivery and notification of delivery?
Answer: 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 ensure 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.
Question:How is a java object message delivered to a non-java Client?
Answer: A non-java client cannot receive a message in the form of java object. As per specifications, the message sent should be received in the same format. It is the responsibility of the provider to handle the conversion of the data type and the message is transferred to the other end in its understandable format.
Question:What is MDB and what makes it special?
Answer: A Message Driven Bean(MDB) resembles a Stateless session bean where incoming and out going messages are handled and this ability to communicate asynchronously is the special feature about the Message driven bean.
Question:Give an example of using the publish/subscribe model.
Answer: 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 topic on the server.
Answer: There are two kinds of Messaging:
Synchronous Messaging: In Synchronous messaging, there is a client that waits for the server to respond to a message.
Asynchronous Messaging: In Asynchronous messaging, there is a client that does not wait for a message from the server rather an event is used to trigger a message from a server.
Question:What are the core JMS-related objects required for each JMS-enabled application?
Answer:Every JMS-enabled client has to 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 topic 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)
Question: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?
Answer: As per JMS specification,one JMS provider cannot 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.
Question:Why doesn't the JMS API provide end-to-end synchronous message delivery and notification of delivery?
Answer: 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 ensure 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.
Question:How is a java object message delivered to a non-java Client?
Answer: A non-java client cannot receive a message in the form of java object. As per specifications, the message sent should be received in the same format. It is the responsibility of the provider to handle the conversion of the data type and the message is transferred to the other end in its understandable format.
Question:What is MDB and what makes it special?
Answer: A Message Driven Bean(MDB) resembles a Stateless session bean where incoming and out going messages are handled and this ability to communicate asynchronously is the special feature about the Message driven bean.
Question:Give an example of using the publish/subscribe model.
Answer: 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 topic on the server.
About Dharmendra P
