Will Web services replace today's thin clients? Or are Web applications here to stay? |
 |
|
| > |
QUESTION POSED ON: 17 December 2002
Do you think Windows forms over the Web with Web services will replace
today's thin clients? Or do you think the convoluted (HTML, JavaScript,
XML, XSLT, and ASP.NET) thing we call a Web application is here to stay?
|
|
| > |
Hey. This is a great question!
Here's my take. Recently, I've been thinking more and more about the
end-to-end argument. This is a principle that was put forth by Dave Reed and others while at MIT (Dave helped invent the guts of the Internet). The gist of the argument is that moving smarts out to the endpoints in a system is the way you build flexible systems. Allowing the machines at either end of a conversation to figure out the best way to cooperate is a more efficient, flexible and "opportune" way to design systems. If you jam smarts into the infrastructure and rely on those smarts, then if the smarts turn out to be not-so-smart, or if there is something else you want to do the you're usually out of luck. By allowing/encouraging the endpoints to implement the smarts then your world of opportunity is much greater.
Ok, so what does this have to do with anything?
The Web and Web applications flourished in a large part because the infrastructure (computer, LAN, WAN, transport protocols) made little to no assumptions about the applications they would support. Developers could create browsers, fat applications, crawlers, application servers, all without getting permission or requiring an engineering feat in the core. Super important. You can't do this, for instance, with the PSTN. The phone companies own the guts and any smarts in the network.
Ok, still so what?
Much of the end-to-end advantage is that as problems or new requirements arise, anyone can propose, test and deploy a solution on the infrastructure. With plain-old Web applications, the infrastructure is pretty dumb. This is the reason things are so convoluted, right? Cookies, server state, stateless client scripts, server scripting, CGI. Ugh! But, here's the important bit. As problems arose, new solutions could be implemented. No one needed permission to write a CGI program, or implement state management (state management mechanisms were originally implemented with URL munging before cookies were added to the "infrastructure"). No permission required, innovation from a huge group of real-world-problem-motivated developers. This continues today with the evolution of other Web protocols (One of my recent favorites, RSS, has a messy history, is arguably dirt simple but solves a real problem and is enabling fantastic things to start to happen with syndicated content. End-to-end is working. It rules).
I'm getting there, I promise.
Click here for part two of this answer.
|
|
|
|
|
|
|
|
Search and Browse the Expert Answer Center
Search and browse more than 25,000 question and
answer pairs from more than 250 TechTarget industry experts.
|
|
|
|
|
|
|
|
|
|
|
|
