Servlets Future!!

[Ramnath Krishnan]

I am trying to learn more about Java Servlets, but not sure where they are really useful.
The market is flooded with ASP,JSP,Cold fusion which have already shown thier worth.
Is it true that Servlets are going to replace CGI scripting for web development.
Despite all this, do you guys think, servlets will pick up..
if so why ? and if not why not?.
Sun will release the Java Servlet API 1.1(or have they already). Do they work with all servers or just Java Web Servers.
So in order to develop servlets does one require Java Web Server ( these applications can also be used on other web servers).
The functionality provided by servlet API, does it encompass all the requirements that the web demands.
I know there are lot of questions, but this site has given me very good explanations and I believe there are good number of experienced Java Guru's.
Thanks in advance.

[paul wheaton]

I'll try to answer some of your questions:
I think servlets will replace other forms of CGI.
To run a servlet, you need a servlet server. There are many to pick from that work with almost any web server.

[Frank Carver]

Hmm. Although I'm a great fan of servlets, the jury is still out on whether they will take off properly, or just languish as some people's favourite web-programming system.
On the plus side, servlets are very flexible and have easy access to the full set of Java APIs, including any you may find in jar files. This includes easy socket and database access, powerful email and directory services and so on. If you know Java, writing servlets can be efficient and rewarding. Servlets are generally much faster than CGI scripts, and make it much simpler to maintain data between HTTP requests.
On the minus side, there are still hardly any publicly available (reasonable cost) web hosting companies who support servlets. I would love to get some of my servlets up and running on the real web, but at the moment I'm limited to my home and work intranets. Another problem is the lack of knowledge of servlets by the general web-programming population. How many people do you know who have heard of CGI, ASP, ColdFusion and so on, but have no idea about servlets. Even in the Java community they are not particularly well known. Sun also screwed up by not releasing the servlet API as part of Java 2, even though they claimed it would be included. Well-written server-specific compiled code (Apache modules, NSAPI etc.) can be faster than servlets, although more machine-specific.
The servlet API is currently up to version 2.1, and is available for download from Sun. As Paul notes, there are plenty of servlet engines available (one list is at servlets.com, there's another at Sun) if you want to use servlets on a machine that you control. I mainly use Apache Jserv.
There is some discussion as to whether the servlet API really gives web developers what they want. It is essentially similar in concept to CGI - a simple wrapper round the HTTP protocol), but with persistent context and an attempt at persistent session information. Many authors have added extra layers on top of servlets such as efficient HTML templates (I like Webmacro) and automatic database-to-web translation.
There is some reason to claim that a well-written servlet-based application can be more maintainable than an equivalent in other systems, but introductory books on servlet programming (like most introductory books on any sort of programming) don't address maintainability, and imply that servlets should be monolithic lumps of sequential code. I strongly suggest that any web application is designed, coded and unit tested first, and only then is the servlet layer added and tested. If you start by coding the servlets, it can really skew the design.
I hope this helped. Any more questions?

[Ramnath Krishnan]

Thank you for the replies. Yes, I agree with the fact that servlets are eventually going to replace CGI scripting.And also, there are no books out there which talk about maintainability.
But i did not follow the last part of your reply regarding 'monolithic lumps of sequential code'. Also the part where you say that any web application is designed,coded and tested first, only then is the servlet layer added..
A question: Can an entire application be designed and implemented using Servlets ( just like ASP or Cold Fusion)?
I know that one can use the power of Java API with the servlet programming and all the class libraries therein.
Thanks in advance.

[Frank Carver]

A question: Can an entire application be designed and implemented using Servlets ( just like ASP or Cold Fusion)?
Yes, and the Java solution is more flexible and powerful than either of those, because it gives access to all the Java APIs.
I did not follow the last part of your reply regarding 'monolithic lumps of sequential code'. Also the part where you say that any web application is designed,coded and tested first, only then is the servlet layer added.
OK, I'll try and explain this more clearly, and I'll take a fairly simple example I wrote recently as an example.
What was required was a system to allow our requirement capture team (the people who handle customer requests and questions) to note down anything the customer asks for, and add comments and clarifications later as the requirements capture process proceeds. It was decided to do this as a web application to make it easily accessible from any machine on the LAN.
I very quickly (half an hour or so) produced a very sketchy prototype in perl. It had many problems, but served to reassure everyone that a web interface made sense, and allowed a few notes to be captured immediately.
When it came to producing the "real" one, it was decided to use Java, as the server hardware was fairly slow, and the perl forms could take up to a few seconds to return when a button was clicked.
Now, if I had followed the example of most of the Java servlet tutorials, I would have started by creating a class which extends HttpServlet, overriding doGet and doPost, and filling them with the code to read files from disk, display them to the browser and process the various form buttons. Ending up with essesntially one large and hard to maintain class.
Instead, I chose to design the system as a "proper" Java application, which just happened to have a servlet-driven user interface. The first stage was an ItemStore interface which defined the load/save/delete operations on a stored set of notes, and a FileItemStore to implement these operations in terms of plain text files compatible with the perl prototype.
At this point I gained two benefits: I was able to fully unit test the storage and retrieval of notes without needing a web server and I had a system which was flexible enough to store notes in another way if required (say in a database, or in a marked up format such as XML) without affecting any of the rest of the software.
I then built an ItemStoreManager in a similar way to create and manage groups of notes using the above ItemStore interface. I was able to test all the operations on this class (create a group, add a note, remove a note, edit a note, move a note between groups, remove a group) from an automatic test harness again, with no web server involved.
As the software so far had no dependency on servlets or html, I could have written a very simple text-based ui (choose an operation from a menu, enter text and terminate with a "." on a line of its own etc.) and had a fully usable (although not web-enabled) application, or I could have written a flashier-looking but ultimately similar AWT or Swing ui to do the same job. I still could if I want to.
I decided not to bother, and to press on with the web interface, but it is important to note that only at this stage did I need to bother with anything about servlets, http, html or the internet. And the servlet code was very simple, a GET handler which accepted a text command for each of the ItemStoreManager operations, including "edit" which wrapped the specified note in a web form, and a PUT handler which updated a note from the returned form.
So I have a working web-based note storage application, ready for all the "good ideas" from the users: a search facility, a way to order notes by status (new, under consideration, under development, done etc.), notifying people by email when new notes are added and so on ... But that's all for the future.
It is important to note, however that the chosen design approach allows these or any other modifications to re-use the basic filing system, and even allows other applications with command-line, GUI or web interfaces to access the same data with no "cut and paste" or "re-inventing the wheel".
This was an almost trivial example, but it does show how designing a web application as a regular Java application first can have significant testing and maintenance benefits, which in turn means more robust software delivered sooner, for lower cost.

[Ramnath Krishnan]

Thank you very much Sir....That was the clearest explanation that I ever got!!!