How AJAX kills the application server

How AJAX kills the application server

Summary: AJAX's 'client-service' architecture eliminates the need for an application server to connect the Web client to back-end resources.

TOPICS: Servers

Everyone focuses on how a new breed of AJAX applications will gradually eat into Microsoft's bread-and-butter desktop application revenues, but the effect on the bottom lines at Sun, Oracle, BEA, IBM and any other vendor that sells a lot of application servers will be much more immediate.

An unnoticed side-effect of implementing rich internet application platforms — whether they're AJAX or anything else — is that this 'client-service' architecture eliminates the need for an application server to connect the Web client to back-end resources. Sure, if you're a company like Zimbra implementing a new resource at the back-end, in its case an email server, then obviously that server is a new addition. But it's still devolving more processing to the client, so it requires far less horsepower than it would to deliver the same functionality to a wholly web-based client.

I was first alerted to this in a conversation a few weeks back with Adam Gross, VP marketing at, who told me about early customer reaction to his company's AJAX toolkit. Customers were excited because it meant they could connect directly to the AppForce hosted platform without having to run up an application server as an intermediary. "We can just store the XML and the JavaScript on our server and deliver that as necessary to the client," he explained. "A lot of the time, developers are restricted by the fact their company can't deploy a new piece of server hardware [to operate a new application]. [Using AJAX] liberates them to do things that are completely within their own resources ... it lets you do more with no server infrastructure."

Topic: Servers

Phil Wainewright

About Phil Wainewright

