61.. What is Durable subscription?

You must not cache session handles in stateless session beans that operate in transactions started by a client of the bean. Caching handles in this way causes the bean to be returned to the pool while the session is still involved in the transaction. Also, you should not cache non-durable subscribers due to the restriction mentioned above.
A non-durable subscriber can only be used in the same transactional context (for example, a global transaction or an unspecified transaction context) that existed when the subscriber was created. For more information about this context restriction, see The effect of transaction context on non-durable subscribers.
Using durable subscriptions with the default messaging provider. A durable subscription on a JMS topic enables a subscriber to receive a copy of all messages published to that topic, even after periods of time when the subscriber is not connected to the server. Therefore, subscriber applications can operate disconnected from the server for long periods of time, and then reconnect to the server and process messages that were published during their absence. If an application creates a durable subscription, it is added to the runtime list that administrators can display and act on through the administrative console.
Each durable subscription is given a unique identifier, clientID##subName where:
clientID
The client identifier used to associate a connection and its objects with the messages maintained for applications (as clients of the JMS provider). You should use a naming convention that helps you identify the applications, in case you need to relate durable subscriptions to the associated applications for runtime administration.
subName The subscription name used to uniquely identify a durable subscription within a given client identifier.
For durable subscriptions created by message-driven beans, these values are set on the JMS activationSpec. For other durable subscriptions, the client identifier is set on the JMS connection factory, and the subscription name is set by the application on the createDurableSubscriber operation.
To create a durable subscription to a topic, an application uses the createDurableSubscriber operation defined in the JMS API:
public TopicSubscriber createDurableSubscriber(Topic topic,
java.lang.String subName,
java.lang.String messageSelector,
boolean noLocal)
throws JMSException
Topic
The name of the JMS topic to subscribe to. This is the name of an object supporting the javax.jms.Topic interfaces, such as found by looking up a suitable JNDI entry.
subName The name used to identify this subscription.
messageSelector Only messages with properties matching the message selector expression are delivered to consumers. A value of null or an empty string indicates that all messages should be delivered.
noLocal If set to true, this prevents the delivery of messages published on the same connection as the durable subscriber.
Applications can use a two argument form of createDurableSubscriber that takes only topic and subName parameters. This alternative call directly invokes the four argument version shown above, but sets messageSelector to null (so all messages are delivered) and sets noLocal to false (so messages published on the connection are delivered). For example, to create a durable subscription to the topic called myTopic, with the subscription name of mySubscription.

62.Whats is a subtle difference between a "durable" JMS message and a "persistent" JMS message ?

A "durable" JMS message is applicable only to publish/subscribe paradigm and the "persistent" JMS message is applicable to both "Point-to-Point" & "publish/subcribe" paradigms.
Let's look at both:
A " durable message " is a message where the JMS server will hold on to a message if the subscriber is temporarily unavaliable. So the durability is defined by the relationship between a "Topc Subscriber" and the "JMS Server". Durability is applicable only to publish/Subscribe paradigm. For this to happen subscribers need to register themselves with a unique " client id ". A " persistent message " is a message that defines the relationship between a "Message Producer" and the "JMS Server". This can be established for both
point-to-point and publish/subscribe. This has to do with the guaranteed once only delivery of the message by persisting the message after it has been recieved from the message producer.

63.How to create Temporary Destinations ?

Normally, you create JMS destinations--queues and topics--administratively rather than programmatically. Your JMS provider includes a tool that you use to create and remove destinations, and it is common for destinations to be long-lasting. The JMS API also enables you to create destinations--TemporaryQueue and TemporaryTopic objects--that last only for the duration of the connection in which they are created. You create these destinations dynamically using the Session.createTemporaryQueue and the Session.createTemporaryTopic methods.
The only message consumers that can consume from a temporary destination are those created by the same connection that created the destination. Any message producer can send to the temporary destination. If you close the connection that a temporary destination belongs to, the destination is closed and its contents are lost.
You can use temporary destinations to implement a simple request/reply mechanism. If you create a temporary destination and specify it as the value of the JMSReplyTo message header field when you send a message, then the consumer of the message can use the value of the JMSReplyTo field as the destination to which it sends a reply. The consumer can also reference the original request by setting the JMSCorrelationID header field of the reply message to the value of the JMSMessageID header field of the request. For example, an onMessage method can create a session so that it can send a reply to the message it receives. It can use code such as the following:
producer = session.createProducer(msg.getJMSReplyTo());
replyMsg = session.createTextMessage("Consumer " +"processed message: " + msg.getText());
replyMsg.setJMSCorrelationID(msg.getJMSMessageID());
producer.send(replyMsg);

