REST and JMS have very different processing models. JMS is designed for long connections with large numbers of interactions per connection while REST is designed for a single interaction per connection.
Because of the state that JMS includes, it's best to use a separate REST service in front of ActiveMQ, and have that service perform JMS operations, as needed, rather than trying to use the REST interface built into ActiveMQ. That interface caches an ActiveMQ consumer inside the broker itself (it's stateful). Keeping in mind that "slow consumption" = "very bad thing" in the JMS and ActiveMQ worlds (the JMS spec itself calls out the need for timely processing at all times), such a model is not one I would recommend. Also, REST fits well with idempotent processing due to the possibility of lost connections in the middle of processing requests - consuming or producing a message is not idempotent. It's possible to build idempotent processing "on top of" JMS, and that's what I'm recommending - use a higher-level abstraction/solution. I haven't looked too carefully through the AJAX interface built-in to ActiveMQ, but I'm sure it suffers some issues as well. All of this is consideration for architecture and design. The solution may be fine in light of the weaknesses (e.g. the solution may not care about losing messages, or messages getting stuck). -- View this message in context: http://activemq.2283324.n4.nabble.com/Send-headers-with-ActiveMQ-ajax-client-tp4680774p4680795.html Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
