Servlet design question

[John English]

I'm building a set of servlets and am wondering about the messiness
of my design. I have doGet() and doPost() calling a bunch of other
methods depending on the request, and they need a whole pile of
shared state, some of which is session-wide and some of which is
for that request only (e.g. request-related stuff scooped out of
a database). I ended up passing request and response parameters
all over the place, so I rewrote the state using a RequestWrapper
which adds in all the request-specific state info and a reference
to the response object, so now I can just pass the request wrapper
object to all the methods I call. I also created a SessionState class
containing all the session state info and stored a SessionState object
in the session, so that I don't have to spend all my time wrapping and
casting and unwrapping ints with Integers and all that jazz. The request
wrapper also contains a reference to my SessionState object, as well as
useful stuff like the PrintWriter obtained from the response, to avoid
have to say "PrintWriter out = response.getWriter()" everywhere. Basically
the request wrapper has ended up as this huge dustbin full of all sorts of
miscellaneous junk that needs to be accessible at different points in the
processing (e.g. for the logged-in user, the surname and initials taken
from the database).

Even so, I end up with some really huge servlet classes, with maybe
half-a-dozen methods handling the processing of the different request
parameters (e.g. displaying a table, and responding to different selections
in different ways with the confines of the same web page), and these in
turn divvying up the processing between three of four subsidiary methods.

The lack of modularity that I end up with is driving me crazy. So I'm
wondering:
* should I use request dispatching to split the servlet logic into multiple
servlet classes?
* should I create instances of some other sort of object (ad hoc classes
defined to encapsulate specific aspects of the servlet logic) and use
these to subdivide the work?
* or is there a better way?

I find the whole servlet thing a bit strange and non-OO; there's only
one servlet object, it handles multiple requests, so you can't put any
request-specific or session-specific fields in the servlet class itself
because then they'll be used concurrently by every request and session
that's active at a particular moment, so everything needs to live inside
the methods and be passed around as parameters. Can anyone tell me why
this particular approach was adopted, and how I can ever end up with
readable and maintainable code?

-----------------------------------------------------------------
John English | mailto:[email protected]
Senior Lecturer | http://www.it.bton.ac.uk/staff/je
School of Computing & MIS | ** NON-PROFIT CD FOR CS STUDENTS **
University of Brighton | -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

 

[Heiner Kücker]

Hi John,

Sorry, my englisch is not good.

For a better work in JSP Servlet Environment use my CnC framework.

I have written an JSP FlowControl Framework called
'Control and Command'.

My Framework enabled to write a JSP application
easy like an modal DOS application like BASIC or
CLIPPER.

It closed the gap between Browser and Server
presented by the request response cycle.

Online demo is available on
http://www.control-and-command.de

The bottom of the demo pages shows the scripting source code
with an arrow on the current source code line.

This is an JSP Custom Tag for debug.

An single step debug mode is available.

The CnC-Language contents procedures and functions
with parameters (per value or per reference)
and control structures
if/else if/else condition,
while loop
and do loop.

Sorry, Documentation is completely written in german language.

My Framework contents an DomainParser (parser for an
Domain Specific Language), an Compiler and a
Flow Processing Unit.

It works with JSP Custom Tags.

Its completely free.

Im pleased over an positive feedback or
success story by using my framework.

Heiner Kuecker
http://www.heinerkuecker.de
JSP WorkFlow FlowControl Navigation: http://www.control-and-command.de
Expression Parser: http://www.heinerkuecker.de/Expression.html

 

[William Brogden]

I'm building a set of servlets and am wondering about the messiness
of my design. I have doGet() and doPost() calling a bunch of other
methods depending on the request, and they need a whole pile of
shared state, some of which is session-wide and some of which is
for that request only (e.g. request-related stuff scooped out of
a database). I ended up passing request and response parameters
all over the place, so I rewrote the state using a RequestWrapper
which adds in all the request-specific state info and a reference
to the response object, so now I can just pass the request wrapper
object to all the methods I call. I also created a SessionState class
containing all the session state info and stored a SessionState object
in the session, so that I don't have to spend all my time wrapping and
casting and unwrapping ints with Integers and all that jazz. The request
wrapper also contains a reference to my SessionState object, as well as
useful stuff like the PrintWriter obtained from the response, to avoid
have to say "PrintWriter out = response.getWriter()" everywhere.
Basically
the request wrapper has ended up as this huge dustbin full of all sorts
of
miscellaneous junk that needs to be accessible at different points in the
processing (e.g. for the logged-in user, the surname and initials taken
from the database).

Even so, I end up with some really huge servlet classes, with maybe
half-a-dozen methods handling the processing of the different request
parameters (e.g. displaying a table, and responding to different
selections
in different ways with the confines of the same web page), and these in
turn divvying up the processing between three of four subsidiary methods.

Really huge servlet classes are indeed a symptom of a design out of
control.

The lack of modularity that I end up with is driving me crazy. So I'm
wondering:
* should I use request dispatching to split the servlet logic into
multiple
servlet classes?
* should I create instances of some other sort of object (ad hoc
classes
defined to encapsulate specific aspects of the servlet logic) and use
these to subdivide the work?
* or is there a better way?

