aspose file tools*
The moose likes Servlets and the fly likes Servlet chaining Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » Servlets
Bookmark "Servlet chaining" Watch "Servlet chaining" New topic
Author

Servlet chaining

Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
Can I know how servlet chainging can be done
& the different methods available.
paul wheaton
Trailboss

Joined: Dec 14, 1998
Posts: 20726
    ∞

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!

permaculture Wood Burning Stoves 2.0 - 4-DVD set
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
"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>


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Servlet chaining