[Web-SIG] Web Container Interface

[Greg Ward]

[me, commenting on what the Java folks got wrong]
>  * the level of granularity is wrong: most Java web applications
>    consist of multiple servlets, and if the code I work on in my
>    day job is any indication, there's a lot of overlapping code
>    among the servlets in a given application.  Thus, the point
>    of entry between a web application container and a collection
>    of web applications should be... the web application.
>
>    (The Java community has figured this out; when you administer a
>    modern servlet container like Tomcat, you generally work at the
>    level of web apps, rather than individual servlets or the whole
>    container.  The existence of "servlets" as a separate entity
>    complicates both administering a servlet container and writing web
>    applications.  It's a nasty design flaw that we should strenuously
>    avoid.)

[Ian asks for clarification]
> Can you expand?  Do you mean that servlets as an exposed resource are 
> unnecessary, and that the only exposed resource should be the 
> application as a whole?

That pretty much nails it.  There should be exactly one programmatic
point of interface between the container and the application, and it
should almost certainly be an instance of a class named something like
WebApplication.  (This is where the mythical runCGI() method should
exist.  Although that is clearly the wrong name; I'd prefer
handle_request() or something like that.  Or even just run() or
handle(), what the heck.)

At work, I'm in the (unpleasant) position of maintaining a legacy web
application written as a collection of similar servlets that just write
HTML to stdout -- the Java equivalent of a bunch of CGI scripts, really.
However, we're running it under a modern servlet container -- Tomcat --
that implements a recent version of the Java servlet specification,
which in particular specifies just what a web application is, how it's
executed, how to configure it (ie. describe it to the servlet
container), etc.

(You can download all 330 eye-glazing pages of the servlet specification
from http://jcp.org/aboutJava/communityprocess/final/jsr154/index.html;
the struggle to get that far is alone indicative of how vastly more
pleasant working with Python is.  It's a continual source of amazement
to me that Sun has not succeeded in killing Java with sheer bureaucracy;
I guess lots of programmers just love those curly braces and static
types.)

Anyways, the annoying thing about writing web apps in Java is that as a
*programmer*, I primarily work on servlets, but to actually get those
servlets to run -- ie. if I pretend to be a sysadmin for a few minutes
-- then I have to step away from the code and start mucking around in
complicated XML config files that describe my web application(s).  And
how do you describe a web application?  By listing the servlets that
implement it, of course!  So the sysadmin has to be pretty intimately
aware of how the application is constructed -- eg. which classes handle
which URLs -- and the programmer does not work at the most natural
level.

That said, I think modern Java web development has moved beyond writing
individual servlets -- they're still there, but whatever framework you
use takes care of providing the actual servlet class; application
developers just write handlers that the main servlet calls.  (At least
that's a very vague, hand-wavey overview of how Struts, which is a
popular framework over in Java-land, works.  I know little about Struts
and nothing about any other Java framework.  They're all pretty pathetic
compared to Quixote, as far as I'm concerned.  ;-)

> Which may in turn be factored into servlets, 
> but that's up to the application to determine...?

I think if the notion of "servlet" had never existed, no one would have
bothered to invent it.  As far as I can tell, it was just some silly
idea cooked up by some pinhead at Sun that caught on because, well, lots
of programmers like curly braces and static types, and Java's the best
curly-braces-and-static-types programming language out there by a long
shot.  They got the HttpServletRequest and HttpServletResponse classes
dead-on; I'll give them that much credit.  And the session management
seems pretty sound.  But the rest of it... I'm not so sure.

        Greg
-- 
Greg Ward <gward at python.net>                         http://www.gerg.ca/
Budget's in the red?  Let's tax religion!
    -- Dead Kennedys