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.

Answer 2

The answer is latency. With JMS the message is available for the consumer the same second it was sent. With any polling solution you will always experience latency at around half of the polling period on average.

This also consumes more CPU and network because polling consumer must wake up every other second and perform the actual call.

Finally you must think about duplicates and transactions. With correctly setup JMS you are guaranteed to receive message exactly ones.

Answer 3

If you want to implement your own queueing service, then feel free. About the only major benefit is simply not having to rely on the third component (the JMS server).

If you're resource concerned about 10 extra threads and 10 extra sockets, then you really have other issues to worry about above and beyond using the JMS server. Neither ads enough incremental cost to matter.

If you don't need queuing at all, then simply call the web service in line and be done with it.

If you implement it yourself, then you have to implement the queue, the persistence and recovery (for when your system goes down at the 29th second and loses the 100 unsent messages), transaction recovery, reconnecting logic, etc.

If I had to do that for a single queue to a single destination with a single producer, and JMS servers cost X thousand dollars a year in licensing fees etc., then yea, I'd certainly think about redoing that bit of logic myself. Or if I didn't want to commit the memory pressure of a JMS server.

But JMS servers are free, they come with my app server, they're configured with a half dozen mouse clicks and they're "fast enough" for most needs. They're ubiquitous infrastructure today.

Just odds are really high it's simply not worth the effort to reinvent this wheel, IMHO.

Answer 4

Well that entirely depends upon your requirements. Having JMS based communication has its own advantages such as:

• non-blocking (asynchronous) messaging
• high performance and reliable load balancing
• high throuput
• fault tolerant (what if the consumes on other end goes offline)

Ofcourse it all comes at a cost, so it all depends on what you need. If you've a low throughput system with only a few messages per minute and can live with either loosing some messages due to communication error then you can very well switch to polling based Webservice.