On Wed, 1 Mar 2000 08:24:33 -0800, Craig R. McClanahan <[EMAIL PROTECTED]>
wrote:
>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.
>
ok, didn't know that.
>>
>> 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.
My thought was: Generally, it is better for performance to have different tasks
done by different pieces of code: the server can easier "load balance" them on
different
machines and at some points, the need for concurrency control (locks, synchonizations)
might no longer be needed. However, as I'm thinking more about it, here this is not
the case as everything the controller servlet does is read-only (and thus no
concurrency
control is needed).
What's about security handling? When done "manually" in the servlet, it is very
convenient
to have all request coming in at a one single servlet - no need to do security checks
at different places in the application. But if I use container managed security,
wouldn't it be better to have one servlet per security area and then assign the
respective security roles to the servlets? Is there an easy way to handle security
when using only one servlet?
ingo.
P.S: I propably should have said that I'm a student working on my diploma thesis
(Application architectures based on the J2EE). That's why I don't have much practical
experience yet and some of my questions might sound silly...
I'm very glad about this list. Lots of good ideas and experiences are posted here --
a gold mine for my work. Thank to all of you!
>
>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
===========================================================================
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