Since 1998, Phil Wainewright has been a thought leader in cloud computing as a blogger, analyst and consultant.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Another "new thing kills old thing" story?

    Sigh, I have been hearing stuff like this since 1980. Every "new thing" claims it's going to take over everything and everywhere, but there are still mainframes running in glass rooms in most major financial operations. Guess the new thing will just have to co-exist with it's older brethren for a while longer, huh?

    Much as I dislike Microsoft's corporate behavior, AJAX isn't going to be killing off anything anytime soon.

  • Maybe you misunderstood

    I think the writer has misunderstood what Ajax means.

    I do not know how a particular company used to deliver their applications, but to me not much changes.

    The only thing that changes is the interaction model between the web browser and the server...the same old server. That is the letter A in Ajax; asynchronous. The x comes from use of XML...which is very much like superset of HTML. The letter J comes from Java script which takes over some tasks from the web browser, mainly rendering the screen.

    So...where is the change on the server? To the server, it is still request/response. If you are using some custom software, you just bought a rewrapped webserver...which you can get for free anyway. Bummer!

    This gives the user a richer interface to work with, which directly reduces the appeal of traditional desktop applications. Maintaining rich but thin applications brings great savings, and allows new business models, and reduces the importance of the desktop operating systems. Any rinky dinky system with memory and modest local storage (flash drive etc.) can be enough to run these applications. Now calculate 1+1 and you know who might really lose.
    • Great post...

      You're exactly right. I couldn't have said it better.

    • Imagination can be a great limitation to human productivity

      Think about it

      If U create a Browser using AJAX (forget what it stands for). I mean a Web Browser inside a WebBrowser than how will china government be able to ban any websites ?

      Do U feel the Power of AJAX ?
  • Silly article...

    AJAX and traditional web development are basically the same as far as backend server requirements are conserned. If anything, you may need better backend server components for AJAX because there are typically an order of magnitude more HTTP connections made to the server.

    AJAX transmits more XML than HTML versus a traditional web site -- so what? How does that change anything in the backend? You still need a sophisticated (typically J2EE) server in the background serving up all of the HTML or XML.

    The authors logic is very flawed. If I have a page that dynamically refreshes a portion of data on the screen (by requesting XML asynchronously) or reloads the whole screen via a new HTML page, the work done by the server is basically the same. There isn't much more or less of a difference.

    AJAX is exciting and promising. Due to the new possibilities, I'm sure Sun, IBM, Oracle, BEA, JBoss and others will enjoy the renewed interest in sophisticated online applications. These next-generation web apps will require serious backend software and the J2EE servers are already in a position to deliver.

    Gmail -- J2EE
    Yahoo Mail -- J2EE (as far as I know)
    Zimbra -- J2EE
    ClarifyCRM -- J2EE

    Look up AJAX in wikipedia and you'll notice that there is more work done by Java/J2EE than any other technology. These app server vendors will be sitting pretty. This article is FUD.

    • J2EE to deliver HTML???

      Why on earth would I want to go to all the expense and high-maintenance of a J2EE server to deliver HTML and XML? What's wrong with Apache/Linux?
      And J2EE is not synonymous with Java. If you want to run server-side Java, there are plenty of ways of doing it without having to use a J2EE server.
      phil wainewright
      • What is J2EE

        I know it is confusing. J2EE is so many things, a bit like .NET (but not really).

        If you want to work with Java to deliver HTML/XML, you go with J2EE. You don't have to go to the extremes of course. You can stick with Tomcat, which is a nice J2EE server. I think you are mixing it up with EJB containers...which are optional, but still part of J2EE.

        When you talk about J2EE, you talk about a whole variety of things, most of which you never have to use if you don't want to. You pick and choose what is good for your application. It's not a monolith.

        If you really want stretch it, you can use your database server as a web server these days and have it generate XML right from the database. Now you can drop the whole web tier away too. But that's stretching it too.
      • J2EE not required, but recommended...

        No, you're right. You absolutely could serve up AJAX applications with any technology. Ruby-on-Rails, PHP, Perl, Mono, Python with Apache and Linux. The author was just trying to make a case that AJAX was bad for J2EE vendors (Sun, IBM, Oracle, and BEA). I was pointing out real AJAX application deployments that are using J2EE web containers to power the application. The real-life evidence I provided is in direct contrast to the author's theories.

    • Clarify CRM is mostly Win32

      There is a J2EE version of Clarify, but it doesn't replace the Win32 version running on a Citrix or Terminal Services platform. Having it on Citrix gives you the full richness of a Win32 application while keeping bandwidth to a minimum.

      Web applications might be richer today, but they still can't compare with native client software. Outlook 2003 Webmail is one of the better web applications out there, but people still prefer using regular Outlook 2003 especially when you have the RPC over HTTP functionality that eliminates the need to use a VPN client.
      • Curious George...

        Yea. More rah-rah MSFT and their Win32 kindom is the apple of my eye speak from brother Ou.

        How about instead of purchasing and deploying ClarifyCRM + Citrix + run around and install the Citrix ICA client + purchase hundreds of Terminal Server CALs you just...

        1) Open a browser
        2) Oh wait! Your done. Happy pain-free CRMing thanks to AJAX powered by J2EE.

        Thanks for playing though,
  • I think Phil is part right, but is taking it a bit far

    AJAX removes some of the value from the application server, because it no longer has to deal with creating objects to get/populate data in HTML controls. The client is capable of keeping track of its own state, but there are situations where the server will need to keep track of client state as well, and application servers have facilities for making that easier.

    The client handles the UI. But the application server can still provide some value in that it has a rich API for handling XML in an OO fashion, handling the XML requests, as well as facilities for accessing a back-end database, something an AJAX client can't do directly. Plus, it provides threading facilities to more efficiently use system resources, unless Phil suggests going back to inet.d-style sockets and just handling requests that way.

    I saw another article on here by a different author saying "platforms are dead", because all that stuff is just a commodity. Well, not entirely. I think there are some pontificators out there who are getting ahead of the technology, are thinking conceptually, and are kind of buying into the hype of the moment. There are important technical details to these arguments that are getting missed. No doubt there are some business leaders who are thinking the same way, but I think it is to their detriment.
    Mark Miller