• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

general servlet app arch. question...

 
Matt Horton
Ranch Hand
Posts: 107
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've actually been working on a program for quite some time now, and I have this intuition that when it comes time to finally performance test or something, I'm going to get burned.
Basically, my entire servlet application only extends Servlet once. That servlet instantiates my own version of a session object, which I of course insert into the HttpSession object. That (my) session object manages my primary 'current' manager and all of (what I call) my 'sub' managers which direct a user across whichever task path they take. Specific pages extend Containers that extend a base page, and essentially these classes all digest whatever params I've conjured up from the base servlet into some set of html that returns, of course, via the primary servlet.
This seemed like a great idea a long time ago, just being able to avoid whatever threading issues and instance variables that came up -- just having one servlet and a few hundred classes that churned out various pages in html(Strings).
With this superficial discussion of my app, does anyone see anything inherently wrong with this design? Is this an inane design? Is this a common sense design? Not enough info? Is there a specific reason(or benefit) to extending servlet in each possible page?
Thanks in advance...
[ February 11, 2002: Message edited by: matt horton ]
 
William Brogden
Author and all-around good cowpoke
Rancher
Posts: 13058
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I can't think of any advantage to having multiple servlets instead of a single one that directs things to the approriate class. With respect to performance, probably the String output will be the slowest thing by far and will dominate your performance stats.
Bill
 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This sounds rather like the Front Controller pattern in "Core J2EE Patterns" by Alur, et. al.
Kyle
 
Matt Horton
Ranch Hand
Posts: 107
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Bill, thanks Kyle...
This sounds rather like the Front Controller pattern in "Core J2EE Patterns" by Alur, et. al.

That's a good thing right? I mean, if someone described it in a book, it has to be legit! Yee-hoo!
Incidentally, I merely reused this design from a project that I had worked on a few years ago. I had merely hoped this entire time that the person whose code I initally read had thought the goods and bads all the way through (and that the code would scale; also, unfortunately I used that guy's code as a tool to learn servlets and I never went back to evaluate the design for any integrity other than the hopeful 'oh maybe it helps for reasons x,y,z'). From your link, I assume that he had merely reused a known design. I'll have to pick the text up to digest the costs and benefits.
Thanks so much...
Matt
[ February 11, 2002: Message edited by: matt horton ]
 
James Carman
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What you are describing somewhat resembles the Struts application framework available from the Apache Software Foundation. It uses a single Action servlet that maintains separate action beans to fulfill requests. I think it would be wiser to use it than try re-inventing the wheel. Also, for presentation, you should probably use JSPs.
 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'll second James' vote. Just because it resembles a known pattern doesn't mean it's entirely correct.
The single-controller servlet idea is pretty standard. However, as James points out, it's much more useful to use JSP's for output then to encode HTML in a Java class.
If you are looking to redo your framework, I'd start with replacing the classes that output HTML with JSP's first. Then I'd look at adopting a framework like Apache Struts...
Kyle
 
Matt Horton
Ranch Hand
Posts: 107
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks again guys for the input...
I'll actually hold off on any reworking of the framework right now (maybe for several releases down the road ). My underlying question was merely 'is disaster ahead?'. That is, was there anything fundamentally unsound w/ that structure.
Reading everyone's posts, I feel like I've asked "there's pasta in lasagna, right". I'd like to go ahead and let this thread die, but I feel like I still have to ask one more question: is there a good synopsis somewhere of "servlets vs. jsps"? I initially started writing this app in the fall of 2000 using .jsp, feeling as if I could leverage past COM/.asp experience, but I found it much more intuitive to just write the app using servlets. That is, is the only benefit to using jsps having logic embedded into display? If that's it, imo, that's not really much of a win.
Thanks again in advance...
 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually that's what we advocate you NOT use JSP's for.
JSP's are best used for embedding active content (e.g. Javabeans) in HTML pages. I tend to not put any logic at all in a JSP if I can avoid it. IMHO the <jsp:usebean> and <jsp:getProperty> tags should make up the vast bulk of your JSP programming.
Kyle
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic