Explore topic-wise InterviewSolutions in .

1. USE JNDI to locate administrative objects.
2. Locate a single ConnectionFactory object.
3. Locate one or more DESTINATION objects.
4. Use the ConnectionFactory to create a JMS Connection.
5. Use the Connection to create one or more Session(s).
6. Use a Session and the Destinations to create the MessageProducers and MessageConsumers needed.
7. Perform your COMMUNICATION. 

1. Use JNDI to locate administrative objects.
2. Locate a single ConnectionFactory object.
3. Locate one or more Destination objects.
4. Use the ConnectionFactory to create a JMS Connection.
5. Use the Connection to create one or more Session(s).
6. Use a Session and the Destinations to create the MessageProducers and MessageConsumers needed.
7. Perform your communication. 

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. So even if the client is down , the messaging will COMPLETE successfully. 

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. So even if the client is down , the messaging will complete successfully. 

Synchronous messaging involves a client that WAITS for the server to respond to a message. So if one END is down the ENTIRE communication will FAIL. 

Synchronous messaging involves a client that waits for the server to respond to a message. So if one end is down the entire communication will fail. 

JMS specification defines a transaction mechanisms allowing clients to SEND and receive groups of logically BOUNDED messages as a single unit of information. A Session may be MARKED as transacted. It means that all messages sent in a session are considered as parts of a transaction. A set of messages can be committed (commit() method) or rolled back (ROLLBACK() method). If a provider supports DISTRIBUTED transactions, it's recommended to use XAResource API. 

JMS specification defines a transaction mechanisms allowing clients to send and receive groups of logically bounded messages as a single unit of information. A Session may be marked as transacted. It means that all messages sent in a session are considered as parts of a transaction. A set of messages can be committed (commit() method) or rolled back (rollback() method). If a provider supports distributed transactions, it's recommended to use XAResource API. 

JMS is the ideal high-performance messaging platform for intrabusiness messaging, with full programmatic control over QUALITY of service and delivery options.
JavaMail provides LOWEST common DENOMINATOR, slow, but human-readable messaging using infrastructure already available on virtually every computing platform.

JMS is the ideal high-performance messaging platform for intrabusiness messaging, with full programmatic control over quality of service and delivery options.
JavaMail provides lowest common denominator, slow, but human-readable messaging using infrastructure already available on virtually every computing platform.

The MAIN parts of JMS applications are:

• ConnectionFactory and Destination
• CONNECTION
• Session
• MessageProducer
• MessageConsumer
• Message 

The main parts of JMS applications are:

A JMS message contains three parts. a HEADER, an optional PROPERTIES and an optional body. 

A JMS message contains three parts. a header, an optional properties and an optional body. 

Publish/subscribe (pub/sub). This MODEL ALLOWS a client (publisher) to send messages to a JMS TOPIC. These messages are retrieved by other CLIENTS (subscribers) (it may happen so that a topic has no subscribers) asynchronously. Pub/sub model requires a broker distributing messages to DIFFERENT consumers. 

Publish/subscribe (pub/sub). This model allows a client (publisher) to send messages to a JMS topic. These messages are retrieved by other clients (subscribers) (it may happen so that a topic has no subscribers) asynchronously. Pub/sub model requires a broker distributing messages to different consumers. 

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. 

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. 

A publish-subscribe MODEL is based on the MESSAGE topic CONCEPT: PUBLISHERS send messages in a topic, and all subscribers of the given topic RECEIVE these messages. 

A publish-subscribe model is based on the message topic concept: Publishers send messages in a topic, and all subscribers of the given topic receive these messages. 

A point-to-point model is based on the concept of a MESSAGE QUEUE: Senders send messages into the queue, and the receiver reads messages from this queue. In the point-to-point model, several receivers can EXIST, attached to the same queue. However, (Message Oriented Middleware)MOM will deliver the message only to ONE of them. To which depends on the MOM IMPLEMENTATION. 

A point-to-point model is based on the concept of a message queue: Senders send messages into the queue, and the receiver reads messages from this queue. In the point-to-point model, several receivers can exist, attached to the same queue. However, (Message Oriented Middleware)MOM will deliver the message only to one of them. To which depends on the MOM implementation. 

