In regards to discussions like this I wonder (for three months for now)
WHY the servlet framework designers invented the HttpSession class
and completely forgot to "invent" the HttpChain (or some) class for tracking
user actions launching and protracting the application-defined form
(page) chains comprising business transactions? The lack of this
class category constantly produces misunderstanding when it comes
to the Back button in a browser etc.
So did guys from Micro$oft - their Webclass extension to VBasic
(another framework strongly resembling servlets in principle) also
lacks this very important mechanism though having the Session tracker.
> -----Original Message-----
> From: A mailing list for discussion about Sun Microsystem's Java
> Servlet API Technology. [mailto:[EMAIL PROTECTED]]On
> Behalf Of SERVE 'EM - Dan Coggeshall
> Sent: Tuesday, March 07, 2000 2:04 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Modelling use cases with JSPs/Servlets
>
>
> 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
___________________________________________________________________________
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
