File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Servlets and the fly likes Single Servlet vs. Multiple Servlet approach Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Java » Servlets
Bookmark "Single Servlet vs. Multiple Servlet approach" Watch "Single Servlet vs. Multiple Servlet approach" New topic
Author

Single Servlet vs. Multiple Servlet approach

maneesh subherwal
Ranch Hand

Joined: Aug 26, 2002
Posts: 42
All,
I have a question that folks here at JavaRanch may be familiar with.

Using Tomcat's Specifications and the MVC pattern, is it better to use a single servlet controller or several servlets, one for each action, for a large application, in terms of container overhead and/or maintenance?
e.g.
SingleControllerServlet?UpdateDB
SingleControllerServlet?RetrieveFromDB
OR
UpdateDBServlet
RetrieveFromDBServlet
In case 1, I send the function as part of the queryString while in case 2, each servlet performs its own function and has less logic processing to do.
Thank you,
cyberCipher


Sun Certified Java Programmer 2 (1.4)<br />Sun Certified Web Component Developer
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

First I had posted this in your other thread, but in case you haven't read it there yet.
"cyberCipher"-
Welcome to the JavaRanch! Please adjust your displayed name to meet the
JavaRanch Naming Policy.
You can change it
here.
Thanks! and welcome to the JavaRanch!
Mark


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

Alright here are my two cents worth.
I believe that a Servlet should be just that. The interface between the client and the server through a browser. It's responsibilities should remain to handle requests and responses on the web. Setting Headers, Content, etc.
Anything that is business logic related should be delegated to "Helper" classes, rather than in the Servlet itself.
Now, I also think your question is better handled by looking at the Web server, App server, and the pool of servlets to handle client requests.
By configuring this correctly you will enhance performance. By making multiple Servlets I think the complexity and ability to maintain increases.
Now, I am not an expert, and could be completely off in my beliefs, so taking my ideas with a grain of salt, and if someone else that is an expert cna better answer, than please do.
Mark
maneesh subherwal
Ranch Hand

Joined: Aug 26, 2002
Posts: 42
Thank you, Mark, for your suggestions and responses.
I agree with you that a servlet should be no more than a controller or an interface. Logic decisions must either be driven by the helper classes, javabeans, or helper files, maybe xml files.
However, this may cause a significant memory overhead, instantiating the helper classes each time or I/O to search for the xml files. By using several servlets the complexity does increase and so does the maintenance since a problem has to be fixed in multiple places. However, who eventually wins the trade off between memory overhead and maintenance overhead. I believe that the maintenance overhead is more of an issue.
Thank you,
Maneesh
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

I think maintenance costs are much higher and more expensive all around than a memory issue. After all Ram and hardware are much cheaper.
Mark
p.s. Thanks for changing your name. However, you need to include your last name as well. Thanks
[ September 04, 2003: Message edited by: Mark Spritzler ]
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I'll simply vote one for the "Front Controller" pattern with a single servlet.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Phil Chuang
Ranch Hand

Joined: Feb 15, 2003
Posts: 251
It's actually not that difficult to use just one controller.
Here's the solution that I've come up with, it may not be the best, but it works pretty well:
1 controller servlet recipe
-use something like /app/abcde instead of /servlet/controller?flow=abcde - you can pick apart the URL once you get to the controller. I do this instead of getting it from the request, plus it looks cleaner.
-as far as getting input from the request, I have a filter set up that takes all the string data from the request and puts it in a map of name vs parameter, and passes it along to the servlet which passes it to the flow. That way you are not tied down to the HttpServletRequest.
-set up a map wrapper that resolves flows to classnames, one that is loaded at startup and can be configured externally. Construct and cache the flows and dish them out on demand.
The benefits are
1) external configuration for flows (may or may not be important)
2) simplification through reflection (cleans up controller code)
3) single entry/exit point for the View
4) You're pretty much forced to write decoupled code - which should help overall design and development.
The disadvantages:
1) larger up-front cost, but done correctly, it's only a one-time cost and will reap larger benefits in the long run
2) if you like accessing the request/response/servlet objects directly and like to sprinkle business rules in with control and input logic, then this approach is not for you
Phil Chuang
Ranch Hand

Joined: Feb 15, 2003
Posts: 251
Oh, and for J2EE design, I can't recommend this book enough.
maneesh subherwal
Ranch Hand

Joined: Aug 26, 2002
Posts: 42
Thank you for your response, Phil.
I thought of another 1 controller design using xml mappings and reflection API that is similar to the one you mentioned here. I agree that
the up-front costs are larger but the maintenance benefits alone are enough to 'run with it.' I do not have a problem with building this single controller framework but I was unsure about putting the work into it if the results were not what I expected. However, it seems that the 1 controller approach is a favorable one for several reasons.
Thank you,
Maneesh
Matthew Phillips
Ranch Hand

Joined: Mar 09, 2001
Posts: 2676
Originally posted by maneesh subherwal:
Thank you for your response, Phil.
I thought of another 1 controller design using xml mappings and reflection API that is similar to the one you mentioned here. I agree that
the up-front costs are larger but the maintenance benefits alone are enough to 'run with it.' I do not have a problem with building this single controller framework but I was unsure about putting the work into it if the results were not what I expected. However, it seems that the 1 controller approach is a favorable one for several reasons.
Thank you,
Maneesh

Take a look at Struts. It uses and xml config file to map urls to actions (the helper classes).


Matthew Phillips
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Single Servlet vs. Multiple Servlet approach
 
Similar Threads
Single Servlet Controller vs. Multiple Servlet Controllers
Servlet Thread Model
Prototype delay not working in IE 7 on windows XP
Servlet Thread Model
putting servlets to sleep