||Designing Messaging Applications with Temporary Queues|
|Subject:||Interesting, but why messaging?|
Response to: Interesting, but why messaging?
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.