Women in Technology

Article:		Designing Messaging Applications with Temporary Queues
Subject:		Interesting, but why messaging?
Date:		2007-04-23 05:36:52
From:		zanfolim
I might have missed the point here, but why would someone use messaging for handling a synchronous request? Wouldn´t it be better to just handle it in a synchronous call (xml over http, rmi, or some other remote protocol)? Thanks for the information, Tedi

Showing messages 1 through 1 of 1.

• Interesting, but why messaging?
  2007-04-23 07:53:28  ThribhuvanThakur [View]
  
  
  JMS has proven to be successful for both asynchronous (pub/sub) and synchronous (Point-to-Point) calls. As you mentioned, you could use xml/http, RPC or SOAP or RMI (for java clients) for synchronous calls. In some sense, this is a matter of choice and would depend upon the dependability and the availability of the framework you choose.
  
  If you already using JMS and wanted to support synchronous calls, then JMS is the way to go. JMS promotes building loosely coupled systems and persistence messages (dependability). If your application does not have strict response requirements, JMS will queue the request(either syn or asyn) when the service is temporarily unavailable and the message will persist until the service is ready -- after which your application would continue normally.
  
  Thanks, I should have added more along these lines. I agree.