Comments on Archimedes Trajano: AJAX Queue

Dear Archimedes,We implemented similar pattern for...

2006-05-10T04:59:00.000-04:00

Dear Archimedes,

We implemented similar pattern for one of our Stock market client. Problems that leads to implementation of this patterns are:
1)We have Service oriented architecture, where one of the service provider put restriction on response size i.e. on request for one of the report they will send only 50 records only though a report query will return 2000 records. In response message we have one field which indicate that a response contain more records.
2)If we will do repetitive request from server side code, waiting time will frustrate user for getting final report.
3)In this case AJAX is the only solution.
We are getting response from Server in pre agreed XML format. Using XSLT we will display it on client browser.

Technology stack of this application are: MQ series for messaging, Struts 1.2, JAXB for XML validation and marshalling and unmarshalling of response, AJAX for repetitive call, XSLT at client side for display records.

If you want more details contact me on divyesh_kalavadia@tcs.com

It is good that you proposed a pattern to this type of common problem faced by developer.

Regards,
Divyesh Kalavadia

The server doesn't maintain the state. The server...

2006-04-27T20:47:00.000-04:00

The server doesn't maintain the state. The server just puts messages into a an event queue that the client will pick up.

For example in Google Suggest, while you are typing, you send messages to the server, all the queue provides you is a place to get the responses from the server side based on your request. And since its using JMS as the queue mechanism, it is cluster-safe.

If your concern is due to the need of sending the session ID + request ID type information as a context. The purpose is to prevent the problem of "one response for every request". The context information allows the server to chunk up a bunch of data rather than sending one small piece of data at a time.

All TCP/IP network connections have a context, usually source address+port + destination address+port. It specifies the channel of data to pass information to. You don't want to pass information to the wrong channel. That's how the context information would work.

And like TCP/IP, you can terminate the channel from one side and the data just goes nowhere. In the case of the AjaxQueue, the element in the JMS queue just expires and gets deleted by the queue. The expiration function is also provided to us for free by JMS.

As for undoing the benefits. I don't see how any benefit is lost.

Client still requests for data, client gets the data back so that part is status quo.

The context information you are concerned about is just to provide a something to identify the channel the client should listen for data on.

Network traffic is reduced fo server responses. Since they get bunched up into a larger response.

So no I don't think this will undo anything. It actually improves on it since you speed up the slowest part of your application -- the network.

I think the biggest benefit of AJAX is that you no...

2006-04-27T14:55:00.000-04:00

I think the biggest benefit of AJAX is that you no longer need to maintain state both on the server and in the browser. You can basically reduce server interaction to the client retrieving snippets of raw data from the server without the server caring about the context. It seems like the approach you outlined would once again require that the server and client be in the same state. Don't you think this approach would undo most of the benefits that AJAX has had for web application developement overall?.