Javascript -> JmsReplyTo(TemporaryDestination) -> JSONP

[northshorefiend <sp...@JamesAshepherd.com>]

Say you have a widget on a webpage. The user clicks 'send' and expects a
'synchronous' response.

You could just register a listener with amq.js and wait asynchronously for a
reply.

But the user complains it is not fast enough.

So what about using the JSONP idea to contact the server outside of the GET
poll and the POST batch sending that amq.js does?

On the server side I expect a Servlet would be needed that forwarded the
message and waited for a reply using a TemporaryDestination then do the
JSONP thing.

I think this would entail a split in the taxonomy of widgets: a widget that
uses the above style could not also be updated via AJAX polling, as I
believe the AJAX response could be queued in the server side whilst a JSONP
response updates the widget. When the AJAX response returns it would contain
stale data.

I suppose it is a bit subversive.

I have another idea, but I can't make a link to a future post here :-)
-- 
View this message in context: http://www.nabble.com/Javascript--%3E-JmsReplyTo%28TemporaryDestination%29--%3E-JSONP-tf3704747s2354.html#a10360381
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Javascript -> JmsReplyTo(TemporaryDestination) -> JSONP

[chago <na...@visualxs.com>]

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.

Re: Javascript -> JmsReplyTo(TemporaryDestination) -> JSONP

[northshorefiend <sp...@JamesAshepherd.com>]

northshorefiend wrote:
> 
> Say you have a widget on a webpage. The user clicks 'send' and expects a
> 'synchronous' response.
> 
> [..]
> 
> I have another idea, but I can't make a link to a future post here :-)
> 

While testing my other idea I found the delay I was talking about only
happens in Camino. Testing between Safari and Firefox everything works as I
initially thought it should.
-- 
View this message in context: http://www.nabble.com/Javascript--%3E-JmsReplyTo%28TemporaryDestination%29--%3E-JSONP-tf3704747s2354.html#a10362735
Sent from the ActiveMQ - User mailing list archive at Nabble.com.