gregw
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.
Posted at 03:44AM Dec 18, 2003 by gregw in Servlets | Comments[0]
