• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Single Servlet vs. Multiple Servlet approach

 
Ranch Hand
Posts: 42
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Mark Spritzler
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 42
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'll simply vote one for the "Front Controller" pattern with a single servlet.
 
Ranch Hand
Posts: 251
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 251
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Oh, and for J2EE design, I can't recommend this book enough.
 
maneesh subherwal
Ranch Hand
Posts: 42
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 2676
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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).
reply
    Bookmark Topic Watch Topic
  • New Topic