667481 members! Sign up to stay informed.

Sponsored Links


Resources

Enterprise Java
Research Library

Get Java white papers, product information, case studies and webcasts

News News News Messages: 20 Messages: 20 Messages: 20 Printer friendly Printer friendly Printer friendly Post reply Post reply Post reply XML XML XML

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

Posted by: Nuno Teixeira on April 28, 2009 DIGG
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 replies

·  What is the Asynchronous Web, and How is it Revolutionary? by Nuno Teixeira on Tue Apr 28 11:27:06 EDT 2009
  ·  Link to article by Carlos Angelim on Tue Apr 28 12:29:15 EDT 2009
    ·  Nothing New Here by Niall Gallagher on Tue Apr 28 13:15:37 EDT 2009
      ·  URL - oops! by Jim Fergusson on Fri May 01 07:51:01 EDT 2009
    ·  No need to learr how those private API by JeanFrancois Arcand on Tue Apr 28 13:24:45 EDT 2009
      ·  Re: No need to learr how those private API by Niall Gallagher on Wed Apr 29 04:18:36 EDT 2009
    ·  JSP and JSP are not good solutions. by Nicolas Bousquet on Wed Apr 29 04:44:05 EDT 2009
  ·  Re: What is the Asynchronous Web, and How is it Revolutionary? by Benz Town Citizen on Tue Apr 28 16:19:24 EDT 2009
    ·  why no mention of HTML 5 webSocket ? by Alex Vasseur on Tue Apr 28 18:06:14 EDT 2009
  ·  The easy way solution for Asynchronous Web: by Dmitry Levitin on Thu Apr 30 05:04:20 EDT 2009
    ·  Re: The easy way solution for Asynchronous Web: by Marco Wang on Tue May 19 06:17:57 EDT 2009
  ·  Re: What is the Asynchronous Web, and How is it Revolutionary? by Marco Noname on Thu Apr 30 05:27:24 EDT 2009
  ·  Why are we wasting our time on this stuff? by Daniel Murley on Thu Apr 30 08:18:25 EDT 2009
    ·  Re: Why are we wasting our time on this stuff? by James Watson on Thu Apr 30 09:05:07 EDT 2009
  ·  Correct me if I'm wrong by Ryan , on Thu Apr 30 11:22:52 EDT 2009
  ·  asynch http in resteasy by Bill Burke on Thu Apr 30 13:24:26 EDT 2009
    ·  Re: asynch http in resteasy by Niall Gallagher on Thu Apr 30 13:45:14 EDT 2009
      ·  Re: asynch http in resteasy by Bill Burke on Thu Apr 30 14:10:18 EDT 2009
  ·  Comet vs. Async HTTp by Bill Burke on Thu Apr 30 14:13:08 EDT 2009
  ·  Reality check by Jochen Bedersdorfer on Fri May 01 21:33:11 EDT 2009
  ·  Re: What is the Asynchronous Web, and How is it Revolutionary? by Paul Campbell on Fri May 15 06:42:38 EDT 2009
  Message #308019 Post reply Post reply Post reply Go to top Go to top Go to top

Link to article

Posted by: Carlos Angelim on April 28, 2009 in response to Message #308016
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

  Message #308021 Post reply Post reply Post reply Go to top Go to top Go to top

Nothing New Here

Posted by: Niall Gallagher on April 28, 2009 in response to Message #308019
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

  Message #308024 Post reply Post reply Post reply Go to top Go to top Go to top

No need to learr how those private API

Posted by: JeanFrancois Arcand on April 28, 2009 in response to Message #308019
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 ;-)

  Message #308038 Post reply Post reply Post reply Go to top Go to top Go to top

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

Posted by: Benz Town Citizen on April 28, 2009 in response to Message #308016
Nice article.

  Message #308048 Post reply Post reply Post reply Go to top Go to top Go to top

why no mention of HTML 5 webSocket ?

Posted by: Alex Vasseur on April 28, 2009 in response to Message #308038
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.

  Message #308069 Post reply Post reply Post reply Go to top Go to top Go to top

Re: No need to learr how those private API

Posted by: Niall Gallagher on April 29, 2009 in response to Message #308024
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.

  Message #308070 Post reply Post reply Post reply Go to top Go to top Go to top

JSP and JSP are not good solutions.