64.How may messaging models do JMS provide for and what are they?

JMS provides for two messaging models, publish-and-subscribe and point-to-point queuing.

65.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.

66.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.

67.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.

68.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 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)

69.What is the Role of the JMS Provider?

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.

70.How does a typical client perform the communication?

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

71.Give an example of using the point-to-point model?

The point-to-point model is used when the information is specific to a single client. For example, a client can send a message for a print out, and the server can send information back to this client after completion of the print job.

72.Does Tomcat support JMS (Java Messaging Service)?

Tomcat is just a servlet container, not an EJB container nor an application server, so it does not contains any JMS basic support. However, there’s nothing stopping you from using another JMS provider.

73.Is it possible to send email messages using JMS?

JMS has no inherent support for email operations.

74.How do I communicate between two clients that are on different machines on a network using JMS? I want to use a standalone application for communicating between the machine and I want to pass the message using JMS.?

You can make two JMS client applications, say AppA and AppB. Make AppA listen to topic ‘forA’. Make AppB listen to topic ‘forB’.
If AppA sends a message to topic ‘forB’, AppB will receive it. If AppB sends a message to topic ‘forA’, AppA will receive it.
For sample code etc, try downloading SonicMQ (as a JMS server) and go through the samples.

75.Is there any relationship between javax.jms.Message and javax.mail.Message?

There is no direct relationship between javax.mail.Message and javax.jms.Message. If your requirement is to map (correlate) them, here is what you can do:

• From JMS domain to JavaMail domain (a javax.jms.Message is received):
  A JMS topic/queue can be associated with one or many e-mail id(s). The JMS Message Header can be mapped to ‘custom’ JavaMail Message Header.
  The JMS Message Body can be associated with the JavaMail Message body.
  A JavaMail client application should be able to process these ‘custom’ headers and the content of the message body.
• From JavaMail domain to JMS domain (a javax.mail.Message is received):
  An e-mail id can be associated with one or more JMS topics/queues. The JavaMail Message Header can be mapped to ‘custom’ JMS Message Header.
  The JavaMail Message Body can be associated with the JMS Message body.
  The JMS client application should be able to process these ‘custom’ headers and the content of the message body.

76.Is it possible to acknowledge individual messages on a queue without affecting previously received, but as yet unacknowledged, messages?

If you acknowledge a message, all previously received messages will also be acknowledged. From the javax.jms.Message Javadoc, the acknowledge method will “Acknowledge this and all previous messages received.”
So the answer to your question is no, if what you meant by “affecting” is not-yet acknowledged.
I suggest an alternative. You should look at javax.jms.QueueBrowser to review queued messages. QueueBrowser has getEnumeration, which “Gets an enumeration for browsing the current queue messages in the order they would be received”.

77.What encryption options are there for sending messages through JMS?

Encryption is not handled by the JMS specification. It is left to the JMS provider to implement and provide encryption and decryption of messages. These days, Progress Software’s SonicMQ is a leading JMS provider and they have a robust encryption mechanism called Quality of Protection. They also provide an SSL-related feature, which also has build in encryption.

78.How does the Application server handle the JMS Connection?

• Application server creates the server session and stores them in a pool.
• Connection consumer uses the server session to put messages in the session of the JMS.
• Server session is the one that spawns the JMS session.
• Applications written by Application programmers creates the message listener.

79.?

80.?