"Mikhail A.Golovanov" wrote:
> 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
What write a russian is undersend very hard. :-))
Maxim
___________________________________________________________________________
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
