> I might be missing something here and I hope you guys can clear it up. I
am
> following the J2EE architecture DB-EntityBean-StateFul Session
> Bean-Servlet-Applet. Primarily I would like one session bean to attend to
> all calls from the applet-servlet for one session. I would consider the
> session here to be the time the applet inits and it dies. During the
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.
In this case, the servlet can just delegate the request from the applet to
the session bean.
> session, the applet would make several post/get calls to the servlet. It
> would be NICE if the same session bean could hold the state during session
> rather than the servlet between the post/get calls for one client. The
ideas
> I am getting from this thread is that the "session" for a session bean is
> what happens during one post/get call of the servlet and not of the final
> client which is the applet.
No. This is not the case. The scope of the session here depends on who is
creating the bean! In the above case, the servlet is the client.
> So it is the responsibility of the servlet to hold the state during the
> session rather than that of the session bean. The problems I see is that
the
> HttpSession object (I have not used this before and hence feel free to
> correct me) might not be highly dependable due its use of cookies, url
> redirection or ssl if we have a not so willing client. I am hoping for a
> solution where a session bean would hold the state of the real session i.e
> of the applet which is the final and real client.
Let's put it this way:
- The stateful session bean is meant to store conversational state between
the bean and its client. What to treat as conversational state depends on
the conversation - that is the business logic. So, the idea is for the
stateful bean to maintain the state of the conversation it is doing with its
client.
- In your case, the servlet is the client of the session with the session
bean.
- FYI, the HttpSession is highly dependable - the cookie vs URL rewriting
issue is generally transparent to the client, as long as all the URLs are
encoded.
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.
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".
