Monday, March 05, 2007

Ok, Tomcat 6 is out and stable and contains new type of servlet called Comet (more info on Tomcat’s version is here), new Jetty has a similar mechanism (another open source servlet container that is usually considered to have the fastest engine when benchmarked; however, the speed comes with a price tag of portability). To understand, what is going on I was digging through the net for some time now.

Java has its java.nio since 1.4 – New I/O with non-blocking streams. It is possible to create non-blocking sockets with this API too. A tutorial I was using to understand the architecture is here: This is the best tutorial I have found, but still it was a bit heavy on my brain :)

To speedup servlet engine by using NIO sockets, Jetty developers came up with continuations: - a way to suspend current HTTP request thread and free the server thread for other clients. In ‘normal’ circumstances, i.e. in ‘old’ web development where user clicks on URL and gets the page rendered by the servlet, there is no need for suspending the thread – why make user wait? Not so with AJAX or HTTP 1.1 KeepAlive – here, client-side browser scripts want to have the connection open at all times to pull the newest data as soon as it is available: chat room engine waits on socket stream to receive new messages; input completion engine (e.g. considers it too costly to open connection every time user types a letter to get suggestions etc. In general there is a shift in web server development strategy to move from request/response paradigm to endless asynchronous messaging queue.

Now, this whole NIO doesn’t really fit into Servlet API standard:

After reading all of these I feel like I am at the square one and have no clear idea as to how to write ‘clean’ web application. All the new stuff creates a huge mess of interwoven technologies, which are quite difficult to sort out by anyone looking at the ‘new style’ servlet code. And JSP 2.1 is not helping by introducing new Unified Expression Language. Are we heading towards faster web app servers and slower, disoriented programmers with constant headaches? For me, I decided to stick to less “cutting edge”, but easier to read and maintain old Servlet API standard, for now.

No comments: