How does JMS Receive work internally?

Question

I've been researching various communication technologies/architectures/patterns/implementations (read: buzzwords) including Web Services (WCF, Axis2), ESBs, SOA, and wanted to know more about JMS with regards to messaging.

Conceptually, JMS sounds simple. My take is that it's an intermediate broker which manages messages from publishers and routes them to appropriate subscribers. This is done by queueing messages as they are published, and dequeuing them as they are received.

Question 1: Is my basic understanding of JMS correct?

One of the things that bugs me when reading about technologies is when a certain level of (intentional or unintentional) hand-waving is done about a feature.

Based on my basic understanding, a JMS Provider must be running in order to send or receive messages. My assumption on publishing is that the JMS Provider simply waits until a message is published, then stores it in a queue (memory or database-backed, depending on implementation). However, I am not quite sure how receive works.

Question 2: Does receive (typically) block if no messages are avaiable?

Question 2b: If so, how is blocking achieved? Does the client continuously poll for messages? Does the server simply not respond until a message is published (how does this work without timing out?) Does the provider initiate a call to the recipient?

Question 2c: If not, how does one ensure messages are received in a timely manner, without impacting performance?

The basic description seems to lean towards a single JMS provider to ensure that messages are centrally managed not lost. I can see scaling being an issue.

Question 3: How does JMS scale?

When scaling, I can see there being complexities to ensure that a single message is delivered to all appropriate subscribers, regardless of which physical server receives the message.

Question 3b: How does a JMS implementation ensure reliable delivery in a scaled environment?

Please note that although these questions are related to JMS, they likely apply to any messaging infrastructure. I welcome answers specific to JMS as well as those which are more general or even specific to another technology.

Answer 1

I am trying to answer few questions based on my experience on JMS.

Answer 1:- JMS is Java Message Service API; it provides uniform interface for Java clients to access messaging framework. Beneath JMS API is a JMS compliant messaging provider, for example WebSphere MQ provider. JMS supports transport of a payload over any messaging protocol to destinations viz. Queue and Topic. These are basics of JMS.

How does receive work? JMS specification provides two important classes:- MessageConsumer and MessageListener. MessageConsumer class allows a JMS client to synchronously receive JMS messages by calling any of its receive() method. This call will be blocking thread until a message is received. Otherwise, asynchronous receive can be made by registering an object of MessageListener with MessageConsumer. It is JMSProvider who get to know that a message is arrived in its local destination and its job is to deliver messages to either polling message consumer thread or non-polling registered message listener thread.

Answer 2:- MessageConsumer API has two variants of receive: receive() and receive(long timeout). The latter variant lets MessageConsumer thread block until message arrives within specific timeout period or else it times out.

Different messaging frameworks might implement blocking feature in different ways. As JMS objects are JNDI administered objects and provider specific proxy objects are returned to JMS client, it means that the client is unaware of how blocking is happening in background. A particular messaging framework may choose message consumer thread polling after a particular time period. Alternatively, it may choose to block until notification is sent.

I am not sure if you are looking answer for a particular JMS compliant messaging framework?

Answer 3:- I guess by JMS scaling you mean ability to have many publishers/subscribers, many destinations over multiple physical machines. JMS scaling requires support of underlying messaging provider to support some sort of clustering/fail over. As such JMS specification does not support scalability. Correct me if I am wrong on this? For example I have worked on JMS compliant WebSphere MQ which provides clustering support.