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
