I have done the second model. There are a lot of advantages and disadvantages.
Dis: A lot of servlets can get confusing when trying to figure out where a
specific page is supposed
to be submited to.
Adv: You are sort of right with the bottleneck idea. Usaully a JWS allows
multiple instances of the same servlet, so by having more than one instance you
can handle several requests for the same servlet. However, you also need to
look at the hardware. Regardless of how many instances you have, if you only
have one processor, then you can only handle a few requests. If you have
multiple instances up, be careful with the instances conflicting with
eachother. By seperating the servlets you will not have this problem.
Adv: My opinion is that servlets become somewhat procedural, because of HTML's
limitiations, and stateless protocol. While there are ways around this such as
sessions, I have not been able to really emmulate extensive OOP when it comes
to servlets. Now the objects that the servlets use can very object oriented.
But the problem lies in making the HTML and servlets interact on an object
oriented level is really difficult. Therefore, by having serveral servlets, it
can break up the proceduralness.
After working with servlets for two years, I really have to tell you that it
comes down to a judgment call and personal preference. There are just too many
tradeoffs when dealing with servlets. If you want me to elaborate more, just
write back. Hope this helps.
DanC
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:
>
> 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?
>
> All comments are appriciated,
>
> ingo.
>
> ___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
