The Problem

Web development, for all its usefulness, often happens with a curious inelegance. It's kind of like making sausage. I like the result, but I don't want to see how it's made. Web programming in Java was better than web programming in alternative languages. It gave you more structure with easier maintenance and, often, better scalability than Visual Basic or Perl-based approaches, and an easier programming model than C++. But for all the benefits, certain problems make it seem clunky and awkward.

What You Want

Current web application servers might be powerful, but they're not convenient or natural. So, what is convenient and natural? It shouldn't take too much effort to figure that out. What if your controllers looked like this:

    if ( ) =  = true) { );

or this:

    if (shoppingCart.verify( )) );

That's better. What you really want to do is encapsulate the presentation of one or more web screens in a method. Then, more sophisticated page flows would not be a problem. You could simply roll up more and more pages into higher-level components. For example, you could take this code:

    checkoutAddress.showForm( );
    if(checkoutAddress.getSeparateBilling) checkoutBilling.showForm( );
    creditCardNumber.showForm( );

and roll it up onto a method:

    public static void showCheckoutWizard( ) {
      checkoutAddress.showForm( );
      if(checkoutAddress.getSeparateBilling) checkoutBilling.showForm( );
      creditCardNumber.showForm( );

so the usage becomes:

    cart.showCheckoutWizard( );

in its cleaner, refactored form. But you can't code that way, because your web server won't let you. Creators of most web application servers will sell their soul to keep things stateless and scalable.


Think of living without any short-term memory. Normal conversations in day-to-day life would be nearly impossible. Think of the logistics:

  • You'd have to write down every important phrase of every conversation as it occurred.

  • Then, when someone asked you a question, you'd have to look up the history of your conversation with that person before you could answer.

  • To optimize things, you'd have to decide how much information you should keep close bysay, in your briefcaseversus at home, in your filing cabinets.

  • When information got too old, you'd need to throw it out.

  • You'd have to maintain this whole system and revisit it when it didn't meet your needs.

That's the status quo for web developers. Your briefcase is the HTTP session, and your file cabinet at home is the relational database. It's an insane proposition, but we deal with the tedium because the Web is so important, and stateless solutions scale better. So, you willingly take a pretty large stride away from the ideal solution. Still, each time you struggle with the awkward little edge cases, you ask yourself if there's a better way, some kind of abstraction that fits the problem more neatly.

The Back Button

Saving state within simple conversations does not cover the whole problem. On the Web, conversations are not linear. Users can and do change their minds, pressing the Back button. Some assumptions that you've made as you continue to accumulate data may no longer apply.

Sometimes, you'll want to keep the user from going back, such as when she's made a purchase, or done something to force a committed change in a relational database. In these cases, you can simply punt and disable the Back button. Most often, you need to build special support for the Back button. You may even have to remove data from a database that a user would not have seen yet. Worse, many web designers simply don't solve the problem, and tell the user to expect unintuitive behavior. You've taken one more step back, away from the ideal. Once again, this awkward Back button forces you to deal with things on a case-by-case basis, and it just doesn't feel right.


Web development in Java focuses an incredible amount of brain power around navigation and flow . You'd think controlling flow from the server side would be natural, but servers can't update clientsthey can only respond to requests. This simple little truism forces servers to handle hundreds of little requests rather than a couple dozen application flows. It's also hard to synchronize the user interface with the model. You'd like to use a simple method call that controls the user interface and model, but you can't. The web server just doesn't work that way. And you're stepping back again, and you've got that sinking suspicion that there's a cliff behind you somewhere.

Continuation Servers to the Rescue

A new class of web servers called continuation servers is starting to make some real noise. A continuation server uses a programming construct called the continuation to keep enough information about a request to be able to completely reconstruct the context. In technical terms, a continuation saves the execution environment, including the call stack. In practical terms, using continuations in a web server lets the server maintain context for you, freeing you to program in a more natural way.