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/