Can JMS messaging be replaced by a polling Webservice call?

Question

Existing scenario: Two Apps are communicating using Queues. One of them is always the Producer, and other is always the consumer.

The 'Producer' generates and saves data in its own storage. It then sends it to the Consumer, using Queues.

The more I read about JMS consumer (and listener) implementation (using Spring), it seems like we can easily replace Messaging with Polling Webservice calls.

This is because all that the JMS Listeners do is keep thread(s) open, listening to the Queues. So if your JMS listener ConnectionFactory is set to have 10 connections, you will have 10 blocking threads.

So, instead of keeping 10 threads open, why not just poll every 30 seconds or so using 1 thread. That one Poll can instruct the WebService to sent 100 data items (or more) to it in the response.

Answer 1

Both of these are just abstractions. If you think about it its just a socket you are pushing data over. What is really different are the guarantees each abstraction makes. Crazy enough you can actually have SOAP Web Services that are serviced over the JMS and JMS that uses HTTP as the transport.

In Short JMS specifies a set of guarantees related to messaging(acknowledgement, redelivery, failover,etc.). Web Services(the way most people think about them) are composed mainly of a thin set of specifications describing message format(SOAP,JSON) layered on top of specifications describing transport(HTTP).

Regarding Polling. Most JMS implementations are push models. The subscribers register with the broker and as messages arrive they are pushed to subscribers. Push models have higher throughput than pull models.