How to design Servlets properly...

[krilledrille]

This is a newbie question...

What considerations are recommended when it comes to servlets and
consecutive HTTP Request? Does it make sense to have one servlet
handling several requests (e.g. separating them via the parameters
list) or shall a design more go towards one servlet per request?

I have seen mostly the latter (so in the Duke Store example from SUN)
and I find the distinction of request via the parameters not very nice
to program, but I am wondering what the opinion from experienced
programmers are.

thanks a lot for sharing your thoughts

Krilledrille

 

[Christophe Vanfleteren]

This is a newbie question...

What considerations are recommended when it comes to servlets and
consecutive HTTP Request? Does it make sense to have one servlet
handling several requests (e.g. separating them via the parameters
list) or shall a design more go towards one servlet per request?

I have seen mostly the latter (so in the Duke Store example from SUN)
and I find the distinction of request via the parameters not very nice
to program, but I am wondering what the opinion from experienced
programmers are.

thanks a lot for sharing your thoughts

Krilledrille

I actually believe the best way is not working with servlets directly, but
using a framework on top of it (unless your application is small). The only
"problem" with that approach is there are so many to choose from .
There's Struts, Spring, Webwork, Sitemesh, ...

Ofcourse, if you're just learning Servlets/JSP, it's best to use them
direclty, so you know the basics if you later on decide/need to use a
framework.

 

[John C. Bollinger]

This is a newbie question...

What considerations are recommended when it comes to servlets and
consecutive HTTP Request? Does it make sense to have one servlet
handling several requests (e.g. separating them via the parameters
list) or shall a design more go towards one servlet per request?

I have seen mostly the latter (so in the Duke Store example from SUN)
and I find the distinction of request via the parameters not very nice
to program, but I am wondering what the opinion from experienced
programmers are.

I'm having trouble figuring out what you mean. A Servlet's process, and
an HttpServlet's doGet, doPost, etc. methods in general cannot make any
assumptions about requests and responses other than the one of each that
they are working on in any particular thread. A servlet cannot make
assumptions about how many instances of its class are live in the
container, or about to which URLs they are mapped.

Servlets often do determine details of their responses based on request
parameters, but that has nothing to do with distinguishing requests from
each other. URLs are mapped to servlets without consideration of
request parameters. A servlet might forward a request to another
servlet based on the parameters -- is that what you're wondering about?
There can be good reasons to do that, but I have no general opinion
about it.


John Bollinger
(e-mail address removed)

 

[Christophe Vanfleteren]

I'm having trouble figuring out what you mean. A Servlet's process, and
an HttpServlet's doGet, doPost, etc. methods in general cannot make any
assumptions about requests and responses other than the one of each that
they are working on in any particular thread. A servlet cannot make
assumptions about how many instances of its class are live in the
container, or about to which URLs they are mapped.

Servlets often do determine details of their responses based on request
parameters, but that has nothing to do with distinguishing requests from
each other. URLs are mapped to servlets without consideration of
request parameters. A servlet might forward a request to another
servlet based on the parameters -- is that what you're wondering about?

I believe the OP was talking about using
http://some.host/someservlet?action=boo
http://some.host/someservlet?action=baa
vs.
http://some.host/booServlet
http://some.host/baaServlet

 

[krilledrille]

thanks a lot for your thoughts! John, Christophe's comment was hitting
the nail on the head, although I am not sure whether this allows for a
nice design. Always thought that too many if()s are not favored in the
code and this statement definitely causes those! Especially if there
are a number of parameters and even different combinations of them. I
guess in that case the latter solution with 2 servlets becomes the one
to choose?!

Additional question:

What different does it make for the container, is

http://some.host/someservlet?action=boo
http://some.host/someservlet?action=baa

or

http://some.host/booServlet
http://some.host/baaServlet

requiring more resources from the server/container???

Cheers
Krilledrille

 

[Christophe Vanfleteren]

thanks a lot for your thoughts! John, Christophe's comment was hitting
the nail on the head, although I am not sure whether this allows for a
nice design. Always thought that too many if()s are not favored in the
code and this statement definitely causes those! Especially if there
are a number of parameters and even different combinations of them. I
guess in that case the latter solution with 2 servlets becomes the one
to choose?!

I'd go for the second solution, it leeds to more maintainable an flexible
code.

Additional question:

What different does it make for the container, is

http://some.host/someservlet?action=boo
http://some.host/someservlet?action=baa

or

http://some.host/booServlet
http://some.host/baaServlet

requiring more resources from the server/container???

Theoretically the first uses less resources, since you have fewer classes to
load. But it don't think it is worth it.
Also, the second style is easier to make searchengine-friendly. I believe
Google for example will not crawl through all URL's with ?'s in them. You
also get nicer looking URL's for your users.

 

[Juha Laiho]

Theoretically the first uses less resources, since you have fewer classes to
load. But it don't think it is worth it.
Also, the second style is easier to make searchengine-friendly. I believe
Google for example will not crawl through all URL's with ?'s in them. You
also get nicer looking URL's for your users.

Then there's the middle way -- it's completely allowed to map several
URLs to a single servlet, and just have the servlet check which URL
was called. So, looks much like the first case in terms of actual servlet
code, but looks exactly like the second case from user point-of-view.

Whether this is best or worst of both worlds I leave open for discussion..

 

[Hylander]

if's aren't always bad. The code can still be concise and fast. You
also have these options (all of which seem to be "command pattern"
based):

*polymorphism
(ie: a command pattern using plain java classes instead of servlets)
*hashtabled commands
*reflection
*chained ternaries and methods (less brackets)
*subclassed servlets and a base servlet that handles common
functionality.

I *would* avoid using switch statements with "codes".

I'd go for the second solution, it leeds to more maintainable an flexible
code.


Theoretically the first uses less resources, since you have fewer classes to
load. But it don't think it is worth it.

Also, the second style is easier to make searchengine-friendly. I believe
Google for example will not crawl through all URL's with ?'s in them. You
also get nicer looking URL's for your users.

Many apps do not want to be search engine friendly of course and
prefer the extra security. You can hide the ? if you use an http POST
method if you are concerned about messy/more-hackable URLs.

In terms of using more than "one" servlet, it may be better to have
separate servlets for the general ideas of login/authentication,
searching, and navigation. What you don't want is jillions of servlets
for every possible action on a page for all your pages...that is also
unmaintainable. You have to open all those files, compare, etc etc..

I agree that a framework is a good idea. turbine, WW, spring, struts
etc are all decent. Xpetstore (http://xpetstore.sourceforge.net) is
one example app that uses servlets, filters, chaining, several
frameworks all rather nicely. Also has very little code compared to
traditional pet store.

One reason for having less servlet code is so that you have less code
dependent on changing specs. ie: the change from "putValue" to
"setAttribute" caused quite a few problems on various servers and was
rather pervasive in the code. I like to keep javax.servlet.http
importing code to a minimum as the spec has much room for growth.

J