Now that the 2.4 servlet spec is final, I believe the time is right to start
considering the end of life for the API. This may sound a little
strange coming from somebody on the JSR and who has spent years writing
a servlet container, but I think the API has outgrown it’s original purpose
and no longer is the best API to go forward with.
The problem is that servlets are trying to be too many things to too many
people. One one hand servlets are protocol handlers, able to control the
the details of connections, transport and encoding. But they are also
intended as application components, to be used by presentation programmers
and to be plugged and played with during deployment. There is also the
the whole stand-alone versus J2EE application server issue within the
specification.
The problems that result are many:
- Web Applications commonly get deployed with their own CompressionFilter,
XML parser, logging jars and authentication mechanism. What exactly is the
"application" infrastructure being provided to them? - Because protocol concerns are implemented within application components,
the extensibility and portability of the container is limited.
For example, compression could be implemented more simply, uniformly and maintainably
by the container. Instead we have many web applications shipping their own copy of
the CompressionFilter, complete with the bugs of the original sample code.
It also limits the efficient portability of servlets, even over versions of HTTP.
It is often good practise for Servlets written for HTTP/1.0
consume memory and CPU calculating the content length so that connections can
be persisted. Because this HTTP concern has been implemented by the
application, it cannot be disabled when the servlet is deployed in a HTTP/1.1
container that does not need content length for persistent connections. -
Servlet containers are unable to take advantage of non-blocking
NIO because application servlets do their own IO assuming blocking semantics. Nor
are HTTP features like range requests, trailers and accept headers able to be
used without involving the application developers. - The contract between servlet and container is not well defined for HTTP headers.
What does it mean in when a servlet sets a HTTP header?
Is it a command to the container to do something (e.g. Connection: close), a signal
that the serlvet has done something (e.g. Transfer-Encoding: gzip ) or a helpful
hint that the container can use,ignore or enforce (e.g. Content-Length: 42)? - There is no standard lightweight deployment package for HTTP consumers
such as SOAP. A full 2.4 web application container is a bit of overkill if
all you want to do is transport XML blobs. Why should you have a fully
capable web tier just to accept web services?
I believe the answer to these woes is to create a new API that is purely about
content and is really protocol independent. This API would allow for the creation
of Contentlets, which are application objects that can be selected and queried for meta data and
content without reference to HTTP headers, transport encodings, threading or streams.
Contentlets would be equally able to serve their content over HTTP, email, rsync or
whatever new protocols that emerge that fit a generic request/response style.
It would be the responsibility of the transport implementation to pull meta
data and content from the Contentlet. This is the opposite of Servlets, which push
HTTP headers and content, even if they are not required or accepted by the client.
The Container would be able to efficiently implement transport features such as
compression, conditionals, encodings, ranges and protocol specific features.
The application components could be written with no concern for transport
and thus application developers need not become protocol experts in order
to write save, portable and efficient code.
Of course Servlets could be used to initially implement Contentlets, but
the eventual aim should be to have direct HTTP to Contentlet containers,
perhaps built on a revamped and simplified Servlet 3.0 API? Either way,
we need to begin thinking about the end-of-life of 2.x Servlets.