One of the questions most frequently asked about web application development goes something along the lines of,

"I am interested in becoming a web developer, but I don't know where to begin. There seems to be so many technologies in the field of web development that I feel lost. How do all these technologies relate to each other, which ones do I need to learn in order to be considered a serious professional, and which one should I learn first?"

Well, in this tutorial, I intend to answer this question by stepping back from the realm of specific technologies and focusing on a general survey of web application development. In doing so, I'll try to provide a broad framework with which you can make sense of the mosaic of available technologies, programming languages, standards and protocols, and tools.

"It seems to me that my job as a webmaster has continually been about fitting together a zillion little puzzle pieces. This piece talks to that piece and that piece talks to this piece. It is easy to get overwhelmed." - anonymous reader

I have heard this statement about a hundred times in one form or another.

I guess I can see why someone would say that building web applications is like putting a puzzle together. The myriad of web application development technologies could certainly look like a jumble of puzzle pieces.

However, understanding web application development in terms of a puzzle metaphor is just about the worst thing you could possibly do for yourself! This metaphor only leads to confusion and if you adopt this metaphor, you'll quickly find yourself becoming overwhelmed with the myriad of technologies.

Web application development technologies are definitely NOT puzzle pieces.

Puzzle pieces fit together in specific, "correct" ways. That is, although puzzle pieces look similar in many ways, every piece is very different from every other piece. One piece cannot be substituted for another piece unless you want the final picture to look really weird.

With a puzzle, there is always a single, overarching, "right" way to put the pieces together and each piece is unique.

In web application development however, there is no right way to solve a problem and no truly unique technology. Rather, there are multiple possible configurations of essentially redundant tools, each which solves the same set of problems.

For example, as we will see later, CGI, ASP and Servlets all serve the same basic function. They perform server-side processing. Similarly CORBA, DCOM and enterprise Java Beans specify how to talk to distributed objects. Likewise XML, HTML, SGML, XSL and CSS are all similar tools for marshalling and displaying data across a network.

As such, web technologies within the same categories, can be used interchangeably in MOST situations. Choosing one or the other may often be more of a bureaucratic/administrative/standards decision than a technical one.

Rather than using a puzzle metaphor, I like to think of web application development in terms of legos. With legos, there is no overarching "right" way to solve a problem. There are just a whole bunch of block categories (6 hole, 4 hole, 2 hole) which can be put together in an infinite number of ways.

Certainly there is variety within the categories (some 6-holed pieces are red; others are blue), but all lego blocks, regardless of their individuality within a category, are still equivalent as members of their category.

The lego metaphor provides a way for you to make sense of the forest of existing technologies and the forest of future technologies. Rather than understanding each technology on its own, you need only understand the categories into which individual technologies fall. Once you understand where a technology fits into the scheme of a web application, you already understand 60% of that technology.

Okay, let's start getting into the thick of things.

If you are reading this, you probably already have some conception of what a web application is and does. You might even be tasked with setting up a development environment at your office to start producing web applications in support of your business. However, even if you are totally new to the field, don't worry. Web applications are actually pretty simple conceptually. (Note: You might want to check out some of the more introductory tutorials at Web Ware)

Essentially, all web applications do pretty much the same things

1. Provide a Query Interface - Web Applications provide users with an interface for entering data. The data they enter is usually called a "query" or a "request" because the user-defined data is used to dynamically query or make a request from some service on the web server machine (searching a database, ordering a book, requesting a file).

2. Transmit User-Defined Query - Once collected, the user-data is sent to a web server

3. Perform Server Side Processing - The web server processes the user-data using some sort of "middleware".

4. Massage Data - Processing almost always involves playing with data on the server. The user-defined request specifies how the data should be played with

5. Transmit Query Results - The processed data is now returned to the client

6. Perform Client Side Processing - Finally, the returned data is displayed to the user. Display might be as simple as interpreting HTML, or as complex as performing calculations, sorting, or other manipulations of the data.

Consider the following generic web application work flow diagram.

And that's it. As I said, web applications are conceptually very simple!

Let's quickly look at the most basic example of a web application (so simple it is hardly a web application at all). Consider a straight HTML request in which a user 1) instructs a web browser to 2) contact a web server using the HTTP protocol, and 3) ask it for a specific 4) HTML document which the server 5) returns to be 6) displayed by the web browser.

We might also have a slightly more complex example. Suppose a user supplied search parameters via an 1) HTML form that the web browser 2) sent to a web server using an SSL connection. The web server might 3) process that data with a CGI script by connecting to a 4) data file, searching it based upon the user query, and 5) sending back the results to be 6) displayed in the web browser window as a table.

This pattern could be made much more complex of course. For example, suppose we have a 1) Java client which 2) sends an encrypted request to a Java Web Server 3) which processes the request with a Java Servlet that uses a CORBA object to systemically generate 4) financial trade data in the form of XML with an associated XSL style sheet that is 5) sent back to the Java client to be 6) parsed into an XML Tree and displayed according to the XSL.

As you see, in the web application work flow, a motley of technologies can be used to perform various tasks.

In fact, there are literally hundreds of technologies and tools used throughout this simple process. The sheer number of pieces is why many developers feel overwhelmed when they look at the processes of web application development. However, regardless of how many technologies are involved in a project, for the most part they can all be placed into one of four conceptual categories.

That is, a technology will fall into the category of 1) the display layer (GUI), 2) the communication layer, 3) the middleware layer, or 4) the data layer.

You'll see that when you confront a new web development technology, that if you can place it in one of these categories, that you will immediately understand what it is, what it does, and probably most of how it does it. Every technology has its own syntax and quirks of course, but armed with this broad understanding and a desk reference book, any new technology should incorporate into your toolbox within a week or two regardless of how cryptic the acronym is.

But perhaps a picture would be best here. Consider the sections in the typical web application and what tools fall into the categories. In the next sections we will focus on each of these categories and the technologies they harbour.

Looks quite complex eh? Well that is the reason web application developers can get overwhelmed. However, as we've been saying, there is no need to feel overwhelmed when you can take this giant lego statue apart and examine it block by block.

Let's start with the Display/GUI Layer.