Two Laptop Bag*
The moose likes Servlets and the fly likes Design help! Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Servlets
Bookmark "Design help!" Watch "Design help!" New topic
Author

Design help!

Tonny Tssagovic
Ranch Hand

Joined: Dec 30, 2003
Posts: 226
Hello people,
What are the tradeoffs between one big controller Servlet for all the use cases and many smaller Servlets/use case? Maintenance/ Clarity? When one should chose to have a simple Servlet/use case? How many use cases/Servlet is appropriate if I don't want to use the Command pattern
Thanks in advance!
Chris Stehno
Ranch Hand

Joined: Feb 26, 2001
Posts: 180
One problem I ran into with having multiple servlets in a system was memory constraints. My web hosting provider chains in the JVM memory to a paltry 32MB. Servlets are eventually (if you are using lazy initialization) resident in the JVM memory. Under this kind of constraint, a single controller servlet is almost a requirement.
Under "normal" circumstances, I think it is more a matter of preference. A single servlet gives your app one entry point so that security is often easier to control, but unless you are using a command-based architecture, your servlet code can quickly become unmanageable.
Multiple servlets can also give you shared resources by having them all subclass a base servlet. As far as scalability and ease of coding, all things considered, I'd go with a multiple-servlet approach.
Hope this helps a little.


- Chris Stehno, SCPJ
Tonny Tssagovic
Ranch Hand

Joined: Dec 30, 2003
Posts: 226
Originally posted by Chris Stehno:
As far as scalability and ease of coding, all things considered, I'd go with a multiple-servlet approach.
.

Thanks for the reply Chris,
But how come multiple servlets would scale better, in case they would use more memory then a single Jumbo Servlet? And how about performance, did u ever try to calculate the overhead of using a big Servlet with if-else /command pattern, and a single Servlet which directly calls the corresponding Bean (or is it simply ignorable)?
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Try to avoid the big if-else structure if you go with a single servlet. A common approach is to get one or more hidden form fields or a URL parameter and use that as key to a Map to get a handler. The idea is something like...

That can very nearly be your entire servlet. Oh, and something to load up the Map in the first place. Another option is to retrieve a class name from the map and create a new instance for every request. Creating and releasing objects may or may not be more expensive than pools or coding for threading.
I like the single servlet approach because it gives you a handy place to put security and logging and stuff that should apply to all pages. Others may jump in and explain how all those could be in a base class or in filters.


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
Tonny Tssagovic
Ranch Hand

Joined: Dec 30, 2003
Posts: 226
Thanks for the reply Stan,
Isn't what you are documenting the Command handler, with controller pattern? I think it only confuses the guys that have never seen it before, and just makes the application harder to understand even if it decouples between the servlet and the handlers.
Jeroen Wenting
Ranch Hand

Joined: Oct 12, 2000
Posts: 5093
We use multiple servlets, one for each functionality.
I didn't choose the architecture, but I would have done something similar.
Mind that our application will be installed on dedicated machines at customer sites, so shared hosting is no problem
Current count is some 100 servlets and rising, should go up to some 300-350 ultimately.
All the HTTP handling code is abstracted away in a single servlet class from which all others derive, with all the details of parameter handling etc. being handled by the mother through XML configuration files per servlet.
Luckily the person building it didn't try to hide away the request and response objects as his knowledge was a bit limited and I'm now having to code around the framework in many places in order to create decent looking JSPs (I'm using the original parameterhandling for input only, it was originally intended to be used for output as well through largescale use of Java code fragments inside JSPs...).
A single servlet application would be quite impossible for something this large.
It would quickly become impossible to manage (also consider that we're 3 people writing the Java code, that's 3 people who would have to edit that same servlet at the same time).


42
Tonny Tssagovic
Ranch Hand

Joined: Dec 30, 2003
Posts: 226
Thanks for the reply Jeroen,
It makes me confident. Actuallyy there are no more then say 5-7 use cases, but each use case is rather complex, but this is handled at the SLSB and Business logic so no problems..
Although there are not many use cases/sevrlets, these all would probably handle requests by millions/day.
Do you document in your RS which use case maps to wich servlet? Would you have done the design dif. if you had to design the application from day 1?
Thanks again
Craig Jackson
Ranch Hand

Joined: Mar 19, 2002
Posts: 405
[QOUTE] What are the tradeoffs between one big controller Servlet for all the use cases and many smaller Servlets/use case? Maintenance/ Clarity? When one should chose to have a simple Servlet/use case? How many use cases/Servlet is appropriate if I don't want to use the Command pattern[/QOUTE]
My $0.02.
The response below is not necessarily specific to servlets/jsp. Just something to think about when making design decisions.

It is often desirable to use the same controller for all systems events of one use case. This makes it possible to maintain the state(i.e. help identify out-of-sequence events) of the use case in the controller. Some applications require certain sequence of events.
A common problem in controllers are that they are given too much responsibility. Ideally a controller should contain little code and do very little work and should delegate to other objects to complete the work. It should coordinate or control the activity.
There are at least 2 types of controllers. The facade controller and the use-case controller. Facade controllers may represent the overall system or a subsystem or something. It should provide a layer of protection over the application and it should be the main point of entry between UI layer and the other layers. The facade controller is better suited if there are not "too many" system events.
A use-case controller should be considered if the design of the facade controller shows signs of high-coupling or low-cohesion or the facade controller becomes bloated with excessive responsibilities. A use-case controller is good alternative when there are many system events across different processes.
I hope this may help in your design.
Craig.
Jeroen Wenting
Ranch Hand

Joined: Oct 12, 2000
Posts: 5093
The main thing I'd have done different is to not create an entire MVC-like framework from scratch and to further abstract away the business logic from the presentation logic (there's sometimes no way to get around integrating the two currently, though I try).
In part this is due to the fact that quite a bit of metadata defining the presentation of the application is stored together with the actual data (this is an old terminal app based on database specific tech...), in part because the people designing the framework had never used OO tools let alone Java before embarking on an extremely ambitious project.
Tonny Tssagovic
Ranch Hand

Joined: Dec 30, 2003
Posts: 226
Thanks Craig and Jeroen
 
jQuery in Action, 2nd edition
 
subject: Design help!