What is the Asynchronous Web, and How is it Revolutionary?

Discussions

News: What is the Asynchronous Web, and How is it Revolutionary?

  1. The Asynchronous Web is fundamentally different than other web interactions, and that difference revolutionizes how web applications behave. In the Asynchronous Web it is possible to deliver spontaneous presentation changes to the user as the state of a dynamic system changes, without the need for the user to interact with the interface. This article describes how Java EE can be used to support asynchronous web activities. Read article

    Threaded Messages (21)

  2. Link to article[ Go to top ]

    Just in case anyone have problem with the mouse pointing on the link, the url to the article is: http://www.theserverside.com/tt/articles/article.tss?l=WhatistheAsynchronousWeb
  3. Nothing New Here[ Go to top ]

    The focus of this article is based on the "Java Standards" such as Servlets and even JSP and JSF. None of which are prepared for asynchronous processing or streaming, and in the case of Servlets (including Jetty continuations) the existing proposals contain much overhead and are heavily compromised by backward compatibility issues. If you want to use the asynchronous we now take a look at Simple (http://www.simplframework.org/). It supports asynchronous processing and response streaming, all without only a handful of threads. Recent benchmarks show it can scale better than both Jetty and Glassfish Grizzly, showing twice the throughput. http://www.simpleframework.org/performance/grizzly/run1/ScalabilityApacheBench.png http://www.simpleframework.org/performance/grizzly/run2/ScalabilityApacheBench.png
  4. URL - oops![ Go to top ]

    I do it all the time.... should be http://www.simpleframework.org/ Jim
  5. Shameless plug: The Atmosphere Framework build on top of all the current Comet native API Container. That way you can write portable Comet/Async application across existing WebContainer -> http://atmosphere.dev.java.net. About SimpleFramework: great framework, bogus benchmarks ;-)
  6. What to you base this on, empirical analysis I would hope. In such a case I would like to see the results of your tests? Results for Simple are available, not only for tools such as Apache Bench, but also for Faban (http://faban.sunsource.net/), both show a vast difference in performance. If there is a dispute here, then anyone is welcome to perform the tests. https://simpleweb.svn.sourceforge.net/svnroot/simpleweb/trunk/faban/ Testing through Jersey, a framework common to both, Simple is twice as fast. With regards to learning private API, there is almost nothing to learn. Its even simpler that Servlets and is not compromised by legacy junk.
  7. I'am really sorry to say that... But JSP/JSF is not a good solution for Ajax (even only synchronous part) and what futhermore what you call "asynchronous" web. And "asynchronous web" is not a good term because you goal is just to make client state synchronized with server state, nothing more that any heavy GUI framwork or mainframe system can do for more than 20 years even in text mode. JSP/JSF design is based on more that 10 year old concept of HTML templates compiled and designed for dynamic page generation BUT static templates. You cannot change easily a JSP at excution time, nor you can't easily change HTML client content without heavy javascript coding. You can think of application mostly classic with no AJAX and "asynchronous web" at all. In this simple case. JSP/JSP is an acceptable solution. And incidently, theses type of applications will not be real time at all or just use an applet / flash application for the dynamic part... If you go ajax, a simple solution based on checking server at a regular interval will be sufficient for 99% of use case. To make a descent interractive application you need : - a good client side framework dealing all with all user actions and on screen update. May it be Flash or an ajax based solution... JSF/JSP does not help here... At best you can use JSP to generate your XML responses for your AJAX needs. A bazooka to kill an ant. - or a good client/sever side framework that will make the client an server side model of the GUI consistent. It's less interractive and slower than flash or full javascript GUI but you can code faster and it can be an alternative. In this case you need a framework that will allow you to alter the GUI model both from the client or the server side. Modifiing menus, toolbar, windows/tab/pane or simply the state of a single checkbox or text. JSF/JSP is not capable to do that nicely. What it can offer is just a set tag of specialised components or small HMTL part that will be refreshed upon request. You can't implement a true observer pattern that is so common to most GUI. Even with asynchronous web solutions, it will not help to update any arbitrary part of your client seamlessy, efficiently. JSP/JSP is already dead. JSF was just an attempt from SUN to bypass the de facto standard for this type of application on JAVA : Struts. Just checks web projects... It's still struts for old fashion web... And for real web 2.0 there is no real winner. It will take a long time, but the whole HTML templating technology will fade. Fully object GUI model like you have in swing is the future. XML description of the GUI is acceptable for fast designing/prototyping, but with an easy access to the dynamic object model.
  8. Nice article.
  9. Such an article should consider describing some HTML 5, webSocket - http://www.w3.org/TR/2009/WD-websockets-20090423/ - and related upcoming technologies or already available bridge like Kaazing.
  10. Java5 come with built-in HTTP Client mechanism. How to: On first time, when client reach the server, server store client info like ip and port. From this moment server able to send responce\request to client. In this way client and server fully asynchronous.
  11. I didn't read the spec, however, does this approach work with client behind NAT/firewall?
  12. Synchronicity through the request-response-paradigm is not that evil as one could think after reading the article. My experiences show that it can lead to a very clean and manageable programming paradigm where you have a good chance to handle the flow control of a complex application and still give the user the feel of an interactive application. It is always clear that a processing step is initiated by the user and you don't have to handle the nightmare of unrequested updates. Sure there are some special cases where it is desirable to get updates without the users fingertips, but this can easily be handled via some kind of automatic requests. And don't forget: Even if you do a lot of magic to reach your asynchronous nature - which in essence is nothing more than extending the mvc paradigm over the network wire - you still do not see the changes that the hundreds or thousands of other users do in the same time. So in the next step will you extend your collaboration model to updates between active user sessions or some kind of magic database triggers?
  13. I really fail to understand this stuff. Actually, that's not true. I fail to understand why we bother with things like the "Asynchronous web". The web has its roots in displaying information like a page in a book. That's the paradigm and that's what it's really really good at. Now we can do magical things like send information back to the page, or even update little sections of a page at random. It's almost like a choose your own adventure. But I really don't understand why we're desperately trying to retrofit an old technology to act like a complete desktop application. A retrofit process that is arguably poor at best. Large AJAX apps are useless over poor connections and isolate, if not completely deter users. And this is if their desktop client won't crash from the amount of JS and AJAX garbage that's being forced down their necks. Lets have a SERIOUS revolution - let the browser do what it does best - browse. For anything else, lets put serious focus seriously on alternate technologies, and stop trying to turn Grandma's wagon into an F1 racer.
  14. But I really don't understand why we're desperately trying to retrofit an old technology to act like a complete desktop application. A retrofit process that is arguably poor at best. Large AJAX apps are useless over poor connections and isolate, if not completely deter users. And this is if their desktop client won't crash from the amount of JS and AJAX garbage that's being forced down their necks.

    Lets have a SERIOUS revolution - let the browser do what it does best - browse. For anything else, lets put serious focus seriously on alternate technologies, and stop trying to turn Grandma's wagon into an F1 racer.
    I have to say that I kind of agree with this. When I come a cross a page that's using tons of Javascript, I'm generally annoyed. I use NoScript so if I don't know much about you, I'm not going to allow scripts from your page. I might just leave. This happens to perhaps 10% of the new pages I see that use AJAX. I might hang out and try to read the page with it all junked up. If I can't work with it, I might turn scripts on from your domain. The thing is, half the time I do turn on scripts, they are just annoying. They don't add anything meaningful. I think there are some major limitations to HTML that good scripting can address but I don't need a multi-media experience from every website. I wonder if I'm just an oddball or if there are a lot of people that feel that way.
  15. Correct me if I'm wrong[ Go to top ]

    I always thought the beauty of HTTP is this, open a connection, send the request, get the response and close the connection and pooof free up resources on both sides. If in this new paradigm the server is going to keep the connection open for an indefinite time just because something might come down the pipe later on or not, then we are seriously hindering server's capabilities in terms of the number of requests that it can handle. in fact I see this as a waste of server's potential rather than a revolution in web communication. Does DoS become more frequent or am I missing something?
  16. asynch http in resteasy[ Go to top ]

    I wrote an async http abstraction for JAX-RS in Resteasy project -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com
  17. Re: asynch http in resteasy[ Go to top ]

    That looks pretty cool, dead simple, would be good if JAX-RS supported something like this as part of the core API. Cooler still would be to allow (through another interface) the thread access to the response output stream so that it could stream the response, then when its finished or when @Suspend times out to close the response.
  18. Re: asynch http in resteasy[ Go to top ]

    That looks pretty cool, dead simple, would be good if JAX-RS supported something like this as part of the core API. Cooler still would be to allow (through another interface) the thread access to the response output stream so that it could stream the response, then when its finished or when @Suspend times out to close the response.
    You can stream the response with StreamingOutput. A little wacky (callback x 2), but it works.
  19. Comet vs. Async HTTp[ Go to top ]

    My current thoughts about comet are that if your server is doing Async HTTP, do you really need a COMET api? 1) There's very little extra performance benefit 2) COMET is proprietary requiring extra javascript library support Thoughts? -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com
  20. Reality check[ Go to top ]

    From the article: The last option to consider is HTTP long polling, where the request is made in anticipation of a future response, but that response is blocked until some event occurs that triggers its fulfillment. This mechanism, which is illustrated below, is nearly as efficient as streaming and is completely compatible with proxy/firewall configurations as it is indistinguishable from a slow responding server. ------------------------------------------------------ A reality check is in order here. This kind of pulling is a constant concern when deploying our solution. Many many firewalls and proxies are misconfigured or misbehave when subjected to long running requests. Some just close the socket and you are stuck with ugly timeouts. Fine-tuning the duration of a long request needs to be done more often than not. "completely compatible" is just not a real world observation.
  21. "Frankly, we are left with more questions than answers at this point." Indeed. Seems like someone is grasping for a solution to a problem that doesnt really exists. With ever increasing bandwith and lower network latencies small period polling is fast becoming less of a problem and less of a compromise. Also this whole supposed tie-in with "web 2.0" is a complete red herring - what on earth has the detail of the dynamic update protocol got to do with "collaberation" ??. Bottom line - we already have an "asychronous web" its called AJAX and it works perfectly well for 99% of all aplicable applications, and this article is nothing more than some lame attempt to lay claim to breaking new ground that has infact already been well broken and understood.
  22. Embrase the web, don't fight it[ Go to top ]

    My guess is that this concept is doomed to fail because it flies in the face the inherent, inescapable architecture of the web, which is that of a client request, server response paradigm. We may not like it all the time, we may wish it acted more like peer to peer or desktop computers but that's not what it is and attempts to hide that or skirt it are going to be uphill battles. Just look at what Microsoft did with ASP.NET. The tried to hide the nature of web development behind their Windows Forms programming model and it lead to a lot of weird problems and inefficiencies like bloated state management. Eventually they realized that you have to accept the web for what it is and they released an MVC based framework.

    No web server is going to be able to keep tens of thousands (much less millions) or TCP sessions open all the time just in case it wants to pump more data out to a browser. That just doesn't scale.