If you are interested in the the application of these principles there is a Silkworm White Paper thats worth a look.

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’.

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.

BRAOUMMMM! (the sound of Alex’s head exploding)

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.

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.

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.

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.

Is Phil Wainewright actually a developer? From his bio it looks like he’s just a pundit.

Phil’s credentialed as far as I’m concerned. I just caught this quote from him on Patrick Logan’s blog:

I’ve determined that I’m no longer convinced that software
engineering, at least as it’s commonly discussed and taught,
is what I want to prepare students to do. I try to focus them
on being innovative, entrepreneurial, and working with dynamic
languages on networked applications.

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.

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.

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.

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