I am trying to build ActiveMQ Ajax client and have been able to reach a point where I can connect to the apache servicemix running on my machine.
The problem is now that the apache camel route I want to call through this ajax client expects certain headers, but I am not sure if we can send headers in the ajax request for activemq.
I see that in amq.js there is a function called sendJMSMessage which actually sends headers and is actually called by sendMessage function of amq.js. But when I am trying to call that method from my js I am getting method does not exists error.
Could you please help me and direct me what should I do to send the headers.
Is this for an application that will run in production? If so, I recommend avoiding the ajax interface into ActiveMQ and consider a REST service, or something similar in its place. With Camel, setting up a rest endpoint is fairly simple.
With that said, you may be able to find a solution here. Just keep in mind that this feature may not get much usage (please correct me if I'm wrong), which means it will be hard to get help with it.
> Is this for an application that will run in production? If so, I recommend
> avoiding the ajax interface into ActiveMQ and consider a REST service, or
> something similar in its place. With Camel, setting up a rest endpoint is
> fairly simple.
> With that said, you may be able to find a solution here. Just keep in mind
> that this feature may not get much usage (please correct me if I'm wrong),
> which means it will be hard to get help with it.
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Send-headers-with-ActiveMQ-ajax-client-tp4680774p4680785.html > Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
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).
Many thanks for your reply, yes REST is an option but in our project there is no plan of exposing a Webservice using camel, that was the reason I went for AJAX. It wen well until I got stuck at the headers requirement.
The Ajax client needs to pass the message as well as the servicename as the header or probably a property of that message.
Where servicename would describe, one of many services with their respective routing slip.
Oh, that's in the web-demo code, not the actual ActiveMQ code.
You might get away with a local copy of the same. Another option, that is likely more straight-forward and a safer approach, is to create a message with the necessary details all in the body, send to a separate queue which is consumed by a camel route, and have the camel route create a new message using the body and headers specified in the original.
With all that said, please do consider this path carefully. Most of the JMS guarantees will be lost using AJAX when all the possible timings of lost connection between the Ajax client and broker are considered.