This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I do lots of servlet chaining. Since I'm working with applets that talk to servlets, I force both to talk only through object streams. So when I need a servlet to talk to another servlet, I just make them use the same object stream. I did encounter one problem though. If I have a servlet talk to another servlet running on the same JRun/Apache copy, Apache locks up. Sad, but true. But most of my stuff is distributed enough that it isn't a problem. Different methods? I suppose most people do it the old fashioned way: A servlet that wants info from a second servlet sends a CGI string and gets back text or html. Barf!
"Servlet Chaining" as implemented in Java Web Server (JWS) is generally considered to be a bad choice for most applications. Servlet Chaining as a general technique of invoking one set of servlet code from another can be more useful, but still has problems. The main issue with servlet chaining is that the information passed in to and out of a servlet are not a good match for any sort of "remote procedure call". Incoming information comes not just from the input stream but from the ServletContext and ServletRequest. Accessing form parameters causes the irreversible side effect of reading and parsing the input stream so the "called" servlet can't access parameters. Output information is similarly complex. Some of the ServletResponse or HttpResponse methods have irreversible side effects like closing the output stream, and there is no easy way for a servlet to know whether it should generate a complete headers-and-html page for a browser, or just some data for a chaining servlet. The general solution for this problem is to separate the "model" (ie the business logic, stored data etc.) from the "view" (the minimal servlet code which reads get/post parameters and environment details and calls methods on the "model". Then, if you need one servlet to re-use some processing associated with another, don't bother invoking the servlet, but call the methods of its underlying model. Here is a very simple example
These three classes show a simple model (a hit counter) with two servlets which access it. One servlet is designed for inclusion in another page, and just returns the number of hits after incrementing it. The other servlet might be thought of as an "admin interface" with a GET interface to show the unmodified count, and a POST interface to set a new count. Exercises such as storing a collection of named counters, or adding other user interfaces are left to the reader. Alternate designs using servlet chaining are possible, but rapidly become clumsy and error prone. Designing this system as a single servlet is also possible, but can lose the clarity and simplicity of the servlet code in a lump of 'if (action.equals("increment"))' selections. For a more detailed description of this approach, see the thread entitled "Servlets Future!!" in this forum, or follow the url: <a href="http://www.javaranch.com/ubb/Forum7/HTML/000012.html">http://www.javaranch.com/ubb/Forum7/HTML/000012.html</a>