The Java Message Service is a Java API that allows applications to create, send, RECEIVE, and read messages. Designed by Sun and several partner companies, the JMS API defines a common set of interfaces and ASSOCIATED semantics that allow programs written in the Java programming language to communicate with other messaging implementations.
The JMS API minimizes the set of concepts a programmer must learn to use messaging products but PROVIDES enough features to support sophisticated messaging applications. It ALSO STRIVES to maximize the portability of JMS applications across JMS providers in the same messaging domain.
The JMS API enables communication that is not only loosely coupled but also
Asynchronous. A JMS provider can deliver messages to a client as they arrive; a client does not have to request messages in order to receive them.
Reliable. The JMS API can ensure that a message is delivered once and only once. Lower levels of reliability are available for applications that can afford to miss messages or to receive duplicate messages.
The JMS Specification was first published in August 1998. The latest version of the JMS Specification is Version 1.1, which was released in April 2002. You can download a copy of the Specification from the JMS Web site, http://java.sun.com/products/jms/.

The Java Message Service is a Java API that allows applications to create, send, receive, and read messages. Designed by Sun and several partner companies, the JMS API defines a common set of interfaces and associated semantics that allow programs written in the Java programming language to communicate with other messaging implementations.
The JMS API minimizes the set of concepts a programmer must learn to use messaging products but provides enough features to support sophisticated messaging applications. It also strives to maximize the portability of JMS applications across JMS providers in the same messaging domain.
The JMS API enables communication that is not only loosely coupled but also
Asynchronous. A JMS provider can deliver messages to a client as they arrive; a client does not have to request messages in order to receive them.
Reliable. The JMS API can ensure that a message is delivered once and only once. Lower levels of reliability are available for applications that can afford to miss messages or to receive duplicate messages.
The JMS Specification was first published in August 1998. The latest version of the JMS Specification is Version 1.1, which was released in April 2002. You can download a copy of the Specification from the JMS Web site, http://java.sun.com/products/jms/.

•JMS provider
•JMS client
•Messages
•Administered objects
•Native CLIENTS

•JMS provider
•JMS client
•Messages
•Administered objects
•Native clients

Example for point to point model, would be a print out. When you select a print-out option, your system sends the MESSAGE to the server, and once the print-out is taken out, again this server will SEND the message back to you. Point to point model is used, when the INFORMATION is SPECIFIC to a single CLIENT.

Example for point to point model, would be a print out. When you select a print-out option, your system sends the message to the server, and once the print-out is taken out, again this server will send the message back to you. Point to point model is used, when the information is specific to a single client.

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.

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.

Durable subscription GIVES a subscriber the freedom of RECEIVING all messages from a topic, while a non-durable subscription does not MAKE any guarantees about messages SENT by others when a client get DISCONNECTED by others.

Durable subscription gives a subscriber the freedom of receiving all messages from a topic, while a non-durable subscription does not make any guarantees about messages sent by others when a client get disconnected by others.

•Session
•Connection
•Message
•Message Producer
•Message Consumer
•Connection FACTORY and DESTINATION

•Session
•Connection
•Message
•Message Producer
•Message Consumer
•Connection factory and destination

The CORE JMS-related OBJECTS that are required are –
•The CONNECTION object
•One or more sessions within a connection that provides a context for MESSAGE SENDING and receiving.
•A topic or queue object within a session representing the destination within the message broker.
•Appropriate sender or publisher or receiver within a session.

The core JMS-related objects that are required are –
•The connection object
•One or more sessions within a connection that provides a context for message sending and receiving.
•A topic or queue object within a session representing the destination within the message broker.
•Appropriate sender or publisher or receiver within a session.

The encryption and DECRYPTION of the MESSAGES is HANDLED by JMS provider and not JMS specifications. Sonic MQ by Progress SOFTWARE is a leading JMS provider and they do encryption through encryption mechanisms called Quality of Protection.

The encryption and decryption of the messages is handled by JMS provider and not JMS specifications. Sonic MQ by Progress Software is a leading JMS provider and they do encryption through encryption mechanisms called Quality of Protection.

First of all, after RECEIVING the message from Topic or QUEUE, the message has to be converted into a non-java client ACCORDING to their specification. The message once converted to non-java client, it can be delivered.

First of all, after receiving the message from Topic or Queue, the message has to be converted into a non-java client according to their specification. The message once converted to non-java client, it can be delivered.

