> > You may also want to consider storing the some of the
> > client-specific state
> > in the applet itself - just the way we do with client-server
> > applications.
>
> Isn't all this (J2EE) just to get away from that ? :^) Less
resposibilities
> the client has the better.
This is not completely true. In fact, the servlet is a client for the bean,
and the HttpSession is there for maintaining the state!):
> > In this case, the servlet can just delegate the request from
> > the applet to
> > the session bean.
>
> How does the servlet just delegate the request from the applet to session
> bean ? Does this allow the conversation between the bean-servlet-applet
kept
> alive ? Thanks
The delegation can not be avoided because you've to convert the HTTP request
into a bean request. Similaryly you'll have to compose the
HttpServletResponse! Of course, the connection will be alive from the moment
the applet sends the GET/POST request, and receives the HTTP response! I
don't mean that the conversation happens across one connection! I hope this
clarifies.
> > - FYI, the HttpSession is highly dependable - the cookie vs
> > However, the servlet may still maintain a HTTP session for the applet
> > client. In fact, I would consider doing so, as it enhances
> > reusability of
> > the servlet. That's of course, a design decision.
>
> I am trying to explore ways to see if I can make one session bean be
invoked
> from the applet for an entire session (all ideas appreciated). If not for
> that, then the next best thing appears to be the servlet to use the
> HttpSession. As I am not sure where the servlet will run (web server on a
> different machine or in an application server), I would prefer to have as
> much business logic/workflow in the session/entity beans running within an
> application server.
I've been following this list for quite some time, and I've noticed that we
enter into this debate between HttpSessions and stateful session beans. To
me, these are two different things, meant to serve different purposes in the
J2EE architecture.
Regards,
Subbu
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
