Joe Walker has a new article on java.net, called "Developing AJAX Applications the Easy Way," that uses DWR to create a multi-user web-based chat site in about 100 lines of code for both the client and the server.
- Posted by: Joseph Ottinger
- Posted on: August 26 2005 09:00 EDT
The article doesn't create a secure chat of any kind, but it does illustrate how easy AJAX can make development. This application isn't large enough to truly benefit from AJAX (except as an example application), and apparently requires the user to send messages to receive messages - perhaps Mr. Walker will add an asynchronous polling mechanism to the example to show us live updates, normally a requirement for people who lurk on such chats.
What do you think? Is the example worthwhile?
- Article from java.net: Developing AJAX Applications the Easy Way by David Heffelfinger on August 26 2005 10:00 EDT
- Article from java.net: Developing AJAX Applications the Easy Way by Claude Hussenet on August 26 2005 12:27 EDT
- This looks great for some one who has swing experience. by Lisa Li on August 30 2005 16:57 EDT
- DWR works for me by John Liptak on August 26 2005 12:16 EDT
- Article from java.net: Developing AJAX Applications the Easy Way by Joe Walker on August 26 2005 12:24 EDT
- Article from java.net: Developing AJAX Applications the Easy Way by Abhay Bakshi on August 26 2005 12:47 EDT
- Article from java.net: Developing AJAX Applications the Easy Way by Claude Hussenet on August 26 2005 12:54 EDT
- Article from java.net: Developing AJAX Applications the Easy Way by Henrique Steckelberg on August 26 2005 13:34 EDT
- Article from java.net: Developing AJAX Applications the Easy Way by Henrique Steckelberg on August 26 2005 01:38 EDT
- AJAX communication vs AJAX RIAs by Jeff Dill on August 26 2005 13:56 EDT
WebORB vs Isomorphic by Abhay Bakshi on August 26 2005 03:16 EDT
WebORB vs Isomorphic by Jeff Dill on August 26 2005 05:55 EDT
Will AJAX drive adoption of component frameworks? by James Waldrop on August 26 2005 07:26 EDT
- Will AJAX drive adoption of component frameworks? by Jeff Dill on August 26 2005 10:13 EDT
- Will AJAX drive adoption of component frameworks? by James Waldrop on August 26 2005 07:26 EDT
- WebORB vs Isomorphic by Jeff Dill on August 26 2005 05:55 EDT
- WebORB vs Isomorphic by Abhay Bakshi on August 26 2005 03:16 EDT
- Article from java.net: Developing AJAX Applications the Easy Way by Marina Prikaschikova on August 29 2005 02:25 EDT
- Feedback on InsiTech's XTT by Richard Conway on August 29 2005 15:58 EDT
- Using DWR and lovin' it by Julien Dubois on August 26 2005 13:53 EDT
- Is DWR open source? by Alok Pota on August 26 2005 19:54 EDT
- Article from java.net: Developing AJAX Applications the Easy Way by Shishank Mathur on August 30 2005 10:12 EDT
- Article from java.net: Developing AJAX Applications the Easy Way by Henrique Steckelberg on August 30 2005 12:51 EDT
- Article from java.net: Developing AJAX Applications the Easy Way by Jeff Dill on August 30 2005 13:34 EDT
- Article from java.net: Developing AJAX Applications the Easy Way by Shishank Mathur on September 05 2005 12:04 EDT
Does Echo have an integration with Spring ?
One of the feature that I like in DWR it's the easy way to export beans defined in the spring factory just by adding a simple XML definition.So,no code is required on the server side.
FYI..I have created a demo with DWR and Spring so my comments may be biased. ;-)
I like it, but I have not tested it.
I'm exploring DWR myself and I'm very impressed.
The article does not show a finished application. There are a bunch of "improvements" that could be added to the article's application. I would judge it on another level: does it show how async communications can make a web application better.
I think it passes that test. The example is worthwhile because it will give reads food for thought.
The live site does have the asynch update functions. They were missed out of the tutorial because the tutorial was just about getting running with DWR.
Ajax Pitfall to watch out for:
If you write an Ajax site with a URL like http://getahead.ltd.uk and then some (like for example java.net) links to it using http://www.getahead.ltd.uk you could get an error from the XHR component. In this case a little apache-foo was all that was required to fix it, but it is one worth watching for.
I heard, AjaxTags (http://ajaxtags.sourceforge.net) was easier to use.
o Rico and Ruby on Rails have a library.
o WebORB from wwww.themidnightcoders.com
o BEA may have big support for AJAX early 2006
o Don't forget, even Apache Cocoon can work similar.
o Isomorphomic (What's your experience?)
o Backbase (http://www.backbase.com) (What's your experience?)
o TIBCO General Interface
o XTT from InsiTech (thin but smart Swing client)
What is your experience with any or all of these, by the way? If you have some experience, do you like open-source AJAX technologies or commercial vendors? I will let you know what I find though.
Can you share your experience and let us all know? Note that the term 'AJAX' was coined by Adaptive Path before "AJAX" took off.
I heard, AjaxTags (http://ajaxtags.sourceforge.net) was easier to use.
What is your own experience with this tag librairie ?
Just by looking at the first sample from the link provided,it seems that the xml generation on the server side is left to the developer !
With DWR,u just specify the following line in a DWR config file
<param name="beanName" value="portletContainerService"/>
and u're done !
I've run into Scriptaculous (http://script.aculo.us/), which have some amazing AJAX components. Some people are already working on integration with Wicket framework, which would take the meaning of "best of both worlds" to a whole new level ;)
Oh, and there's also OpenRico (http://openrico.org/rico/home.page), which has really nice effects too!
o Isomorphomic (What's your experience?)
Our experience: The SmartClient AJAX presentation layer has been deployed in global production extranets since 2000, generally available as a developer product since 2001, and licensed by leading ISVs (including PeopleSoft, Oracle, and at least two of the companies mentioned in TSS headlines this week) since 2002.
If I can make an observation -- The world of AJAX projects and products currently breaks down along two lines:
1) AJAX communication libraries
Most of the emerging projects are simple wrappers of XMLHTTP, to enable some backchannel browser-server communication. This is a quick way to enhance certain interactions (like background loading of SELECT values) in existing web apps. It is fairly easy to "roll your own" background comm with XMLHTTP, albeit with limitations including dependence on ActiveX in IE, no push capability, no file uploads... There are several other "AJAX transports" to solve these issues, including IFRAME approaches, but they are much more difficult to implement and debug on your own.
2) AJAX RIA systems
If you are considering "AJAX enhancements", it is important to make this distinction: Do you want to add some background requests to your applications, or do you want to provide rich GUIs in the web browser?
Hope this helps-
You should forgive me for the typo that I had earlier with Isomorphic.
In the commercial world, how do you compete with WebORB from http://www.themidnightcoders.com?
I see that WebORB Pro is $799 whereas WebORB standard is free. Your SmartClient is $5K/CPU from the licensing page.
If you justify and compare, you will help us as AJAX developers.
In the commercial world, how do you compete with WebORB
Short answer - these are not competing products. WebORB is a communication layer and request broker; SmartClient is an AJAX RIA platform. The distinction will be clear if you explore the live examples on our respective websites. Feel free to contact me via the website if you would like to continue this discussion off-forum.
Enter component-driven frameworks like JSF and Tapestry.
IMO all the AJAX libraries, including DWR, which are designed from the ground up in the Model 2 world seem impedance mismatched with the underlying methodology. Component frameworks, which up until I started writing AJAX code seemed to me to be just another unnecessary abstraction layer, is now where the action is. I can't wait to see what great AJAX stuff comes out of the Tapestry or JSF community. I'm betting it'll make life a lot easier for those of us who want to focus on writing code that matters vs glue logic that's forced on us by the libraries we're using.
Absolutely. AJAX enables rich GUIs, and rich GUIs are inherently component-based.
In the short term, server-side view-component frameworks like Tapestry and JSF should see a bump in adoption, because they are the shortest route to components for server-side developers.
But rich GUI components run on the client, so they will require a client-side framework regardless.
Now when you combine a client-side AJAX GUI framework and components (eg SmartClient) with a server-side view-component framework (eg JSF), you essentially have the old ASP.NET web controls architecture. You get richer UI, but managing the individual view components on ~both~ client and server impacts scalability and responsiveness, and tightly couples your client and server technologies.
The solution is to manage this level of view componentry on the client ~only~. Client and server then communicate in terms of authorized data models and operations, not user interface events.
At their core, this is what the various RIA platforms are about: Client-side MVC, with a shared client-server Model. But this will not happen overnight, and especially not on TSS. ;)
Oliver Steele of Laszlo (the open-source Flash RIA platform) wrote an excellent article (http://osteele.com/archives/2004/08/web-mvc) about this progression last year, with lots of diagrams. Check it out if you're interested.
So, that's a nice article, but it's inaccurate about the eventual RIA diagram. In fact they look exactly the same in the end, it's just that the RIA app has thicker view and controller layers on the client side. However, despite the diagram, these thicker layers don't obviate the need for server-side controller and view layers, because you still have to be able to do things like fetch the next 20 topics in a forum. Really, anything else that requires more state than the client can reasonably be expected to download and maintain will in turn mean a server side which contains more layers than just a bare Model. For instance, do you really trust the client to do validation, auth, or transaction control? Obviously you will revalidate data on the server even though the client did some of it for you, and you're not going to put auth and transactions directly into your model for equally obvious reasons. Perhaps AOP goes some of the way towards streamlining this, but I think it's a stretch to say you could do away with your View/Controller layers on the server altogether.
So in the end the author has painted himself into kind of a corner, diagram-wise anyway, and produced two diagrams that (should) look exactly the same. Since it seems like his intent is to demonstrate that RIA's aren't more complex to develop than server-side MVC apps, perhaps he'd be ok with this. However, I have to take issue with this hypothesis as well, because as I said the client-side MVC layer in his diagram is far thicker in the RIA than it is in the server-side MVC app. That's the whole point after all.
This is why I'm looking to the open source world to do something interesting here. Of course Microsoft could do it as well, with .Net. My guess is that they're not going to be particularly motivated to further narrow the gap between the user experience for web apps and client apps, at least not without locking the user into Internet Explorer and .Net. So waiting for something from them that solves this problem might be akin to waiting for Godot.
So, that's a nice article, but it's inaccurate about the eventual RIA diagram. In fact they look exactly the same in the end, it's just that the RIA app has thicker view and controller layers on the client side...
...AND the server side has much thinner view and controller layers.
So thin, in fact, that Oliver was justified to drop them in those diagrams. There are remarkably few functions left for these layers to perform in most web applications. Data fetching, auth, validation, and transaction control are actually operations and rules on the model, not the view.
Where we may differ is in our expectations of the impact open source will have on this area. I think we can both agree that 90%+ of the web applications developed in the world are going to be running on 'Free As In Beer' platforms...This is why I'm looking to the open source world to do something interesting here.
Yes, open source could be the new end of the line for all mature platform software. But as a rule, open source projects do not innovate--they copy stable solutions. It takes 5-10 years for a new software product category to mature to the point where comparable open source projects can emerge. Not everyone can wait that long...
There are remarkably few functions left for these layers to perform in most web applications. Data fetching, auth, validation, and transaction control are actually operations and rules on the model, not the view.
Your model objects are going to look awfully non-modelly with all that code inside them. Maybe that's not what you meant, but the code has to go somewhere, and I'd put it in a controller if nothing else. I can buy the View going away, if you send me $1, maybe. ;) (You'll still need some kind of resolver piece btw, which some people might call a View.)
But as a rule, open source projects do not innovate--they copy stable solutions. It takes 5-10 years for a new software product category to mature to the point where comparable open source projects can emerge. Not everyone can wait that long...
No offense man, but roughly 10 years ago Java was released in beta. A whole industry has been created and had a chance to have 'mature' players in that time. I think your timeframe is off by a facter of 2 at least, more like 3. :)
Your model objects are going to look awfully non-modelly with all that code inside them. Maybe that's not what you meant, but the code has to go somewhere, and I'd put it in a controller if nothing else.
Well, you could put it in a "service" which encapsulates both your model objects (aka schema) and your view-independent business logic (validation, auth, etc). Whatever you call it in your system, this code is clearly behind the model boundary in a MVC presentation layer. You would use the same code for server-to-server calls, where there is no view whatsoever.
No offense man, but roughly 10 years ago Java was released in beta. A whole industry has been created and had a chance to have 'mature' players in that time.
None taken. Not sure what product category you have in mind, maybe virtual machines, maybe app servers, maybe something else. Anyway, I think most folks on TSS would agree that AJAX RIA platforms are a relatively new product category.
Check out Ajax part of Coldtags suite too:
This is in reference to the request for info on XTT and other frameworks. I've been working with XTT for about 6 months now and it is extremely powerful and easy because it's just Java. You only need to work with one language and can put as much or as little code in the client as you want. InsiTech provides development wizards that make it easy to develop rich, robust apps quickly.
While Java is becoming more common on end user's machines, it is not yet ubiquitous, and can therefore be problematic for public access applications. For this reason, XTT is an excellent choice for corporate or ASP applications for which the need to download a small amount of code is not an issue.
I've been using DWR for a few weeks on my own pet project (http://tudu.sf.net).
Anyway, some interesting facts :
- DWR works perfectly with Acegi security, in case you're frigthened about the security of your Spring beans
If you want to try out my project, it's full of DWR examples : http://tudu.sf.net
What about licensing?. Can I use it in commercial projects
What about licensing?. Can I use it in commercial projectsas is?From its home page:
DWR is freely available as open source software (ASL version 2.0). It is straightforward to implement with extensive libraries, examples and tutorials.
I have explored bit of RICO and SmartClient and both are pretty cool.
Just wondering about security aspect of the various tools mentioned in the discussion as recently big giants like Google, AOL, Yahoo etc. were struck by Ajax security hole in CPAINT, another popular Ajax development tool.
More at http://www.xatrix.org/article.php?s=4040
This whole AJAX vulnerability is completely false, none of the above mentioned companies use CPAINT, besides the security hole is specific to CPAINT toolkit and not to AJAX as a whole, see:
I have explored bit of RICO and SmartClient and both are pretty cool. Just wondering about security aspect of the various tools mentioned in the discussion as recently big giants like Google, AOL, Yahoo etc. were struck by Ajax security hole in CPAINT, another popular Ajax development tool.
That particular case was just a publicity stunt to attract attention to a new project. None of the companies mentioned in that article use CPAINT. The project just kicked off two months ago.
As I understand it, the bug was that their server would execute any code passed from the client. That is an issue with very early prototype code, ~not~ an AJAX security hole. It was irresponsible and misleading to report it as an AJAX issue.
But to answer your question --
The platform for AJAX applications is the same as that for non-AJAX web applications, so the underlying security holes are the same. However, since client-side page rendering and client-server RPCs are fairly new to most web developers, it is more likely that they will overlook some of the issues. Some of the more common cases include:
* quick & dirty RPC mechanisms that allow arbitrary code execution on the server (eg the bug in CPAINT)
* client-side script injection (XSS exploits) not blocked in your component HTML renderers
* overly-permissive proxies that allow arbitrary cross-domain scripting
If you need to implement AJAX applications in production, security is one good reason to evaluate the commercial solutions. Performance, stability, scalability, and interoperability are some other good reasons.
Hope this helps,
Thanks Jeff for the information.
I too agree that Ajax in itself doesn't pose any security threat but it all depends on the underlying application.
Is there any matrix/data available that compare various Ajax tools based on the parameters you mentioned before.