Discussions

News: Opinion: Servlets must DIE! Slowly!!

  1. Opinion: Servlets must DIE! Slowly!! (20 messages)

    Greg Wilkins, of Jetty fame, has come out claiming that the time of Servlets as we know it is coming to an end. Greg sat on the JSR for Servlets 2.4, and now it is finished, outlines an idea for how to move on from here. He first notes the current problems that we have with Servlets (protocol portability, NIO, HTTP Headers, and more). Greg discusses the idea of "Contentlets", "a new API that is purely about content and is really protocol independent".

    Problems with Servlets:

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

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

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

  5. 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)?

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


  7. Contentlets

    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.

    Read Greg Wilkins' thoughts on why Servlets must DIE! Slowly!!

Threaded Messages (20)

  • They must mutate[ Go to top ]

    I'd agree with the sentiments, though clearly the title was designed to attract attention :-)

    Servlets have developed from being a "nice idea" back in 1998, to a core part of a web system. Their usage has moved on, and now people aren't happy with just HTTP transfer, but want other directions. It is a natural progression. Separating the content from the mechanism is the way to go.

    Whatever the end result is, lets just hope they can finally provide people with a sensible and well thought out authentication system to go with this contentlet - something the servlet spec has been lacking since day 1 (and has finally gained a logout method at version 2.4 !! - why would anyone want to log out ??) - otherwise it will gain the name discontentlet ;-)
  • They must mutate[ Go to top ]


    > Whatever the end result is, lets just hope they can finally provide people with a sensible and well thought out authentication system to go with this contentlet - something the servlet spec has been lacking since day 1 (and has finally gained a logout method at version 2.4 !! - why would anyone want to log out ??) - otherwise it will gain the name discontentlet ;-)

    Logout is not the spec , right?
  • I agree[ Go to top ]

    I agree, but I use servlets to pump jpeg out of a database. I have not really found an easier way to do that with PHP, ASP, etc. Well maybe those things exist now, but when I created this useage this was all I could find, that and I knew java. I do not care what goes on, but the ease to pump, or create new iterations off of this data is key to whatever changes would happen.
  • Re: I agree[ Go to top ]

    You can do that with JSP without a problem
    But it will be servlet too at the end of the deal :)

    Dmitry Namiot
    Coldbeans
  • Portlets?[ Go to top ]

    How would Contentlets differ from JSR168, i.e. Portlets? They seem to be, more or less, the same thing.
  • exactly...[ Go to top ]

    Portlets are the higher level abstraction you are looking for .

    Servlets remain the way they are.
  • Servlets Exist for a Reason[ Go to top ]

    IMHO you do need the servlet spec out there, for the simple reason that it's a natural Java mapping of HTTP. That's not to say that I like the servlet API - I don't.

    The problem is the client, too, not just the server. As the client gets more sophisticated (I should say 'if'), we'll get rid of HTTP and the servlet, either by actually switching to some other protocol or by hiding HTTP under web services.
  • Opinion: Servlets must not DIE![ Go to top ]

    I have developed many J2EE web apps with J2EE including Struts, servlets and JSPs. And my opinion is that - servlets are good for specific tasks, like PDF report creation, Front Controller pattern implementation, specific filter related things and so on.

    But not in entire application model, where application consists of servlets only! I have seen projects where people use servlets only, and almost every time it leads to nonmaintainable code.

    Maris
  • More layers than an onion....[ Go to top ]

    Do we really need more abstraction, isolation, layering and genralization in Java? It's getting ridiculous no?

    One of our favourite jokes at work is to identify the conversations that VB/.Net developers don't have, and never will. This is one of them (lucky them).

    When will we stop isolating, abstracting and generalizing? When will we start just writing what we need to write?

    Don't get me wrong, anyone who knows me knows that I'm a huge fan of good design practices. But there has to come a point where we've painted ourselves into a corner. A point where we've isolated ourselves so much that it's painful and tedious to just do what we really want, simply and effectively. There has to be a limit before it becomes counterproductive.

    Isn't this what killed Swing (slow) and AWT (limited)? Maybe the fact that Servlets have become nearly exclusive to HTTP has saved Java on the server side?

    Just a thought.
  • More layers than an onion....[ Go to top ]

    Posted By: Clinton Begin on December 23, 2003 @ 12:06 AM

    Do we really need more abstraction, isolation, layering and genralization in Java? It's getting ridiculous no?

    One of our favourite jokes at work is to identify the conversations that VB/.Net developers don't have, and never will. This is one of them (lucky them).

    When will we stop isolating, abstracting and generalizing? When will we start just writing what we need to write?

    Don't get me wrong, anyone who knows me knows that I'm a huge fan of good design practices. But there has to come a point where we've painted ourselves into a corner. A point where we've isolated ourselves so much that it's painful and tedious to just do what we really want, simply and effectively. There has to be a limit before it becomes counterproductive.


    Very well said. No one can put it in a better way. We have got to stop at some point of time and not complicate things for no reason. One more object over design approch ( OOA ) i have seen is thinking tooo far into future. If i m developing a small to medium sized application I will look into how big will this grow in say next 2 years or so. But i have seen people design it for next 5 to 10 years and overkill. Why ??? Who knows where the technology is going to be in next 3 years. So design carefully and not too much into future that we waste time building it now and by the time we finish , everything is changed.
    Anyway - All the best and have great holidays.

    Isn't this what killed Swing (slow) and AWT (limited)? Maybe the fact that Servlets have become nearly exclusive to HTTP has saved Java on the server side?

    Just a thought.
  • Design for Change[ Go to top ]

    I agree and do feel that one should design code that is easy to maintain and modify rather then writing code that takes care of maximum scenarios of the future ... and it happens most of the times that the future is unexpected.
    However the dilemma is that the only way to write extensible code is to add abstraction and the point where one should stop depends upon the person, problem at hand, time, money ... etc.
  • RE: More layers than an onion....[ Go to top ]

    Do we really need more abstraction, isolation, layering and genralization in Java? It's getting ridiculous no?
    ...

    +1

    First of all I'd like to say that I have the highest respect for your work - I have dissected your Database layer (looks like I'm one of those mythical code reviewer persons in open source :) ) and it gave me a whole new view on the sql to object mapping problem. I can't think of any other way to do it nowadays.

    Clinton, I am a bit interested in hearing your opinion on a related subject, since you do your work in sort of the same field.

    I find the whole Data Access Objects [1] patterns thinking a bit ... intimidating. Or something like that. I of course understand the whole point of it, separating data store from the fetching logic etc etc. But to what extent is it needed? I mean, THE data storage technique today is databases. The whole concept of "let's switch our database into a xml flat file structure or perhaps whe should use web requests instead" feels a bit too far fetched for me.

    I do see the point of being able to switch data storage. But if I want to implement a technique where I can switch where things are fetched from and stored, I would just create a peer interface (well, which I would do anyway) for each object type in the domain model, and then switch implementations on startup through initalization parameters. Say that we for example have a UserPeer interface which declares the getUser() method. Then it's a simple thing to initialize the system with a parameter stating that now it's time to use the "com.my.DBUserPeer", or if so, the "com.my.LdapPeer". With the possibilite to give the differnet peers symbolic names we could even achieve storing and fetching from several different resources at runtime.

    Compare this to the pattern in the link below and that seems a bit overworked to me. Or it might be me that just don't get it. Perhaps they are saying something like this in the text below.

    [1] http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

    Regards Erik Beijnoff
  • DAO[ Go to top ]

    I fear we're getting off the track, but the Spring Framework provides much nicer support for pluggable DAOs than the BluePrints implementation, or ad hoc startup parameters. No need for switch statements in code; a single exception hierarchy allowing callers to be independent of underlying exceptions such as SQLException, which are mapped by Spring to the Spring hierarchy; out-of-the-box support for JDBC, Hibernate, JDO and (now) IBATIS as DAO implementation choices. This means that you can enjoy the pluggability benefits of the DAO pattern--which are often worthwhile--without incurring much complexity. (It's not so hard to extract a DAO interface and code to it.)

    I think Greg has a point about "contentlets", although I don't think the Servlet API is a significant problem for developing applications--except where authentication is concerned, anyway.

    Regards,
    Rod
  • RE: DAO[ Go to top ]

    Yeah, I might be of the track here.. :)

    Just wanted to clarify that I'm not talking about any switch statements or such. I actually even can't remember ever writing a switch statement...:) Really. I'm using a small convenience service that I use extensively to create any objects from a Class or a classname String.

    So the routine is rather something like this:
    1. Get the parameter specifying the UserPeer class
    2. Load an object from the specified class
    3. Check that it implements the UserPeer interface (isAssignableFrom())
    4. Store in a reference as the active peer class.
    5. Above mentioned procedure could of course also easily be used to store several peers in a Map by a key, making it easy to reference them ("database", "flatfile", "myBackyard" etc.)
  • RE: DAO[ Go to top ]

    Erik,

    I was referring to the switch statements in the BluePrint code.

    I'm using a small convenience service that I use extensively to create any objects from a Class or a classname String.
    My point was that this kind of thing is generic, and while what you describe is a good starting point, there are far more sophisticated implementations available that are as easy to use: true IoC containers such as Spring (and others like PicoContainer). These not only do the simple parameterization via classname but can also set properties, including references to other managed objects. And you don't need to implement any special interfaces in your code for this to work.

    In the case of DAOs, Spring combines this with the exception hierarchy I mentioned.

    Regards,
    Rod
  • KISS[ Go to top ]

    The very reason servlets took off was because of simplicity and quick to market.

    doGet, doPost and you are done. Intended purely to pump out content to a browser and receive form updates, end of story. This is what made it mushroom. This is what enabled Java to become a serious server side contender to ASP (ease of use and makes perfect sense). This is why the teapot book sold out in no time.

    If you need more, create something else. But keep servlets as they are. Change them and you will find the pure web people switching over to .NET.
  • Not another diminuitivlet[ Go to top ]

    I think the -let postfix, as in applets, servlets, aglets, portlets, etc, has been overworked quite a bit for pluggable points in frameworks.

    As a first reaction I'd say that the portlet metaphor "parts of a page are like windows" is not appropriate for alle webapplications. So the portlet API would not be generic enough to replace servlets.

    I wonder wether you will succeed in finding a generic content framework. We are building window-like behaviour on an ancient protocol that does hardly permit this. With ancient protocol I mean the fact that webapplications must use the form-sending protocol of HTTP that, I think, goes back unchanged to the early days of the nineties.
    My point is: I wonder wether it will be possible to find an abstraction where the fundamental constraints of HTTP-forms will not shine through.

    I'm gues XForms will be interesting to follow in this respect as a fundamental rewrite of the constraints of form-sending HTTP. But that's another subject.

    Don't want to trigger XUL zealots. :-)

    groetjes,
    Joost
  • I agree, in terms of development (not architecture), servlets do not provide any great headway beyond the old CGI approach, but are you dismissing JSP to soon?

    As a container for the "Contentlets", or in common practice here containers for our application objects that as you say just return XML blobs they are a very lightweight, easy to use alternative.
  • Ted Neward has some interesting observations as usual:
    http://www.neward.net/ted/weblog/index.jsp?date=20031223#1072248895452

    Gawd. This man has some serious amount of knowledge in his brain...

    --Dilip
  • Opinion: Servlets must DIE! Slowly!![ Go to top ]

    I think the title does not fits well to the article.

    Also it will be too early to Kill Servlets.

    Servlets are very handy from small scale to large scale projects.

    Killing servlets will also effect JSP seriously.

    Basic Servlets can ideally be specialzied/mapped to various other protocols over the network.(HTTP standard is already provided).

    NIO will impact the I/O design heavily. I beleive with the NIO you cannot have a handle to Input and Output stream seperately in non-blocking mode. As I believe It may not be that easy to apply NIO at this moment.

    But sure the specifications can be Enhanced to include the new features.

    Enahancements can be done to include new Channels for different Contents type in other words Content Management.

    I beleive this suggestion should go to the JSR team.(of course not for killing Servlets but for enhancements)

    Specifications do evolve with time. We know that very well.