What is a web application?

Next week, I'm going to be taking the official Microsoft .NET Framework 2.0 Web-Based Client Development Certification test (Exam 70-528). I decided that over the next several days, I'll post on what's covered in the current Asp.NET 2.0 framework as well as some tips and tricks to using Visual Studio 2005 for developing web applications. Let's start out with the oh-so-overlooked question: What is a web application?

Web applications started out much simpler than they are today. Just because you can create a full web app in 5 minutes doesn't mean you shouldn't know how it used to be. Before IIS, Apache, Visual Studio and even Eclipse :P

HTTP
HTTP stands for Hypertext Transport Protocol used to transfer or convey information all around the web. While it's original intentions where to transfer documents, it was created for a standard transfer of web-documents (or documents that people could view and transfer with each other in a standard format). Simply put, a client/server technology built on top of TCP/IP.

There are two parts to HTTP. Request and Response. Wherein, the request is coming from the web browser's http handler to the server and the response is coming from the server back to the web browser's http handler. An HTTP request consists of one of 4 methods.

• GET
• POST
• PUT
• DELETE

With a web application you're more likely to only use GET and POST. WebDav is an example that uses PUT and  DELETE.

* In the older days, put and delete were used with web services.

At any rate, you'll find that in any one of these methods the request will look something like this.

GET /index.html HTTP/1.1
HOST: www.vox.com
User-Agent: Mozilla/5.0
Accept: text/xml,application/xml,application/xhtml+xml,text/html
Accept-Language: en-us
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8
Keep-Alive: 300
Connection: Keep-Alive

* Essentially you have the Request line followed by Headers and Cookies.

Alright, that leaves us with the Response.

HTTP/1.1 200 OK
Content-Length: 30960 Content-Type: text/html
Content-Location: http://www.vox.com/index.htm
Last-Modified: Mon, 19 Dec 2007 23:29:34 GMT

.....

A header including the response code, cookies and any other metadata about what's being returned. And of course the actual body of the response (i.e. the data we want to receive).

Most HTTP servers back then were designed for returning just static files. When we wanted to do something more interesting, CGI came into play.

CGI  is the Common Gateway Interface. An HTTP server passes the environment off to another process. This all, of course, started out as simple shell scripts like formmail; evolving into using scripting languages like PERL and PHP.

* Interesting tidbit, PERL was created because Larry Wall got tired of doing it in C over and over. Figuring, I'll just write my own language. :P

At any rate, what's going on here when a browser sends an HTTP request to a web server?

The problems that ended up arising in CGI, even with FastCGI, was that it forked a new process for every CGI request. Meaning slow performance due to the CPU forking process (i.e. context switching) and even the communication between the web server and CGI process. Under normal loads, it really doesn't matter since you'll never notice a difference. But it doesn't work so well when you happen to have 100's of logins per second.

After the coming of Java and .NET processing making dynamic web apps were a sinch. Simply because it's one process running using thread pooling instead.

So a quick run-through on the technologies up to this point in time for creating a web application.

1. Transport Protocol (UDP/TCP/VTP/SCTP)
   
2. IP (TCP/IP)
3. HTML
4. HTTP
5. CSS
   
6. XML
7. Thread Pooling
   
8. CPU Processing
9. Port Identification
10. Web Server
11. Interpretive Server Process (CGI/Asp.NET/J2EE/PHP)
12. HTML/XHTML Rendering Engine (Web Browser)

A series of technologies that when bundled together and on top of one another, we're able to create dynamic tools and resources so that information is a) more accessible and b) simpler to use and extend.

So, the next time a Flashy New Web 2.0 application comes out just remember and ask why it was created. We're too often in our industry asking the how's and what-ifs of creating things when we need to be asking whether or not we should do something.

Until next time :D