> there is only two types of client, one that holds it own state (i.e. uses
> stateless session beans) and one that doesnt, hence uses the stateful
> session beans.
>
> WAP is not my speciality, but... Does what your suggesting mean that for
> every WAP client your maintaining a Stateful object inside your webserver?,
> My thought was to put it in a stateful bean, which could be placed on an
> alternate machine away from the webserver. Interested in your thoughts...
WAP is not my specialty neither, but the solutions I know of uses
regular servlets through a WAP gateway. But these need to be separate
servlets, handling a different client. (I normally view the
browser/servlet/jsp package as one client, however layered). However,
these being just regular servlets, they can handle sessions just like
any other servlet. If your other servlets are keeping their sessions,
why not let these ones do it too?
With the two facades, you are leaving it up to the client programmer to
determine whether he is of the stateful or stateless kind, or in other
words a high load or a low load client. I would always be a low load
client ;-) What do you do when a low load client becomes a high load
client?
To me this architecture is "some clients keep their state, some don't".
This might be useful if you had clients that cannot hold its own state
but I can't think of any such client. And if there are no such clients,
this in my view would just be quite confusing, but that might just be
me. IMHO, if one client keeps it state, let the other ones do it to. By
doing this your beans know what to expect from their clients.
/Marcus
Marcus Ahnve
Sun Java Center
Sweden
===========================================================================
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".
