Ans: JMS (Java Messaging Service) is a messaging standard that allows J2EE application components to create, send, receive, and read messages. JMS defines an enterprise messaging Java API that makes it easy to write business applications that can exchange business data and events asynchronously and reliably in a vendor-agnostic manner.
Ans: synchronous and asynchronous.
Ans: JMS is asynchronous in nature. Thus not all the pieces need to be up all the time for the application to function as a whole. Even if the receiver is down the MOM will store the messages on it's behalf and will send them once it comes back up. Thus at least a part of application can still function as there is no blocking.
Ans:
Ans:
Ans: In RPC the method invoker waits for the method to finish execution and return the control back to the invoker. Thus it is completely synchronous in nature. While in JMS the message sender just sends the message to the destination and continues it's own processing. The sender does not wait for the receiver to respond. This is asynchronous behavior.
Ans: The JMS provider handles security of the messages, data conversion and the client triggering. The JMS provider specifies the level of encryption and the security level of the message, the best data type for the non-JMS client.
Ans: Each JMS-enabled client must establish the following:
Ans: There are 2 types of messaging models that JMS provides:
Ans: IBM's MQ Series is one of the most popular product used as Message Oriented Middleware. Some of the other products include SonicMQ, iBus etc.
All the J2EE compliant application servers come with its own implementation of JMS.
Ans: A JMS session is a single-threaded context for sending and receiving JMS messages, could be locally transacted, non-transacted or distributed transacted.
Ans: 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.
Ans: 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.
Ans: JMS is typically used in the following scenarios
Ans: Message is a light weight message having only header and properties and no payload. Thus if theIf the receivers are to be notified abt an event, and no data needs to be exchanged then using Message can be very efficient.
Ans: The different types of messages available in JMS API are:
Ans: JMS has no support for email operations.
Ans: Byte message is a stream of uninterrupted bytes. It contains an array of primitive bytes in its payload. For the transfer of data between two applications in their native format, byte message is used, which may be not possible with other message types.
Ans:
Ans: