Jaya,

The deed is done, let's live with it for 0.94 at least.

thanks,
dims

On 12/30/05, jayachandra <[EMAIL PROTECTED]> wrote:
> Hi guys, am thinking aloud here.
> On the server side I firmly believe default choice should be 'NO SESSIONS',
> for the default notion of webservices is they are stateless.
> Having said that, coming to the client side we have a couple of options
>
> Option1: Client side sessions (what type of sessions - transport or soap?
> will talk later) are by default turned ON
>
> Option2: Client side sessions (whatsoever) are turned OFF
>
> If we choose Option1, we have to address which type of session to be turned
> on. Is it just the transport session or soap kind of one with WSA refs? The
> later surely is going to be a performance hijack most of the cases.
> Transport session being ON on the client side seems logical if that doesn't
> cause much overhead (it shouldn't be that heavy). So can treat me as +0 for
> "Switch on Transport session  by default (only cookie, no ws-a stuff)"
>
> But on the server side if default is NO SESSIONS, why not also keep client
> request simple and only the required things, this makes me go +1 for Option2
> i.e. "Don't switch on sessions by default"
>
> Thanks
> Jaya
> P.S:: I understood that the initial vote was requested for both generated
> client code and as well as server code.
> Am willing to revote again if someone has a convincing post on how default
> client side SESSIONS are helpful.
>
> On 12/30/05, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:
> > On Tue, 2005-12-27 at 09:39 +0100, Werner Dittmann wrote:
> > > [X] - Don't switch on sessions by default
> > >
> > > Well, I'm not an Axis developer, but makeing web services
> > > "statefull" (session aware) by default is IMO not a good idea.
> > > If some web services need "session" it should be done deliberatly
> > > because the system must take care of the session data.
> > >
> > > Just think about scaleability (load sharing) of webservices on
> > > different servers using IP load balancers. If a service
> > > needs some state (session data) this state must be replicated
> > > to all servers by some means, otherwise you can't perform
> > > load sharing. Such a thing has to be designed, your overall
> > > solution must be aware of it etc etc.
> >
> > Werner, you've got it all backwards .. the issue is on the client side,
> > not on the server. On the server if the service is session scoped then
> > you *have to* create service contexts and store them against the cookie
> > ID until they time out. *None* of the points you made apply to the
> > situation at hand!
> >
> > The question Dims asked is about what the default should be for clients.
> > I disagree with the apparently popular choice of no sessions because if
> > a service has multiple operations then in most cases the operations have
> > some relationships between them. The question really amounts to asking
> > how often do people have session scoped services vs. application scoped
> > services. If they are application scoped then basically the cookie stuff
> > makes no difference: either the service is totally stateless and it
> > ignores all context or its truly stateful and remembers something from
> > every request.
> >
> > IMO the natural behavior should be to maintain sessions by default.
> > That's what even Apache SOAP did back many years ago.
> >
> > I was out of town for a few days so was not able to reply in a timely
> > manner to convince more voters :(. Can we have a re-vote based on the
> > information that Werner's explanation does not apply at all and at least
> > 3 people voted based on that?
> >
> > Sanjiva.
> >
> >
> >
>
>
>
> --
> -- Jaya


--
Davanum Srinivas : http://wso2.com/blogs/

Reply via email to