I find the whole servlet thing a bit strange and non-OO; there's only
one servlet object, it handles multiple requests, so you can't put any
request-specific or session-specific fields in the servlet class itself
because then they'll be used concurrently by every request and session
that's active at a particular moment, so everything needs to live inside
the methods and be passed around as parameters. Can anyone tell me why
this particular approach was adopted, and how I can ever end up with
readable and maintainable code?

My distilled opinion is that you should do as much as possible OUTSIDE
the servlet environment in helper classes that have NO servlet environment
requirement.

You can extract all request parameters to a Map with getParameterMap and
write to an OutputStream or a Writer.
Now you can write methods that take input from any Map and output to any
writer and you can set up a testing environment that does not depend
on a servlet container. Sooooo much faster in the development cycle.

Bill

 

[Andrea Desole]

John, I would like to give you some good references, but I can't find
any. I've been specially looking for an article that was available on
Sun's site a couple of years ago about the 5 tier architecture, but
apparently it has disappeared. Actually, If someone knows how to find
it, I would be glad to know.
Anyway, just to give an idea, servlets and jsps are the presentation or
web tier. As such, their task is to build the view that should be given
to the client(s). They shouldn't usually do any special operation; they
should just take the inforamtion from the client, give it to an
underlying layer (which has the logic), take the result, and make it
available to the client. So,
1) yes, use other objects to divide the work, and call these from your
servlets/jsps
2) don't put huge objects in the session, or don't use wrappers (at
least try not to). Use separate, consistent objects, and use requests
just to take the information you need, and then pass the information to
the competent object. Also, I find it hard to believe that your servlets
have to communicate with so many objects, unless you have a very big
application.
Concerning fields in the servlet class itself, no, you shouldn't do it,
because yes, the class can (and should) be accessed by more threads,
although not necessarily concurrently. I have never done it, but I would
say that the outcome would probably be quite unpredictable. You should
use the session. I don't know what the reason is, but I can guess that
there is actually not much sense in keeping the information in a
servlet, unless you want to use a field just temporarily so that other
methods in the servlet can access it (which is not a good thing anyway:
if you have more complex logic, put it somewhere else). In that case you
should maybe consider the single thread model.
You should also consider using synchronized methods, specially if they
access static variables

 

[John English]

Really huge servlet classes are indeed a symptom of a design out of
control.

Exactly! so I'm trying desperately to regain control before I go any
further...

My distilled opinion is that you should do as much as possible OUTSIDE
the servlet environment in helper classes that have NO servlet environment
requirement.

Uh huh. This is the conclusion I'd come to...

You can extract all request parameters to a Map with getParameterMap and
write to an OutputStream or a Writer.
Now you can write methods that take input from any Map and output to any
writer and you can set up a testing environment that does not depend
on a servlet container. Sooooo much faster in the development cycle.

Hmm, that's a nice idea.

I suspect that what I'll end up doing is defining a bunch of helper
classes to encapsulate the various bits of state info (several ints
and booleans, which are a pain in connection with Maps -- all that
wrapping and unwrapping and casting -- but I'll certainly think about
your approach, which will make debugging a lot easier.

Many thanks,

-----------------------------------------------------------------
John English | mailto:[email protected]
Senior Lecturer | http://www.it.bton.ac.uk/staff/je
School of Computing & MIS | ** NON-PROFIT CD FOR CS STUDENTS **
University of Brighton | -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

 

[John English]

John, I would like to give you some good references, but I can't find
any. I've been specially looking for an article that was available on
Sun's site a couple of years ago about the 5 tier architecture, but
apparently it has disappeared. Actually, If someone knows how to find
it, I would be glad to know.

Me too.

Anyway, just to give an idea, servlets and jsps are the presentation or
web tier. As such, their task is to build the view that should be given
to the client(s). They shouldn't usually do any special operation; they
should just take the inforamtion from the client, give it to an
underlying layer (which has the logic), take the result, and make it
available to the client. So,
1) yes, use other objects to divide the work, and call these from your
servlets/jsps
2) don't put huge objects in the session, or don't use wrappers (at
least try not to). Use separate, consistent objects, and use requests
just to take the information you need, and then pass the information to
the competent object.
OK.

Also, I find it hard to believe that your servlets
have to communicate with so many objects, unless you have a very big
application.

Well, it's fairly big; but there aren't that many objects really. I have
a DataManager for talking to the database; a Utils class containing a
bunch of generally useful static functions; the SessionState object,
which holds about a dozen items (user's name and related details, and
a couple of contextual clues about what the user is currently doing).

