by Steven J. Owens (unless otherwise attributed)
This is an attempt at a concise, high-level overview of web application development in java. You may also want to check out:
Java Web Applications, Part 0A web application is an application that uses a set of related web pages as the user interface. You usually have to login with a username and password to get to any of the pages, and actions you take on one page will show up on other pages.
Coding an application as a web application has some weaknesses. The main two are when you need realtime, up-to-the-fraction-of-a-second display of data, or when you need very complex user interface interaction. Most of the time, when people think they need these, they don't. They're just borrowing a lot of trouble. But when you absolutely do need them, they're the weakest point about web applications.
Someday I'll come back here and talk about advantages. For now, I'll assume you're smart enough to see the advantages. I will say that often some of the big advantages are what people think of as limitations. HTML forms are quick and easy to build, but make it hard to express complex UI behavior. On the other hand, this makes you put a little less work into "make it spin" and a little more work into "make it useful".
Here's the roadmap we're going to follow:
I'm going to start this by taking a look at the servlet engine framework.
There's a ton of material out there on HTML and browsers, and most people know a fair bit about those topics anyway, so I'm not going to start there.
Likewise, there's a ton of good material out there on databases and on serious enterprise development, large, complex applications, and various frameworks people have devised to make it easier to do web applications, so I won't stress that as much.
Later on I'll probably come back and take a look at how you should use those layers to structure the application, which is a problem a lot of serious programmers run into when they start doing web applications. The temptation to keep the browser layer as thin as possible, or even try to hide it from themselves behind a layer of automation, seems to be too seductive for them. But then they end up reinventing a lot of what's already there, or spending a lot of time mapping their framework to the servlet engine framework or to the nature of HTTP.
JSPs and servlets seem to be the heart of the matter, and since JSP is just a tool for somewhat more easily generating presentation-oriented servlets, I'll explain servlets first and then get into JSP.
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, less stateless).
The most commonly cited - and as far as I can tell, completely imaginary - concern in this time span (about 97-99) was performance, both of CGI script overhead (startup overhead - CGI scripts are run from scratch for each request - and general overhead, because each CGI script is run as a distinct process, with its own copy of the interpreter and environment) and of database churn (since scripts are stateless and have to pull any necessary state from the database for each 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.
Lots of people have come up with add-on tools and frameworks to fill in that remaining gap. There are some trends I've noticed, some lines of division that commonly occur and reoccur (or should :-). Some of these are obvious, and defined by the applications that make it up, some are less obvious but still formally defined, some are implicit in the structure, and some are just a good idea and have become common practice.
First, and this is something most people don't bother with, but I think it's important, you have to be more explicit about the protocols and framework. I'll repeat that list with these things added in, the new stuff in bold:
You should also more conscious of the natural chunking that HTML brings into the picture:
Finally, on the application side you'll find it useful to carve up the code a bit. Here's my full picture:
As usual, these aren't as neat and even as it looks at first glance. These "layers" interpenetrate and overlap each other, and some of them don't really exist without the others to define them. (I really need to find a better term than "layers", but I haven't found one yet.)
Note that I haven't said much about javascript. I consider javascript to be a trap that people get bogged down in. It's occasionally useful in very small doses, but a treacherously slippery slope. You inevitably end up with large doses, and sooner or later in there the application gets critically entangled, and your development effort bogs down.
Continued in Part 2