|
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?
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
|
|
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
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 #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
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.
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:
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?
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?
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?
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
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 #308201
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
Re: asynch http in resteasy
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
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
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 #308247
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
Reality check
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?
"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:
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 |
 |
 |
Reza Rahman continues to explore 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.
(January 21, Article)
Ted Neward is an independent consultant specializing in high-scale enterprise systems, and an authority in Java and .NET technologies. He is the author and co-author of several books, including Effective Enterprise Java. At TheServerSide Java Symposium in March, he will be presenting sessions on pragmatic architecture, ECMAScript and Scala.
(January 15, Article)
Now that Oracle is absorbing Sun Microsystems, there mixed views on what should come of the Java Community Process (JCP). While some say Oracle should become the new steward of Java and keep the JCP much as it was, others argue that it may be time to open-source this widespread language.
(November 24, Article)
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 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)
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)
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)
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)
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, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
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)
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)
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)
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)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
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)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
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)
|
|