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.

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?

Another alternative for developing AJAX based applications is the Echo2 framework. Echo2 doesn't require the developer to write any Javascript (or HTML, for that matter). The API is "swinglike", but generates highly responsive AJAX applications

http://www.nextapp.com/products/echo2/

http://ensode.net/echo2_review.html

http://ensode.net/echo2_closer_look.html

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. ;-)

http://claudehussenet.com

Rgds.

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 Sajax
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
<create creator="spring" javascript="portletContainerService">
          <param name="beanName" value="portletContainerService"/>
        </create>

and u're done !

Rgds-Claude

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?)
...

Correction: Isomorphic


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
    A handful of products, all commercial, are building or have built sophisticated GUI frameworks on top of one or more web browsers, using asynchronous JavaScript techniques to render HTML/CSS on the client. SmartClient, Backbase, and General Interface are all in this space. An AJAX communication library is usually a very small part (like 1% of the public APIs) of these systems. The heavy lifting is in the vast array of workarounds and patches for in-browser rendering and interactivity.


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-

Jeff Dill
Isomorphic Software
www.smartclient.com

Jeff,

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.

Jeff Dill
Isomorphic Software
www.smartclient.com

Having worked now with two AJAX libraries as well as multiple model 1 and model 2 frameworks in several languages, I think AJAX is going to change the playing field pretty dramatically for webapp frameworks. The 'natural' way of developing an AJAX application in a model 2 environment (I'm not even going to mention model 1) is to have a fairly thin JS<->Servlet transformation layer which is solving many of the same problems that XML-RPC solves, and then hook up JavaScript handlers and Java-side event handlers to do the 'application logic.' This is how DWR works, just to connect my comment here to the actual context I'm putting it in. ;)

The problem here is that the 'application logic' on the JavaScript side is fairly laborious and not really part of the standard skillset of your typical Struts or JSP developer, unless perhaps they come from the client scripting / DOM world. Even then you're dealing with an error prone, hard to debug, cross-platform nightmare compared to the Java side of the equation. As someone just getting into AJAX, my immediate reaction was "Christ, can't I just focus on what I'm good at and what I care about here without having to learn all this JavaScript stuff which isn't really core to my app anyway?"

Enter component-driven frameworks like JSF and Tapestry.

It seems to me that these frameworks are ideal for developing AJAX-enabled dynamic components on your web page. The components can generate all of the client-side layer up to and including the JavaScript glue that is such a pain to write if you don't come from that world. Suddenly the event handling model is more than just a convenient mental conceit that makes your webapp easier to write, it's actually how things work! How much more natural will it be to write dynamic event handlers when the events are actually dynamic? (Obvious answer: a lot.)

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.


Jeff Dill
Isomorphic Software
http://www.smartclient.com

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.

What he seems to completely sidestep is that you're not developing them in the same language or for the same environment. I'm not 100% sure about .Net, but obviously anything where you could download a .Net component and just run it locally would fall under ActiveX and therefore be most comparable to a Java applet. And most people don't consider either Java applets or ActiveX controls to be a part of the whole zero-download web application space. Therefore all the major web development methodologies would require you to master at least two languages and their associated frameworks -- your server environment and the client's JavaScript environment.

It's non-trivial to find a developer who is equally skilled in both environments. If you're fortunate enough to have a skilled JavaScript person available whenever you need them and the costs of working with them aren't too high (both explicit and implicit costs of course), then perhaps this isn't a big barrier. For many people this is obviously not the case.

So, back to my original point, it seems like there is going to be a premium placed on frameworks which allow a developer to focus on the business logic, and to implement this business logic completely in their chosen environment without having to worry about JavaScript, the DOM, cross-platform concerns, etc. Looking at the Isomorphic website, I'm preaching the choir here. 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, however, and so a commercial solution to this problem has limited scope of impact regardless of anything else.

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.

So, back to my original point, it seems like there is going to be a premium placed on frameworks which allow a developer to focus on the business logic, and to implement this business logic completely in their chosen environment without having to worry about JavaScript, the DOM, cross-platform concerns, etc.

Exactly.

 

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:
http://www.servletsuite.com/jsp.htm#ajax

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).
It's working great for most of my AJAXian needs - publishing Spring beans in Javascript is super-easy. Of course, I sometimes have other needs (publishing a whole JSP as an inner HTML component) where DWR is not enough, but for that I don't need a framework to help me.
Anyway, some interesting facts :
- DWR works perfectly with Acegi security, in case you're frigthened about the security of your Spring beans
- DWR is _really_ publishing your Spring beans : I currently have a tiny bug where my Spring's ObjectRetrievalFailureException goes all the way throught my app's layers to the JavaScript, showing it as a JavaScript error!

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
as is?

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

Shishank
http://goshishank.blogspot.com

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:
http://weblogs.macromedia.com/jd/archives/2005/08/cpaint_vulnerab.cfm

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,

Jeff Dill
Isomorphic Software
www.smartclient.com

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.

Shishank
http://goshishank.blogspot.com