> 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.
> 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
> creating the bean! In the above case, the servlet is the client.
Agree with that. My only point is that applet's session is much more
important for the application developer than that of servlet. I do realize
the servlet is the client of session bean.
> - 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.
Thanks,
Subu
===========================================================================
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".
