I was thinking of doing a simple AJAX framework for myself using some concepts of GUI programming. Actually just one, the event queue.

A more complete description is available on http://www.trajano.net/2006/04/ajax-queue.html

The advantange to performing this approach is that it allows a separation of event handling from the actual page. The development of the AJAX enabled page would be similar to that of a standard GUI application.

Components:

    * one JMS queue that resides on the presentation tier.
    * one servlet to retrieve the queue data from the JMS queue and convert it to XML
    * one servlet to retrieve a secure random number.
    * a Javascript API to retrieve the queue data from the servlet and process the queue events.
    * a JavaScript API to send data to the Servlet tier
    * a Java API to put things into the JMS queue.

This pattern takes advantage of facilities within the J2EE spec and supports clustered environments and multiple windows on the same session. A large chunk of the logic is hidden within the API implementation to make things easier for the developers.

However, there is no concrete implementation of this pattern yet.

Why are you working on inferior methods when it is possible to build reusable Ajax GUI API to build superior online applications at less cost?
http://cbsdf.com/misc_docs/why-gui-api.htm
http://cbsdf.com/misc_docs/gui-api-brief.htm
http://cbsdf.com/technologies/proof-online-GUI-API.htm

Also checkout:
How to build reusable GUI Classes:
http://cbsdf.com/technologies/misc-docs/GUI-Widgets.htm
A quick overview of component process that actually works:
http://cbsdf.com/technologies/misc-docs/CF-LC-Figures.htm

Although it may take an hour are two initially, these technologies save lot of work for you.

However, there is no concrete implementation of this pattern yet.

Kindly let me know when such a thing does materialize. This is like trying to kill an ant with a nuclear weapon.

No offense but did you think about scalability, cost, efficiency just to implement some eye candy functionality?

-Ryan

Seems a rather long chain to go through and like Ryan said, possibly unscalable or inefficient. If there is a way to reduce "moving parts" or the length of the process, it seems like there could be something usable here.

Seems a rather long chain to go through and like Ryan said, possibly unscalable or inefficient. If there is a way to reduce "moving parts" or the length of the process, it seems like there could be something usable here.

The length of the process is there to support clusterability and multiple windows in a single browser session. Granted if you wanted to ignore clusterability, the JMS queue can be replaced by a simple queue implementation running in a singleton on the JVM. That just replaces one part of the equation anyway. There should be some implementation of a JMS queue that is non-clusterable (haven't found one yet, but shouldn't be too hard to make one). Just like HSQLDB has an in-memory implementation which is not shared outside of the JVM. Those can be used in this case. However, if clusterability is required, because you are already in a clustered environment for your servers, this solution should in that environment.

If you send many Ajax requests to the server, it is certainly possible to get the replays in out of order. That is, the webpage may get response to the later Ajax request first. How do you form a right order?

The fact that it is running on JMS guarantees the order.

No offense but did you think about scalability, cost, efficiency just to implement some eye candy functionality?

Cost-wise, everything listed does come with the application server. Scalability, the thing can cluster up horizontally as needed. There is nothing that locks you into a single server or use of session affinity. Efficiency, like I said I haven't tried yet. This is just an idea in progress. If it works, great. You are right, it is like using a nuclear weapon to kill an ant, but at least a nuclear weapon should kill the ant and almost anything larger. Better than a cannonball which has a higher chance of missing.

:))