The New “Application Server”
By Ryan Tomayko under Then you win. on 03. October 2005I haven’t had as much time to follow the press as I’d like but they seem to be catching on at a frantic pace. Phil Wainewright (of Loosely Coupled fame) has an article up on ZDNet entitled How AJAX kills the Application Server:
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.
The new “Application Server” is a web server, a dynamic language, and templating.
I also like how we’ve decided to call this setup “rich internet application platforms”. Personally, I think “The Web” is a better term, but you can call it “Sponge Bob Square Pants” for all I care. Let’s get on with it.
The industry is realizing that there are very few business applications that you cannot build with this basic set of components. What’s more is that all that is needed to transform the basic setup into an integration platform is to stop thinking about the web as a bunch of “pages” and start using HTTP for what it’s worth.
People everywhere are asking themselves what this mess of crap of technology they’ve accumulated is really doing for them. It’s about time.
Simon Willison:
I got a very strong whiff of BS from that article. You still need plenty of server-side logic for an Ajax application - aside from anything else, the security implications of letting the client query the database directly are horrifying. More to the point, if you are using Ajax techniques responsibly stuff should still be more-or-less usable without the Ajax bells and whistles. Is Phil Wainewright actually a developer? From his bio it looks like he’s just a pundit.
comment at 03. October 2005
Alex Bunardzic:
Once again Ryan hit the nail on the head. It’s about time we start looking at all these fractured, disjointed pieces of a puzzle in a more positive, flowing light. You know the way entity-relationship design flows so beautifully from the inception all the way down to css and DOM? Like, in Rails? There’s your full blown stack of a complete, harmonious solution that is a joy to build, polish and maintain .
comment at 03. October 2005
Mike Champion:
“People everywhere are asking themselves what this mess of crap of technology they’ve accumulated is really doing for them”
Having spent 1999-2004 being paid by a mainframe-generated revenue stream I may be biased, but the mess of crap technology, uhh, keeps the brown smelly stuff out of the food chain. I strongly agree with Simon Willison’s point “security implications of letting the client query the database directly are horrifying”. Sewers and other bits of nasty infrastructure are ugly and smelly, but the world is far better off with them than without them.
That’s not to say that I disagree that application servers tend to go away with better client side technology such as AJAX (we get a lot of similar questions about whether LINQ makes the middle tier irrelevant). It might mean that the UI-related functions of an app server migrate to the client side and the security/integrity functions migrate to the DBMS …. but note that this pretty well refutes the theme of the previous posting here about “Should Database Manage The Meaning? “. The DBMS had damn well better manage a whole lot of meaning if you take the app server out of the picture and have untrusted clients make direct requests to a DB.
comment at 03. October 2005
Alister:
I thought the only thing AJAX did was allow you to call the server without requiring a page refresh. Either way, you’re still making calls to the server.
How does this eliminate the need for an application server? You’ve got a web server, a database, and what exactly? Where are you putting your business rules/security/session management?
comment at 03. October 2005
Aristotle Pagaltzis:
Alister: you’re making calls to the server, but it need not be an application server per se. It could be nothing but a relatively thin layer over a database that just exposes the data in web-friendly fashion; and it wouldn’t even be completely stupid or crazy, assuming this layer were coupled to the database via, say, stored procedures rather than allowing direct manipulation (cf. Mike’s comment).
Which is an idea I like, at least in theory—in this world, the server’s just the model, and the view and the controller have migrated to the client. (As opposed to the web of today, where the server is all three, and the client is merely a pretty dumb extension of the view.)
comment at 04. October 2005
as days pass by » Not a bunch of pages:
[…] Ryan over at lesscode.org often speaks the truth, but never more so than in The New Application Server: What’s more is that all that is needed to transform the basic setup into an integration platform is to stop thinking about the web as a bunch of “pages” and start using HTTP for what it’s worth. […]
pingback at 04. October 2005
curthibbs:
It all depends on your definition of “application server”. In the end, I think that spliiting hairs over this definition is pointless.
There is a continuum between these two extremes: dumb-client and all the application logic residing on the server and smart-client with little or no logic on server (database only?). Desktop applications fit at one end and web 1.0 sites fir at the other. What AJAX does is shift the focus point on the line between these two extremes closer to somewhere in the middle.
The point is that there are things that the server does well and things that the client does well. Finding that ideal balance is what AJAX enables.
comment at 04. October 2005
Ryan Tomayko:
Sorry, I didn’t take nearly enough time to explain my position. What I wanted to point out was that AJAX on the client is causing people to think about their normal web server as an integration point, which is what I’ve been advocating since this site went up. Thinking about your web server as an integration point isn’t specific to AJAX, but AJAX is showing the value in that way of thinking.
I’m not suggesting that we let the browser through to the database, I’m just saying that the same techniques we’ve been using to serve pages in a simple manner (MVC, templates on top of a database, with some business logic organized in some basic and simple way) provides a large portion of the functionality people have been pursuing in the big enterprise application server area.
The feeling I got from Phil’s article isn’t that he was suggesting that there’s nothing between the client and the database, I thought he was suggesting that there’s no middle “application tier”. It’s a web server with an embedded dynamic language and a database. One very typical scenario for enterprise applications is the three tier architecture: a web server, a middle-tier (application server) exposing remote objects, and a database. What I thought Phil was realizing in this article is that the middle tier is going away. Portions of it are shifting up to the client and other portions have become overkill with the rise of the shared nothing architecture / dynamic languages.
My apologies for a really vague post. I didn’t go into enough depth in my initial post. I knew I hadn’t when I posted it. My bad.
comment at 04. October 2005
Ryan Tomayko:
Simon said:
Like I said, I don’t think he was suggesting that you let the browser straight through to the database. That’s insane. There’s just no way he was suggesting that.
And there’s a huge difference between what you call “server-side logic” and what Enterprise IT heads call “server-side logic”. We’re talking about massive three tier systems, distributed objects (DCOM/CORBA), messy session replication, EJB entity beans, etc. I think its this level of bloat Phil is refering to here. He’s saying exactly what we’ve been saying: you don’t need it. Shared nothing, simple languages, etc.
Of course. But your seeing the “web page” communicate with the web server in a way that is very new. It requires you to think about the web server as a middle tier - an integration server, not just a dumb box for serving pages. It’s fronting your business logic and exposing your resources. This is such a massively different way of thinking about distributed systems in business IT that I’m surprised no ones head has exploded yet.
I think we’re all way to close the web to understand the significance of what he’s saying here and the audience he’s saying it to. This kind of thinking (that web servers are very powerful components for composing systems) has never been accepted in business IT. Simon, you’ve accepted it for, what, seven years now? I think your underestimating how far ahead of the curve you are.
Phil’s credentialed as far as I’m concerned. I just caught this quote from him on Patrick Logan’s blog:
I don’t know his background but he’s one of the few writers on mainstream IT sites who I see consistently trying to steer business IT toward the web. He’s not a Web 2.0 luminary or anything but a large portion of the people who read him haven’t even heard of Web 2.0.
comment at 04. October 2005
Alex Bunardzic:
Ryan wrote:
BRAOUMMMM! (the sound of Alex’s head exploding)
comment at 04. October 2005
Anonymous:
This is a crock, and here’s your proof - You guys can’t even agree on what he said. I believe with Ajax that an application in the browser, for each target platform, is even MORE EXPENSIVE and error prone than using the native APIs provided by each target OS. This is simply ridiculous.
Use HTTP for what it is? Yes, please, by all means. And HTML as well. But please please please stop bolting crap onto it. You want a stateful transaction link? Fine. Write the gorram protocol. But for the love of Pete, please do not tack it on to HTTP with some brain-dead inanity such as sending a “cookie”, lord help me, for which, evidently, no one can agree on a correct implementation. That is sheer stupidity. And it was only a hint of the insanity we have now. PLEASE STOP THIS IDIOCY. Please stop cramming “just one more thing” into HTML. JUST STOP.
And people said that ASN was too complex and SGML would be too hard to implement. Sheesh!
comment at 05. October 2005
Anonymous:
Are all the Google Maps Mashups BS? Where are their Application Servers?
Take an example application such as Libmap. This research example mixes a Silkworm Directory Web Service (delivering description, location, and access information about libraries) with the Google Maps Web Service. Obviously the constituent Web Services are powered by their Application Servers, but the actual application has no application server of its own, apart from a boring read only web server to hold the page, CSS, and javascript files, the application it’s self only exists in the browser.
In the Web 2.0 architected world, the delivers of Web Services (from traditional application servers - perhaps we need to rename them Service Servers) will not know, or even care too much, what actual AJAX - in browser applications they are supporting.
Of course the application server is not dead, but it not necessarily the best place to build the application the user interacts with. It’s power, structure, and control is most beneficial when applied to core business logic and process delivered as a Web Service to be consumed by potentially many ‘applications’.
comment at 07. October 2005
Richard Wallis:
Whoops, I didn’t mean to be anonymous with my comment above.
If you are interested in the the application of these principles there is a Silkworm White Paper thats worth a look.
comment at 07. October 2005
AJAX and the new application server « Curt’s Comments:
[…] ZDNet has kicked off a blog debate over the fate of the application server with Phil Wainewright’s article How AJAX kills the application server. […]
pingback at 08. October 2006