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.
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 Salesforce.com, 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."
Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.
Talkback
Another "new thing kills old thing" story?
Much as I dislike Microsoft's corporate behavior, AJAX isn't going to be killing off anything anytime soon.
Regards,
Jon
Maybe you misunderstood
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...
-Bryan
Imagination can be a great limitation to human productivity
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 ?
http://groups.yahoo.com/group/AJAX_2-0
Silly article...
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.
-Bryan
J2EE to deliver HTML???
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.
What is J2EE
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...
-Bryan
Clarify CRM is mostly Win32
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...
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,
-Bryan
I think Phil is part right, but is taking it a bit far
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.
RE: How AJAX kills the application server
RE: How AJAX kills the application server
RE: How AJAX kills the application server
RE: How AJAX kills the application server
RE: How AJAX kills the application server
RE: How AJAX kills the application server
RE: How AJAX kills the application server
RE: How AJAX kills the application server