The MOM ( MESSAGE Oriented Middleware) is a software that works as an INTERMEDIATE between two communicating components. It is placed between the CLIENT and server, MOM PROVIDES the FACILITY of passing message by using the technique queuing. Until the client does not request to read the message, the messages will be stored in queue. By using this technique, the software component can work independently of time.

The MOM ( Message Oriented Middleware) is a software that works as an intermediate between two communicating components. It is placed between the client and server, MOM provides the facility of passing message by using the technique queuing. Until the client does not request to read the message, the messages will be stored in queue. By using this technique, the software component can work independently of time.

The TYPES of MESSAGES that are SUPPORTED by JMS are
•Stream Messages
•Text Messages
•Map Messages
•Bytes Messages
•Object Messages

The types of messages that are supported by JMS are
•Stream Messages
•Text Messages
•Map Messages
•Bytes Messages
•Object Messages

The application CLIENT like enterprise JavaBeans components and web components can SEND or receive JMS MESSAGE synchronously. In addition, the application clients can also receive message asynchronously. With the help of message-driven beans, JMS provider can optionally implement the PROCESSING of messages. Message-driven beans are a type of enterprise bean that enables the asynchronous consumption of messages.
The operation of sending and RECEIVING message is carried out in distributed operation, which allows JMS operations and database accesses within a single transaction.

The application client like enterprise JavaBeans components and web components can send or receive JMS message synchronously. In addition, the application clients can also receive message asynchronously. With the help of message-driven beans, JMS provider can optionally implement the processing of messages. Message-driven beans are a type of enterprise bean that enables the asynchronous consumption of messages.
The operation of sending and receiving message is carried out in distributed operation, which allows JMS operations and database accesses within a single transaction.

The basic DIFFERENCE between JMS and RPC lies in the way they message. JMS uses asynchronous messaging type while, RPC CREATES SYNCHRONOUS messaging type. The method invoker in RPC, waits for the method to finish execution and RETURN back the control to the invoker. In JMS the message sender just sends the message to the destination and continues its own processing.

The basic difference between JMS and RPC lies in the way they message. JMS uses asynchronous messaging type while, RPC creates synchronous messaging type. The method invoker in RPC, waits for the method to finish execution and return back the control to the invoker. In JMS the message sender just sends the message to the destination and continues its own processing.

•With the help of APPLICATION server, the server session is CREATED and it stores them in a pool
•To put messages in JMS session, CONNECTION consumer, uses the Server session
•Server session is the ONE that creates the JMS session
•Application written by Application programmers creates the MESSAGE listener.

•With the help of Application server, the server session is created and it stores them in a pool
•To put messages in JMS session, connection consumer, uses the Server session
•Server session is the one that creates the JMS session
•Application written by Application programmers creates the message listener.

JMS has no INHERENT SUPPORT for EMAIL OPERATIONS.

JMS has no inherent support for email operations.

JMS CLIENT is a LANGUAGE PROGRAM that sends or RECEIVES messages.

JMS client is a language program that sends or receives messages.

P2P MODEL is HIGHLY RELIABLE and it is used in a one-to-one situation, while subscribe model is used in one-to-many situation. It is very fast but LESS reliable.

P2P model is highly reliable and it is used in a one-to-one situation, while subscribe model is used in one-to-many situation. It is very fast but less reliable.

The different types of messages available in JMS API are Message, TEXTMESSAGE, BYTESMESSAGE, ObjectMessage and MapMessage.

The different types of messages available in JMS API are Message, TextMessage, BytesMessage, ObjectMessage and MapMessage.

There are two types of MESSAGING MODELS that JMS provides –

• Point to point QUEUING
• SECOND one is PUBLIC and subscribe

There are two types of messaging models that JMS provides –

Synchronous: In this type of messaging, client waits for the server to respond to a message. Ex: TELEPHONE call, two WAY radio communication.
Asynchronous: In this type of messaging, client does not WAIT for a message from the server, but automatically an event is created to trigger a message from a server. Ex: EMAIL, text messaging, BLOG posting.

Synchronous: In this type of messaging, client waits for the server to respond to a message. Ex: Telephone call, two way radio communication.
Asynchronous: In this type of messaging, client does not wait for a message from the server, but automatically an event is created to trigger a message from a server. Ex: email, text messaging, blog posting.

JMS provides both TYPE of MESSAGING,

• SYNCHRONOUS
• ASYNCHRONOUS

JMS provides both type of messaging,