Well what I think we do need Container (we have different containers for different specifications and different purposes), what matters: i) Which container is better for your requirement ii) What is your purpose or requirement.
Your article is focused on few of the implementation approaches followed by Servlet Container vendors and it also tells your approach for implementing the Servlet Container (which has been claimed to be based among available). But after reading the approach suggested by you I feel it is not better then the previous implementation but lacks in comparison to them.
I never said that my approach was the best. It was a different paradigm of doing things which can be considered for some scenarios at least. My article is "Do we really need servlet containers always?" Here the key word is 'always' for HTTP server scenarios. My purpose was to introduce a paradigm, and not commit any heresy :)
Lets start with the first idea of yours to have different thread pools for different tiers/layers.
Well it will just create container which is more memory hungry and it will need lots of CPU usage just for context switching.
Not necessarily. I think the approach I am talking about is to use a SEDA paradigm. You divide your application scenario into different stages. Each stage can be controlled with different thread pool. And when I say thread pool it doesn't mean that there would be lots of threads in the thread pool. Possibly 1 or 2 threads per stage can do the trick, if the processing for one stage is short enough.
Second it will not increase the throughput as database will still take its own time to process query and middle tier will takes its own time which will be same as that of previous scenario. What will happen that your container will keep on piling request in memory and threads of different layers will still take the original time.
Not necessarily again and what is more, like containers, we can put a maximum limit on the number of requests we can receive or hold and timeout expiration. It may increase the burden of application developers and has to be done with care but if one really does have that expertise, he/she may reap rich dividends in the flexibility of designing the application correctly. Also. one may use caching instead of databases. Besides, the slowness of the database will not affect how many requests you may receive and process. Not all requests will be having the same transaction time. One use case/ scenario of your application can be much faster than another one in terms of transaction with database. With the asynchronous decoupled approach, the scenario that is slower will not affect the scenario that is faster. Ultimately, it is how you architect and divide your application.
Now lets think in more detail and you will note that your approach will actually reduce the throughput - how: each tier will not have a thread queue, now once middle tier process the request and send it to data tier things will go great but as soon as data tier return and put request back to queue of middle tier then your request will waste time in queue, now if middle tier needs to send request to data tier again for processing then it will put in data tier queue and you know rest.
Again, please don't go strictly by that diagram I had put in part 3. There are many ways of doing this thing. If your scenario requires 2 transactions with the database, you probably could do it in one thread itself instead of decoupling biz logic and data tier. Moreover, for the return path, even in the diagram I have given, we have separate queues than for forward path. The idea is flexibility of dividing the application in the right stages separated by queues and processing with threads. I think the SEDA site http://www.eecs.harvard.edu/~mdw/proj/seda/ can explain better.
Now think about other aspects like timeout, it will just increase complexity introduce lot more latency and concurrency issues if you think about some global component which will work across layers just to keep track of timeout cleanup.
So my response is that we do need Containers, now what matters is that we have to choose container wisely for our requirement, if somebody has better implementation idea then implement it, how well its been written can be tracked easily by its market share in the domain for which it has been written.
By all means, if less complexity is what matters more, one can go ahead with servlet containers. They definitely have not outlived their usefulness. By the way, I can quote my part 1 again -
"One must be thankful to the containers and the Servlet specification for the standardization and the above fundamental features offered which help developers concentrate on the business problem at hand. Without this support, the huge amount of ground-work to be done would be daunting to the best of us. Some of these features are just indispensable for web applications - no questions asked. I say this also because there are a whole lot of GUI MVC frameworks like Struts, JSF, Spring MVC which have been built around the Servlet specifications. To use these invaluable MVC frameworks for churning out your web-sites, you would of course require a Servlet container.
Before proceeding, let me make it clear that if you need to make a web site for thin browsers with HTML for human users using JavaEE platform, I am of the opinion that Servlet Containers would most likely be required at least to a certain extent. Though of course, now with the emergence of RIA technologies like Flex, JavaFX, etc, there is a whole new paradigm for web-site development."
Apart from this for further reading, you may find these articles useful -
http://www.ibm.com/developerworks/library/wa-aj-web2jee/
http://www.javaworld.com/javaworld/jw-03-2008/jw-03-asynchhttp.html
http://www.javaworld.com/javaworld/jw-02-2009/jw-02-servlet3.html?page=1
I am of the opinion that with Servlet 3.0 asynchronous request processing, we may see big changes in the way web applications are designed in some time.
Lastly, my article looks beyond the typical web application scenarios, as well.
