Re: [Axis2] Service Scopes, statefull vs stateless

[Rajith Attapattu <ra...@gmail.com>]

Hi Deepal,

I think the scopes are more for instance managment than session managment.
(the new session mgt doesn't attempt to touch this as it is out of it's
scope). The scope determines the lifecycle of an instance, or rather how
long shoud it live in simple terms.

Web Services should be stateless !!!!!
My definition and understanding is Web Services should not explicitly mange
a converstational state with a client. Or else they cannot scale well.
(I stand to be corrected on this)

They should persist any operational data btw requests and use a session only
to share a simple conversational state that could be,
a) transient
b) persisted
c) replicated
The service itself should not be carrying data around in memory that could
cause serious scalability and other issues.

However following are my arguments.

Application-Scope vs Request-Scope
------------------------------------------------------
I argue that Application scope is inherently stateless. It's like a
singleton thats shared by many clients. So it cannot have any data thats
client specific. So by definition it should be stateless. It can only cary
data thats immutable by a client.

A good candidate for application-scope would be a stock quote service which
display the top five picks of the day. This can also be done with a service
which has it's scope marked as "request-scope"

I would argue that application scope is the same as request scope. The only
difference is that in application-scope the service instance lives as long
as the application. In request-scope a new instance is created for each
request ( correct me if I am wrong )

So what is the difference ? what benifit does it bring to an application
developer? (Please correct me if I have missed a point)

Soap-Session-Scope vs Transport-Session-Scope
--------------------------------------------------------------------------
In other thread on session mgt I have suggested that we phase out service
groups (which will eliminate soap session scope) and to add HTTP transport
(cookies) session as another stratergy under the new  session mgt system to
bring everything under a unified Session API.

As I said scope should be used to manage service lifecycle and not to
determine a session mgt stratergy. I think thats a wrong approach from an
architectural POV. Session mgt stratergy should be determined in a different
way and if it's tied to service lifecycle then it's difficult from a lot of
aspects like performance, clustering ...etc.

Regards,

Rajith

On 4/5/06, Deepal Jayasinghe <de...@opensource.lk> wrote:
>
> Hi Rajith
>
> pls see my in-line comments
>
> Rajith Attapattu wrote:
>
> > Hi All,
> >
> > I have a question on the usability of the current scoping mechanism.
> >
> > As I understand the current impl has the following scopes when we
> > deply an application
> >
> > Application scope
> > Soap Session scope
> > Http Transport session scope
> > Request scope
> >
>
> yes we do
>
> > But I think they can be collapsed into 2 simple categories
> >
> > Stateful services and Stateless services.
> > Stateless  = (Application and Request scopes)
>
> ohhh , I dont think if some one deploy a service in application scope it
> wont be a stateless service , it has state and which will be equal to
> application life cycle.
> In simple word if some one deploy a service in application scope , then
> there will only one instance of the service impl class life time of the
> system. So I can not agree with that services which are in application
> scope are stateless.
>
> > Statefull   =  (Soap session scope and Http Transport session scope)
> >
> > So I am wondering do we really need to have this distinction. Can we
> > not just simply denote wether the service is stateful or stateless.
> >
>
> Please correct me if I am wrong , Axis1 has the same terminology , and
> SOAP session is totally different from HTTP transport session. SOAP
> session is transport independent if client send the required SOAPHeadere
> parameter then we are happy to support SOAP session management.And
> transport session management happen using cookies.
>
> > With the new session mgt impl we can simply categorise services as
> > stateful and stateless.
>
> I think that is not enough I think we have to have multiple scope as well.
>
> >
> > What do you guys think??
> >
> > Regards,
> >
> > Rajith
>
>
> --
> Thanks,
> Deepal
> ................................................................
> ~Future is Open~
>
>
>