Most of the grief is in my RequestWrapper object. This holds a bunch
of information that I need to be "globally" accessible to all the
objects involved in request processing. I'm building a tree from
informtion in the DB, and the nodes of this tree need to be able to
get at (some of) this stuff. Other stuff is used within the servlets
themselves. I'm being lazy really; I could spend the time figuring
out what I would store in class fields and either pass them as a
pile of parameters (yuck -- don't like long parameter lists) or
build special classes to encapsulate them.

I could probably subdivide it, but then different tree nodes would need
different objects; as it is each node has an init(req) method, and I
just chuck it a reference to my wrapper. The wrapper ends up holding
the original request & response, the response writer, and a miscellaneous
collection of ints and booleans and Strings that need to be made available
to various parts of the logic in the nodes of the tree.

So the wrapper has turned into a bit of a dustbin at the moment, and I'm
trying to figure out a better design before it all gets too entrenched...

My current thinking is to build a bunch of processor classes to encapsulate
the bulk of the work, and have the servlet create an appropriate object
once it's figured out what's going on from the request parameters. These
objects can encapsulate the bits of state that I need in each case. This
will let me strip down the amount of global state needed in the tree nodes.

Concerning fields in the servlet class itself, no, you shouldn't do it,
because yes, the class can (and should) be accessed by more threads,
although not necessarily concurrently. I have never done it, but I would
say that the outcome would probably be quite unpredictable. You should
use the session. I don't know what the reason is, but I can guess that
there is actually not much sense in keeping the information in a
servlet, unless you want to use a field just temporarily so that other
methods in the servlet can access it (which is not a good thing anyway:
if you have more complex logic, put it somewhere else). In that case you
should maybe consider the single thread model.
You should also consider using synchronized methods, specially if they
access static variables

Uh huh. I've just avoided storing any non-global data in the servlet
itself (I only have a couple of things that I set up in init() and
some static tables), so that's not an issue.

Thanks for the advice,

-----------------------------------------------------------------
John English | mailto:[email protected]
Senior Lecturer | http://www.it.bton.ac.uk/staff/je
School of Computing & MIS | ** NON-PROFIT CD FOR CS STUDENTS **
University of Brighton | -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

 

[Andrea Desole]

Well, it's fairly big; but there aren't that many objects really. I have
a DataManager for talking to the database; a Utils class containing a
bunch of generally useful static functions; the SessionState object,
which holds about a dozen items (user's name and related details, and
a couple of contextual clues about what the user is currently doing).

well, just as a start, why not a user object? You can put that in the
session

Most of the grief is in my RequestWrapper object. This holds a bunch
of information that I need to be "globally" accessible to all the
objects involved in request processing. I'm building a tree from
informtion in the DB, and the nodes of this tree need to be able to
get at (some of) this stuff. Other stuff is used within the servlets
themselves. I'm being lazy really; I could spend the time figuring
out what I would store in class fields and either pass them as a
pile of parameters (yuck -- don't like long parameter lists) or
build special classes to encapsulate them.

see? You solved the problem by yourself.

I could probably subdivide it, but then different tree nodes would need
different objects; as it is each node has an init(req) method, and I
just chuck it a reference to my wrapper. The wrapper ends up holding
the original request & response, the response writer, and a miscellaneous
collection of ints and booleans and Strings that need to be made available
to various parts of the logic in the nodes of the tree.

Okay, I don't know what this information is, but what I would do is to
separate request and response from the rest of the wrapper, which might
also have a more significant name. In the servlet I would then change
the "wrapper", adding the necessary information taken from the request,
without letting the request or the response be shown to other classes.
Let them stay in the servlet. The nodes can then use the wrapper.

So the wrapper has turned into a bit of a dustbin at the moment, and I'm
trying to figure out a better design before it all gets too entrenched...

As I said, the name itself doesn't really sound promising. You should
probably split it

My current thinking is to build a bunch of processor classes to encapsulate
the bulk of the work, and have the servlet create an appropriate object
once it's figured out what's going on from the request parameters. These
objects can encapsulate the bits of state that I need in each case. This
will let me strip down the amount of global state needed in the tree nodes.

well, if i understand it correctly you would split in this case the
wrapper. If different nodes need different information you should
definitely do it, maybe defining some common beaviour in some base classes.
If the information coming to the servlet can be of different types I
have to say, honestly, that I would think about doing what you just
said, but maybe the best solution is to let the servlet ask a specific
object (like a factory) to create what is needed. I think it probably
also depends on how much work is needed to find out what should be
created, and on how many times you need it. I would expect this
operation to be done in more servlets.
Maybe what you should ask yourself is: "what happens if I have to change
the web application into a real standalone application?". In this case
the html and the servlets would be replaced by dialogs, and all the
session information would probably be replaced by static variables
(major difference). But the way the code works should be unchanged.

Uh huh. I've just avoided storing any non-global data in the servlet
itself (I only have a couple of things that I set up in init() and
some static tables), so that's not an issue.

I would just avoid storing any data in the servlet.

Thanks for the advice,

no problem. Unfortunately I don't know what you have to do, but I think
the main issue here is just to understand that a servlet is just a
different way to implement an interaction between the user and the
application itself. Except a few things, like session variables, the
rest is like a normal application.
You have a set of functionalities to implement. Whether you use an html
page or a dialog the functionalities don't change.