Home

News: Do we really need Servlet Containers always?

  1. Are servlet containers and servlet api really so indispensible that the JavaEE community cannot imagine developing HTTP servers without them? Is this true for all scenarios? In this 5 part series of blog posts, we attempt to go under the hood and explore if there can be better alternatives, especially when you need HTTP as a transport protocol for communication.

    For more information, check out these blog posts-

    Part 1 - The Premise

    Part 2 - Communications and Multithreading Support

    Part 3 - Request Response Lifecycle and Multithreading

    Part 4 - Other Features

    Part 5 - Concluding Part - Building an HTTP server engine using JBoss Netty and using Apache Web Server for load-balancing with sticky sessions

     

     

     

    Threaded Messages (12)

  2. The answer is no[ Go to top ]

    Apache Synapse (http://synapse.apache.org) and the WSO2 ESB (http://wso2.org/projects/esb) both implement a non-blocking HTTP transport that bypasses the Servlet container and handles many more connections.

     

     

  3. Java Play Framework[ Go to top ]

    http://www.playframework.org/

    Check out the Java Play framework for a non servlet based way of doing server side Java.

    So no. We don't need it.

    Servlets make a lot of sense from isolation point of view. Which in turn makes a lot of sense if you have stateful applications with server side user sessions. Which in turn doesn't make a lot of sense for a lot of modern Ajax based web services since those are designed to be state-less.

    Without state, all you need is something that handles incoming connections and gets it over with quick and without fuss. Launch more of those things to scale. Launch them on different machines to scale. Very simple, and more or less exactly what Play Framework does. Think <1s launchtimes. Think F5 in the browser causes the server to recompile any changed code and serve it up. Nice, in other words.

  4. RESTEasy async HTTP[ Go to top ]

    RESTEasy, a JAX-RS implementation, has a simple asynchronous HTTP abstraction that works with Tomcat 6, JBossWeb, and Servlet 3.0.  I've been wanting for a long time to integrate RESTEasy with Netty both on the client and server-side, but haven't had the time.  It should be fairly easy to do this if anybody is interested in being a consumer or implementing it, ping the RESTEasy dev list.

    --

    Bill Burke, JBoss

    Author: O'Reilly's RESTful Java with JAX-RS

  5. Quoting from the last post:

    The Servlet Specification provides a standard API for HTTP server side applications, albeit with certain constraints and loss of freedom.

    Um...of course?

    All standards impose constraints. That's kind of the point.

    For the vast (VAST) majority of web applications, the Servlet API is more than adequate. 3.0 helps normalize current State of the Art with support for the asynchronous idioms.

    You can pretty much rest the explosion of Java at the middle tier solely on the shoulders of the Servlet API. It's a decent model, and portable enough to promote adoption. The large array of servers that can deploy a WAR today is really pretty staggering. Without the Servlet API, there would be little motivation to port applications from one infrastructure to another. But if you want to do an apples-apples comparison of, say, Tomcat vs Jetty, you can readily drop your WAR in either and test away.

    There have been alternative server APIs since day one, most of them pretty unpopular. Not because they were bad, but simply because Servlets were "good enough" barring some special circumstance.

    Modern SDKs have HTTP servers built in to them, mostly to support web services. But you can use them yourself. Modern containers support web services "natively", so you don't need the servlet model for them either. I would argue that the JAX-RS model is perhaps a better model for many applications than the raw Servlet API. Thankfully, you can deploy that on generic Servlet containers.

    So, do you always need the servlet API? Nope.

    But it's s decent first stop and I wouldn't toss it out onday one of a design spec

     

  6. The objective of the article was to take a small step in the direction of pointing out to the community that the servlet containers and specifications are not the end-all and be-all. The idea was germinated as a reaction to the FUD driven responses I used to get when I would put forward this question. Recently I was checking out a rather nice open source framework which would synchronize different types of databases - oracle, postgresql, mysql, etc. For the HTTP transport, the framework was using embedded Jetty servlet container and using synchronous style transport. Numerous engines for deploying SOAP / REST web services use servlet containers internally when they could easily have gone for a more scalable alternative and used asynchronous HTTP from the very start. That is the objective of the article - to question this. And I am glad that there are many supporters.
  7. JAX-RS better[ Go to top ]

    Quoting from the last post:

    The Servlet Specification provides a standard API for HTTP server side applications, albeit with certain constraints and loss of freedom.

    Um...of course?

    All standards impose constraints. That's kind of the point.

    For the vast (VAST) majority of web applications, the Servlet API is more than adequate. 3.0 helps normalize current State of the Art with support for the asynchronous idioms.

    IMO, JAX-RS is actually superior to servlets in 90% of cases.  If you factor in that many of them have an interceptor model as well as support for async, that number goes up.  Combine JAX-RS with Spring MVC or Seam, and that almost takes away the rest of the reasons to use Servlet API.

  8. I think Servlets API is the most succesfull part of JavaEE. It's real standard (in the sense that there are many compliant implementations) with rather clean API.

    One argument for always using servlet containers is that almost every other web API is built on top of Servlets.

    If one needs lower level, implementation specific HTTP-based API, there's always e.g. Jetty's clean org.eclipse.jetty.server.Handler hierarchy - choose whatever level you need.

    I one needs non-HTTP-based APIs the choice is less standard-based (JBoss Netty, Apache Mina, pure NIO, ...).

    My problem with Servlets 3.0 is that I don't think there will emerge many new APIs built on top of it. Read my rant at http://www.restfusion.com/blog/2010/02/jee-sdk-loathe-it-or-ignore-it-you-cant-like-it/comment-page-1/#comment-33. There's no javax.servlet:servlet-api:3.0 Maven artifact! Imagine someone building Servlets 3.0 based, mavenized library - does he/she need to declare dependency on org.glassfish:javax.servlet:3.0 or javax:javaee-api:6.0 (sic!).

    So javax.servlet:servlet-api:2.5 was good base for new, innovative libraries and standards. There's just no javax.servlet:servlet-api:3.0 library from the point of view of modern open source java developer.

     

    regards

    Grzegorz Grzybek

  9. Sorry for my spelling errors - will TSS ever have "EDIT Comment" option?

  10. We do need Containers.....[ Go to top ]

    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. 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.

    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.

    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.
     
    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.

  11. Re: We do need Containers.....[ Go to top ]

    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.

  12. wisdom?[ Go to top ]

    Try telling your client/pm that you are going to write your own container from scratch because you think its better than using an off-the-shelf servlet container.  Why?  Cause you "think" you can do it better.  Make sure you tell them that when you leave, the software you're writing will be unsupportable because the next java guy they get will look at your code and say WTF.

  13. wisdom?[ Go to top ]

    Try telling your client/pm that you are going to write your own container from scratch because you think its better than using an off-the-shelf servlet container.  Why?  Cause you "think" you can do it better.  Make sure you tell them that when you leave, the software you're writing will be unsupportable because the next java guy they get will look at your code and say WTF.

    Oh sure, I would tell the client/pm that, because, for certain scenarios I have already done it- I used JBoss Netty to build a highly scalable GPRS communication server which gave me much better performance and scalability than WebLogic 8.1. You may read my other blog post "How JBoss Netty helped me build a highly scalable HTTP communication Server over GPRS" which is on the Netty community site and my blog home site - http://thesoftwarekraft.blogspot.com/. As for the next java guy, I can only say I have left enough tools and docs and a well written code for him to understand. Not understanding the code is very much possible even while using regular Servlet Container / Application Server frameworks. Quoting from 97 Things Every Software Architect Should Know - Chapter "Your system is Legacy; Design for it" by Dave Anderson - Even if our system is bleeding edge and developed in the latest technology, it will be legacy to the next guy.