wood burning stoves*
The moose likes Servlets and the fly likes Jayson Falkner and the proper use of controller servlets... Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Servlets
Bookmark "Jayson Falkner and the proper use of controller servlets..." Watch "Jayson Falkner and the proper use of controller servlets..." New topic
Author

Jayson Falkner and the proper use of controller servlets...

Michael Sullivan
Ranch Hand

Joined: Dec 26, 2003
Posts: 235
I've seen projects with many less specialized controller servlets, and projects with one specialized controller. I've also seen a 'dumb' servlet that doesn't do much more than request.forwards.
Can you explain a bit on the recommended usage of controller servlets (in MVC patterns)? I'm envisioning multiple controller servlets, but I'm curious as to your recommendation.
Thanks!
Kevin Jones
Author
Ranch Hand

Joined: Oct 29, 2003
Posts: 39
You would probably want to use a single servlet as a controller. Why? Well if you have a single servlet you have a single point of maintenance for the controller code. Imagine a scenario where your manager comes to you and says we need to add logging, or some other service to the application. If you had a single controller adding this extra service becomes straight forward. If you have multiple controllers adding the multiple services to the mulitple controllers becomes much more of a maintainance issue.
Similarly if you discover a bug in the dispatching code of you controllers you have to fix it in multiple places.
If all the code needs access to a specific resource then this code may need to be added to each controller.
Security is another issue. If you have a single controller you have to secure that. As you add multiple controllers trying to track the security requirements for each one may be an issue.
Generally using a single controller makes life much easier,


Kevin Jones<br />Author: <a href="http://www.amazon.com/exec/obidos/tg/detail/-/0321136497/jranch-20" target="_blank" rel="nofollow">Servlets and JSP: The J2EE Web Tier</a>
Michael Sullivan
Ranch Hand

Joined: Dec 26, 2003
Posts: 235
Kevin,
Thanks for the response. So, you end up with one much more generic controller servlet in your example. If all controllers are responsible for is forward traffic/ security, then it makes sense.
If controllers need to be specialized... this wouldn't make sense (one big controller to handle every situation). I've read that you should only use more than one servlet as controller if you want a clear separation of functionalities.
Very interesting. Does your title cover design patterns outside the MVC?
Thanks,
Michael
[ January 29, 2004: Message edited by: Michael Sullivan ]
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Imagine a scenario where your manager comes to you and says we need to add logging, or some other service to the application. If you had a single controller adding this extra service becomes straight forward. If you have multiple controllers adding the multiple services to the mulitple controllers becomes much more of a maintainance issue.
Can't you use a Filter for this also?


GenRocket - Experts at Building Test Data
Ko Ko Naing
Ranch Hand

Joined: Jun 08, 2002
Posts: 3178
Hi Michael,
U might want to have a look at the thread, in which Frank(the sheriff), Pradeep Bhat(the great) and I discusses about the Front Controller... Really interesting and Mr.Frank got very good examples in explaning about it...
http://www.coderanch.com/t/357783/Servlets/java/Asking-authors-patterns-Web-Tier


Co-author of SCMAD Exam Guide, Author of JMADPlus
SCJP1.2, CCNA, SCWCD1.4, SCBCD1.3, SCMAD1.0, SCJA1.0, SCJP6.0
Kevin Jones
Author
Ranch Hand

Joined: Oct 29, 2003
Posts: 39
Can't you use a Filter for this also?

Yes you could, and that's where distictions start to get hazy. I would certainly use filters for layering services on top of an application, but there could still be code that has to apply to specific endpoints and so will be added to the controller.

In fact I did a presentation at JavaOne 2002 that argued for using Filters as controllers rather than using a servlet
Ben Dover
Ranch Hand

