Ingo Schuster wrote:
> Hi everybody,
>
> I have a question regarding the architecture with servlets and JSPs:
> I have seen many postings on these lists describing an architecture
> with _one_ servlet that acts as the central handler and processes
> _all_ requests. It chooses which action to be taken, executes that
> action and forwards the request to the respective JSP for
> displaying the results:
>
> --> JSP
> /
> Requests --> Servlet ---> JSP
> \
> --> JSP
>
> I wonder if there is not another option to design the program
> flow for use cases that need several steps with user interaction:
> You could "chain" servlets and JSPs with one separate servlet for
> each step:
>
I would suggest that you avoid the word "chaining" in describing this concept --
servlet chaining has a specific meaning in the context of some servlet engines
that is quite different from this, and could confuse people who assume you are
talking about that kind of chaining.
>
> init.
> request result request2 result
> -------> servlet1 ------> JSP1 --------> servlet2 ------> JSP2 -> ...
>
> Has anybody used this second approach for modelling use cases?
> What are the advantages/disadvantages of either architecture?
> Without having much expirience, I could imagine that the first
> variant might have difficulties to scale up - as this single servlet
> could turn out to be a bottleneck? On the other hand, it could be
> easier to maintain the first version and todo the security handling.
> What are the consequences for reuseability, flexibility,
> internationalisation?
>
In what respect could the first servlet become a "bottleneck"? From a performance
perspective, calling one servlet every time is essentially the same amount of
work (for the server) as calling a different one for each request. From a code
maintenance point of view, the actions that you execute should be in separate
classes anyway (conforming to a common interface, often called Action in the
architecture discussions you have read), and the various actions are indexed by a
hashtable or something in the common servlet, and thus accessed very quickly.
Also, from a process flow design point of view, the second model you describe is
exactly what really happens if you replace the terms "servlet1" and "servlet2"
with "action1" and "action2". The physical implementation of this concept isn't
all that relevant to the process flow design -- in fact, I normally accomplish
this implementation by mapping my control servlet to a single file extension like
".do" (which implies "do something with the input form parameters you just
received"). Thus, my "edit a customer" form submits to "saveCustomer.do", while
my "search for orders" form submits to "selectOrders.do" -- but both actions
(saveCustomer and selectOrders) are processed by the same servlet. Therefore, it
looks to the page authors like they are really calling task-specific servlets, but
I have them mapped to the same servlet. (In fact, I could even change my mind and
map them to separate servlets without changing the JSP pages at all, simply by
adjusting my web.xml file and implementing the appropriate individual servlets.)
The bottom line, IMHO -- design any process flow that requires more than one
interaction with the user the way you described in your second diagram, and make
the decision about one servlet versus many servlets separately based on its own
merits.
>
> All comments are appriciated,
>
> ingo.
>
Craig McClanahan
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
