Fundamentals of Servlet Design

Justin Wells
webmacro.org

This section of Fundamentals of Servlet Design analyzes web development and produces a list of requirements for Java servlet design. The next section proposes a solution.


Issues in Servlet Design

Java servlet design exists in a context. In order to understand the right way to look at servlets, take a step back and look at web development in general.

I've been developing web applications since 1995--I've developed web sites, put web front ends on several products, designed products out of servlets, and built a generic Java servlet framework.

In all that time, I've noticed a few things about web projects--they're a little bit different than other kinds of projects, and any design must accommodate the particular nature of the field.

This article goes through the issues that relate to developing for the Java Servlet API and web development in general.

Here's what I think:

Servlet development involves teamwork

A typical web development project involves one or more programmers, page designers, and customers, all working together to build the final product.

This gives us our first requirement, which is so fundamental that many people overlook it:

A servlet design is no good if it means the page designer has to depend on the programmer to make look and feel changes. It's also no good if the page designer can't do any work at all until the programming is done--people need to work in parallel.

Servlet development must be rapid

Customers come to servlet developers with a most basic question: What can servlets do that will help me out?

Initially there will be many good ideas, but not much certainty. Customers generally need to see some results before they know what they want. This puts web developers in an uncomfortable position: "Build it and I'll tell you whether I want it" is not on the road to success and profit.

However, if misused the servlet API can actually increase the time required for development versus a popular tool like PERL or PHP.

The correct approach is to spend a small effort generating something that is just good enough to give the client a better idea. Then allow frequent changes as the project moves forward. Your servlet design must accomodate this.

From these observations I derive three requirements for servlet designs, which can be summed up as "a good servlet design supports rapid development":

Without the ability to show the customer something early, you'll build the wrong thing. And even after you've built the right thing, the customer will want to tweak it. And in order to know whether what you're doing is the right thing, you need to show it often.

Servlet development is complex

Software systems are incredibly complicated. People only hope to understand them by breaking them down into simple components that are easy to understand. The idea is to abstract out the important principles, and illustrate them clearly in your servlet code--only then can a programmer look at the whole and feel like it's well understood.

Similarly, page design is hard. And unlike programming, it cannot easily be broken down into component parts. Instead a good designer looks at the whole and, based on experience and artistry, decides how to improve it.

Both of these tasks are fairly complex, and need to be supported by any servlet design.

So here are two more requirements:

If the servlet programmer can't write clear code, then they'll have trouble illustrating the key abstractions. Next they'll feel they don't have a competent grip on how the whole servlet works. They'll make mistakes, or else avoid making changes out of fear of making a mistake.

If page designers can't deal with the page as a whole, and change whatever they want easily, then they won't be able to do a good job. Their task can't be broken down into separate parts as a program can: how a title is formatted depends on everything else on the page.

Since these two ways of working are incompatible, this leads to a new requirement:

The two problems can't be broken down the same way, cannot be solved the same way, and often involve different people anyway.

Servlet development is client/server

You don't have much choice here--there's a web browser, the client, and your servlet lives on the server, accepting requests and generating responses. Your job is to figure out how to get data back and forth, when to get it, and how to track it.

Here is that last bit, restated as a requirement:

The immediate consequence of a client/server architecture is that the server must track the client and figure out what it's been doing; whether all the appropriate information has been supplied; whether all the correct steps have been followed--for example, perhaps a user must log in before posting a message.

Many designs bury interaction control in HTML and/or the back end, without clearly expressing it anywhere.

Soon people working on projects like this find themselves spending an inordinate amount of time trying to comprehend how all the pages and information fit together in an expensive attempt to solve some mysterious bug.

A good design simplifies this work by allowing session management and other client/server issues to be dealt with from a well defined place, separate from the other work.

The Right Way to Design A Servlet

The next section presents the right way to design servlets.

Next: Servlet Design


Introduction | Download

api | design | faq | goals | links | license | othertech | quickstart | script | status