Joined: Jan 30, 2004
Posts: 91
Hi Kevin,
can you elaborate on that a little. Common acceptance is that the controller is a servlet and filters are used as a decorator (security checks and data validation etc). Why would you suggest using a filter as a controller? If the system were more elaborate involving Dispatchers/Actions (Service to Worker pattern), how do you see them fitting in with a Filter controller? Would the Dispatchers be Servlets in this scenario?
Thanks.
Kevin Jones
Author
Ranch Hand

Joined: Oct 29, 2003
Posts: 39
A controller reads a request, delegates to the model layer to get the business rules executed and then forwards to a page to display the result. To 'call' the page the servlet/controller uses a RequestDispatcher.
One way to think of filters (and this is a very loose analogy) is as a Servlet with built-in request dispatching. So if I have a Filter as a controller the filter would read a request, delegate to the model layer to get the business rules executes then forward to the page, but the forwarding could be done 'naturally' using chain.doFilter or the filter could use a RequestDispatcher as necessary.
The advantage of using filters as I see it are several - it's a natural fit, controllers need to intercept every request to the server, filters are built to do that. You don't need to 'hide' resources. When I use a single servlet as a controll I put my JSPs in WEB-INF, with filters I wouldn't need to as all requests will go through the filter naturally. Having to hide these resources falls into the category of 'ugly-hack', and it's one of those things that becomes part of the lore of web app development.
The disadvantage of using a filter is that everything has to go through the filter (depending on configuration), even requests for images/stylesheets, so unless it is coded thoughtfully the filter could be a bottleneck.
I believe this is something that requires more testing. I spoke to one of the Struts developers at JavaOne and I know he was thinking of investigating this. It may turn out not to be practical, but I can't think of any compelling reason why not of the top of my head.
A couple of other thoughts:
You could think of a controller as being a service, the controller service!
Also, you mention patterns a lot. One issue I have with the use of patterns (and I'm goint to get flattened by folks whole tell me this is a mis-use), is that they can stop you from thinking 'outside the box'. Because something has always been done one way doesn't make it the only way, or the correct way. Just food for thought
Kevin Jones
Author
Ranch Hand

Joined: Oct 29, 2003
Posts: 39
Very interesting. Does your title cover design patterns outside the MVC?

We cover the original model 1 and model 1 1/2 uses but only briefly. I wrote an article on a slightly different approach Here
Michael Sullivan
Ranch Hand

Joined: Dec 26, 2003
Posts: 235
Thanks Ko Ko, interesting read. Also interesting to view the controller as a filter... I'll have to play with that a bit.
Kevin, I think that the power of patterns is to provide reliable, reusable answers to common questions-no? Recognizing patters doesn't limit you to them.
Ko Ko Naing
Ranch Hand

Joined: Jun 08, 2002
Posts: 3178
Originally posted by Kevin Jones:
The disadvantage of using a filter is that everything has to go through the filter (depending on configuration), even requests for images/stylesheets, so unless it is coded thoughtfully the filter could be a bottleneck.

Hi Mr.Kevin,
In this thread, Mr.Frank(the sheriff) said as the following, I think that such kind of bottleneck is very less likely to happen... Could u please correct me, if I am wrong? Thanks...
Originally posted by Frank:

It's easy to think that there might be a bottleneck, but in reality, there almost always isn't. It's important to remember that each request that comes in get's its own thread, and all these threads can be happily running "through" the servlet code at the same time.
Maybe it will help to think of it like lots of people watching a movie at the same time :- the movie doesn't slow down or stop because there are more people in the movie theater

[ January 30, 2004: Message edited by: Ko Ko Naing ]
Ben Dover
Ranch Hand

Joined: Jan 30, 2004
Posts: 91
Hi Kevin, thanks for the insight. You have left me with something to think about. I understand what you mean by patterns possibly denying some sort of creativity, but I personally think it is very healthy to understand them and how common practice over the years has led to them. After all they are simple (not simplistic) solutions to complex issues that have stood the test of time, and combine semantically well with Java. I also think they are flexible enough for a wily developer to play around with.
When faced with a deadline and a deliverable, re-usable patterns can imbue stability in your design. Sometimes being to "out of the box" may be a risk many are not prepared to take or can't afford.
However your "pattern" to use a filter as a controller is tantalising. What will you call it???
Ben Dover
Ranch Hand

Joined: Jan 30, 2004
Posts: 91
Further to the patterns issue...
Dialog between recently promoted Team Leader and Manager.
MANAGER: OK, great design. But is it scalable?
TL: Well it uses JSP/Servlets and is co-located with the business tier.
MANAGER: So it is scalable?
TL: Well, I can't say exactly, I will need to take a closer look at the design and do some testing.
MANAGER: Ok, let me know. But it has got to be scalable george! SCALABLE!!!
MANAGER: .oO(Got to convince the board it's scalable. They love those trendy words).
TL: Leave it with me boss.
TL: .oO(Scalable. Shit, www.webopedia.com. What exactly IS scalable)
TL: .oO(Ok. Scalability: The system needs to be just as reliable under increased load as it is now).
TL: .oO(Ok, now testing reveals the following bottlenecks... but how can I get around them. Hmmmmmm. Should I reinvent the wheel here, or has this kinda thing already been done???)
MANAGER: How's the scalabilty thing going george.
TL: .oO(I need a beer)
TL: (After consulting with JavaRanch gurus) I got it! The perfect pattern. It is widely used, adds security, and has proven to be reliable for scalable web applications. I am re-factoring as we speak.
MANAGER: Good work. And when it's scalable, make sure it's extensible. Extensible George! t's got to be eeeextensibllllle!!!
TL: Yeah, ok boss.
TL: .oo(friggin buzzwords...)
Kevin Jones
Author
Ranch Hand

Joined: Oct 29, 2003
Posts: 39
It's easy to think that there might be a bottleneck, but in reality, there almost always isn't. It's important to remember that each request that comes in get's its own thread, and all these threads can be happily running "through" the servlet code at the same time.
Maybe it will help to think of it like lots of people watching a movie at the same time :- the movie doesn't slow down or stop because there are more people in the movie theater

Yes, I understand this which is why I said "unless it is coded thoughtfully it could be a bottleneck" I chose my words very carefully. WHat I meant by this was that, in the filter there is no need to do any processing if the request was for a 'non-controller' endpoint. i.e. the first thing the controller has to do is to check to see if the request falls under its control and if it doesn't pass it on as quickly as possible and not start synchronizing or using resources that need synchronization when it doesn't need to.
Ko Ko Naing
Ranch Hand

Joined: Jun 08, 2002
Posts: 3178
Originally posted by Kevin Jones:

Yes, I understand this which is why I said "unless it is coded thoughtfully it could be a bottleneck" I chose my words very carefully. WHat I meant by this was that, in the filter there is no need to do any processing if the request was for a 'non-controller' endpoint. i.e. the first thing the controller has to do is to check to see if the request falls under its control and if it doesn't pass it on as quickly as possible and not start synchronizing or using resources that need synchronization when it doesn't need to.

Thank you very much, Mr.Kevin, for your explanation... It's very good that we have both of the authors to share us their knowledge... Thanks a lot...
Ken Robinson
Ranch Hand

Joined: Dec 23, 2003
Posts: 101
In every other aspect of OOP, if we have common code that we want many object to use, we create a superclass and many subclasses. Why is it that for web development the popular technique is to create a controller?
Why not create a servlet that, in the service method, does all the common work before calling super.service? All subclasses would be servlets that extend this super servlet, allowing the URL mapping, security and other features already built in to continue to be used.
I've always wondered why the existing javax.servlet objects where not just extended? Any opinions?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Jayson Falkner and the proper use of controller servlets...
 
Similar Threads
why controller is servlet
Browser Back Button
Servlet Controller Vs SFSB Controller (given swing and jsp)
Java websites
SCWCD or SCBCD?