northshorefiend wrote: > > Say you have a widget on a webpage. The user clicks 'send' and expects a > 'synchronous' response. >
As you probably know, amq.js initiates a long-poll using an AJAX GET request. All JMS messages come down in this get pipeline, and it is always on. This means that it is constantly connected to the server. When there is data available or when a particular timeout value is reached, received data (if any) is processed and the connection is reestablished. The script file also uses an AJAX POST request to execute JMS commands, such as listen/unlisten to a topic or queue and send a JMS message. These requests return immediately with no user-friendly data. So the sending of a JMS message is asynchronous. I have used a lot of request/response mechanisms and my favorite is DWR. I looked at DWR 2.0 carefully when it came out, and it uses a long-poll connection also. However, a method invocation still executes synchronously. This means that if you use reverse AJAX and issue a remote method call you have used your two connections and you cannot process any more AJAX requests until that POST returns. I haven't written a full-fledged JMS application yet. The simple stock board updates and chat applications are straight forward, but what about a full blown business application or game? I envision one topic/queue or hundreds depending on whether I want to remain modular or monolithic. I worry about scale of a modular approach. I'm not sure if JMS is the answer when decoupling is not so important, but I do believe that the amq.js approach to web-based remoting has the capability to be the lowest latency approach to the problem in a pure html/javascript world. Of course, AMF3 blows everyone out of the water. -- View this message in context: http://www.nabble.com/Javascript--%3E-JmsReplyTo%28TemporaryDestination%29--%3E-JSONP-tf3704747s2354.html#a12491061 Sent from the ActiveMQ - User mailing list archive at Nabble.com.