by Steven J. Owens (unless otherwise attributed)
There are three technologies that most people "get" (though you may still need to learn a lot about them): the browser, HTTP, databases. A web app lives in the gap between HTTP and the database. That is, in a concrete sense, the web app code lives and runs in that gap. In an application design sense, you need to think about how your webapp extrudes through HTTP into the browser. I think that not doing this is a fundamental usability mistake that a lot of good programmers make when they start doing web apps. A lot of what makes a good web app design is the proper partitioning of the amount of data and interaction on each given page (UI and information designers call it "chunking"), and what's in each request back to the server.
Note: there's also a very special and specific meaning of "web
application" in the java world. In that specific sense, a webapp is a
specific directory layout and set of data and class and configuration
files (most importantly the web.xml file) that defines a web
application in a servlet engine. Add some specific extra
configuration and tar it up using the Java jar tool in a very specific
way, and give the filename a ".war" extension, and you have a WAR
file, where WAR stands for "Webapp ARchive" instead of JAR for "Java
ARchive" or tar for "Tape ARchive".
It's also a specific thing
in a servlet-engine sense, meaning the set of running objects that the
servlet engine sets up for that web application when in use. In this
article, I'm throwing the term webapp around pretty loosely, but the
fact of the matter is that I mostly do java webapps, so I'm also
generally talking about the specific java concept of a web
application. For the most part, when reading this you can ignore that
very specific concept of a webapp, unless I tell you otherwise.
Here's an example of a run-of-the-mill workflow-oriented webapp: Alice uses the webapp to create a purchase order, then it shows up in Bob's account. Bob is Alice's supervisor, he has to click the "approve purchase" button, then it shows up in Carol's account. Carol is the purchasing department. Carol clicks on the "no way jose" button and it bounces back to Alice's account with a big fat "DENIED" label on it.
A web application divides up into a bunch of different components. Typically people see the breakdown fairly simplistically, as follows:
This is, in fact, the way the vast majority of early web applications were organized. The application code actually existed as a bunch of individual, stateless CGI scripts (most often written in perl), that pushed incoming data into the database and pulled it back out for display (and occasionally pulled it out, munged it with incoming data, and pushed it back in).
As the rest of the world started to clue in that maybe there was something to this Internet stuff, they started wanting (not necessarily needing, but that's another story) more complex applications. This started leading to more complexity in the CGI scripts, sequences and arrangements of HTML forms that only made sense in context with each other, more scaffolding code to make the CGI scripts less individual (not as discrete from one another, more stateful).
The most commonly cited - and as far as I can tell, completely imaginary - concern in this time span (about 97-99) was performance. The common performance fixation was on CGI script startup overhead and database churn. Startup overhead comes from the fact that each CGI request is handled as a separate process running a separate program from scratch - forking the separate process, loading the CGI script source file, loading any necessary interpreter or libraries, doing any setup necessary. Database churn is part of that setup - since scripts are stateless and exit after sending back the response, any necessary state has to be saved to a database at the end of each script invocation, and loaded back up on the next request.
Lots of folks came up with tools and frameworks to address these real or imagined needs. The Java servlet specification is one of them, and it's proven to be fairly useful. It is, like many things Java, a little less than you might expect. This means a little more work, but also a little more freedom. Typically in Java, you get just enough that all the hard work has been done, but you're not locked into a specific approach for a problem. I can see the sense in this, but there are times when it bugs me, because you end up "rolling your own" over and over, for so many commonly repeated tasks.
Lots of people have come up with add-on tools and frameworks to fill in that remaining gap. Most of them are useful to some degree or another, some are really, really useful, and many of them are less useful. But all of them seem to add a ton of complexity to the job, so I'm mostly unhappy with them. Mostly I just stick with plain old servlets, and JSP for the shallow stuff.