- People believe that Application Servers and their Servlet containers provide some great sophisticated and almost magical services that they can never do without for any serious production based application.
- A very large community has generally built web-site based applications or has some web-site component for exposing their business to human consumers. If they are using and investing in Application Servers and/or Containers anyway, why not just use the Servlet container.
These are in fact, quite often valid reasons. But one must pause to think - is there no flip-side at all? Have we not lost out on anything at all due to this approach? And do the above reasons hold true for all HTTP server applications?
Not long ago, there was a time when people thought that EJB = J2EE and that every J2EE application must have an EJB container. In fact, I was one of them. Then one fine day in 2006 I came across a book - "Expert One-on-One J2EE development without EJB" (2004 Edition) by Rod Johnson and Juergen Hoeller, the creators of Spring Framework. That book completely changed the way I thought of JavaEE applications and I consider it a turning point in my professional career. There was an entire chapter - "EJB, Five Years On", which effectively dispelled all the myths I had ever entertained about J2EE and EJB. One by one, the chapter showed me that whatever services Stateless Session Beans (often the only EJBs used) provided- whether Declarative Transaction Management, Remoting, Clustering, Thread Management, Instance Pooling, Security and so on- there were alternatives and in fact, EJB was not the best answer to these concerns for all scenarios. 6 years after the publication of this path-breaking (in my eyes) book, the impact of Spring is for all to see. It revolutionized JavaEE development, the JavaEE6 specification is greatly inspired by it, a large part of the developer community has not looked at EJB since the arrival of Spring and it is understood that Spring shops are unlikely to move away from their favorite framework so that the community may now be split into Spring shops and JavaEE shops. (Read Adam Bien's weblog JAVA EE 6 IS NICE, BUT IT IS TOO LATE...).
I think the reason Spring framework and the book I mentioned above were so effective was that the creators of Spring tried to understand and discuss the philosophy behind the EJB2.1 and J2EE specification and then see whether there were any alternatives or better approaches. Not only that, there was a respect for the capability of the developer and architect community urging that middleware developers are not semi-competent to be unable to make decisions for their application requirements and they should not be deprived of control or ability to use alternatives.
In the same lines I would like to discuss about the need to use Servlet Containers for all HTTP server side processing. Let us keep our minds open and ask some real questions as to when and why we need Servlet containers and when can we do without them. An important pre-requisite is to have confidence and respect for our own competence as developers and architects to control the programming language and platform we have painstakingly learnt and developed our expertise in over several years.
An excellent book “Head First Servlets and JSP” explains the value of containers for server-side HTTP applications. It first challenges a Java developer to think of her responsibilities “if you had Java but no Servlets or Containers”. Then it expounds “What does the Container give you?” and lists the following –
- Communications support (i.e. listening on server socket and HTTP protocol encoding and decoding as well as HTTPs support)
- Lifecycle management (of the Servlet and the entire web application)
- Multithreading support
- Declarative security (by adhering to JAAS Security Standards)
- JSP support
One may add the following as well to the above list -
- standardized deployment contract in the form of war files and declarative deployment descriptor in the form of web.xml.
- A standard API to represent HTTP requests and responses to extract data from HTTP requests (headers, URL parameters, request/response body.
- Session Management
- Pluggability with major web servers (like Apache HTTPD) for reverse proxy, load-balancing with session-stickiness and failover.
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.
Then what exactly are we attempting to discuss about? First, as architects or designers, one must find the key quality attributes required for the business application and decide which of the Servlet Container facilities we absolutely need, which ones we can do without, which attributes are we prepared to trade-off for more important ones and whether there are alternatives. As a young JavaEE developer/designer/architect, I was also among those who thought that Servlet Containers are THE solution for developing Web/HTTP Server-side Applications. By not considering the special quality attributes and trying to twist Servlet Containers and other JavaEE platform offerings, I had blundered and what was worse, for a long time I didn’t even know that I could have done better by adopting a different paradigm. I have since become wiser.
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.
However, consider the following interesting scenarios where there is scope for exploring alternatives to Servlet Containers-
- Say you need HTTP as a transport protocol. You have your own application level protocol in the form of some XML format or some binary protocol (custom or Google protocol buffers and so on). This application level protocol or format is just using HTTP as a means of transport instead of raw TCP/IP sockets. Typically this is done because HTTP is seen as firewall friendly.
- Or else you are using the RESTful facilities provided by HTTP - GET, POST, PUT and DELETE to provide a simple web based service. Once again HTTP is providing a convenient protocol especially in the form of name-value URL parameters to specify your query string and formulate your request. But essentially it is being used as a protocol and a format, not for displaying an HTML GUI page.
- Even for GUI applications, there has been a re-emergence of thick RIA clients enabled by Flex and JavaFX and Silverlight which take care of the GUI rendering entirely at the client side and seek business data from HTTP based server-side applications. Once again, we have the same premise - they don't need the server side to do any rendering for them, just to provide HTTP-based service and provide the data in some mutually agreed application level format embedded in HTTP request/response format.
- One can also include the AJAX/Comet requests which are frequently sent by clients to servers and have to be responded to in minimal time with maximum throughput and also scalability for handling numerous such requests. Often the client side script is capable enough of rendering or just un-hiding certain portions of the page after applying the correct values.
- Sometimes the medium between the client and server can be fragile like wireless (GPRS) and the transport may behave in strange ways - like sending chunks of data in packets and with very low bandwidth.
In my next posts, I will attempt to go under the hood and read between the lines to evaluate the Servlet Container features, for such scenarios.