Posted by: Nicolas Bousquet on April 29, 2009 in response to Message #308019
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.

  Message #308126 Post reply Post reply Post reply Go to top Go to top Go to top

The easy way solution for Asynchronous Web:

Posted by: Dmitry Levitin on April 30, 2009 in response to Message #308016
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.

  Message #308128 Post reply Post reply Post reply Go to top Go to top Go to top

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

Posted by: Marco Noname on April 30, 2009 in response to Message #308016
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?

  Message #308184 Post reply Post reply Post reply Go to top Go to top Go to top

Why are we wasting our time on this stuff?

Posted by: Daniel Murley on April 30, 2009 in response to Message #308016
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.

  Message #308187 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Why are we wasting our time on this stuff?

Posted by: James Watson on April 30, 2009 in response to Message #308184
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.

  Message #308197 Post reply Post reply Post reply Go to top Go to top Go to top

Correct me if I'm wrong

Posted by: Ryan , on April 30, 2009 in response to Message #308016
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?

  Message #308200 Post reply Post reply Post reply Go to top Go to top Go to top

asynch http in resteasy

Posted by: Bill Burke on April 30, 2009 in response to Message #308016
I wrote an async http abstraction for JAX-RS in Resteasy project

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

  Message #308201 Post reply Post reply Post reply Go to top Go to top Go to top

Re: asynch http in resteasy

Posted by: Niall Gallagher on April 30, 2009 in response to Message #308200
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.

  Message #308202 Post reply Post reply Post reply Go to top Go to top Go to top

Re: asynch http in resteasy

Posted by: Bill Burke on April 30, 2009 in response to Message #308201
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.

  Message #308203 Post reply Post reply Post reply Go to top Go to top Go to top

Comet vs. Async HTTp

Posted by: Bill Burke on April 30, 2009 in response to Message #308016
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

  Message #308224 Post reply Post reply Post reply Go to top Go to top Go to top

URL - oops!

Posted by: Jim Fergusson on May 01, 2009 in response to Message #308021
I do it all the time....

should be http://www.simpleframework.org/



Jim

  Message #308247 Post reply Post reply Post reply Go to top Go to top Go to top

Reality check

Posted by: Jochen Bedersdorfer on May 01, 2009 in response to Message #308016
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.

  Message #308843 Post reply Post reply Post reply Go to top Go to top Go to top

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

Posted by: Paul Campbell on May 15, 2009 in response to Message #308016
"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.

  Message #309057 Post reply Post reply Post reply Go to top Go to top Go to top

Re: The easy way solution for Asynchronous Web:

Posted by: Marco Wang on May 19, 2009 in response to Message #308126
I didn't read the spec, however, does this approach work with client behind NAT/firewall?

New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com

Dependency Injection in Java EE 6 - Part 1

Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6. (November 2, Article)

SAML: It's Not just for Web services

SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options. (September 28, Article)

Programming is Also Teaching Your Team

Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team. (September 22, Article)

Can Java EE Deliver The Asynchronous Web?

Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies. (July 14, Article)

JSF Flex

JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags. (June 29, Article)

The Rules of SOA - A Road to a Successful SOA Implementation

In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project. (June 23, Tech Talk)

Ari Zilka Talks About Terracotta 3.1

Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now. (June 15, Tech Talk)

Enterprise Application Integration, and Spring

In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements. (June 15, Tech Talk)

Google Web Toolkit: An Introduction

In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls. (June 4, Tech Talk)

Just Enough Early Architecture to Guide Development

Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable. (May 28, Tech Talk)

Productive Programmer: On the Lam from the Furniture Police

This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work. (May 26, Tech Talk)

Auto-Scaling Your Existing Web Application

Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers. (May 21, Tech Talk)

Automating Hibernate Mapping and Queries For Java Web Development

Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application. (May 19, Article)

Auto-Scaling Your Existing Web Application

In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources. (May 19, Tech Talk)

Free Book: Jakarta-Struts Live

Download the entire book of Jakarta-Struts Live and learn about Struts MVC, Tiles, the Validator, DynaActionForms, plug-ins, internationalization, and more.
(Book PDF Download)

Application Server Matrix

The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)

News | Blogs | Discussions | Tech talks | Patterns | Reviews | White Papers | Downloads | Articles | Media kit | About
Java Solutions
All Content Copyright ©2007 TheServerSide Privacy Policy
Site Map