axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jayachandra <>
Subject Re: [VOTE] [Axis2] Sessions on by default?
Date Fri, 30 Dec 2005 12:30:34 GMT
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"

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 <> 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

View raw message