Re: Stateful services (was Web Service Description and stateful services)

Hello Savas,

It seems to me that the state which you characterized as "3. State as in
"data resource"" is a more general case of either 1. Service state or  2.
Application state

For example if we have a huge file which needs to be exposed, then if it
doesn't matter which customer gets some data from this file (identified by
some token), then it looks like that this file is really part of the
1.Service state
However, if a service wants to present to different clients the different
views of the same data extracted from the file, then it becomes
2.Application/activity state

Thanks
Sergey Beryozkin
----- Original Message -----
From: "Savas Parastatidis" <Savas.Parastatidis@newcastle.ac.uk>
To: <www-ws-arch@w3.org>
Cc: "Paul Watson" <Paul.Watson@newcastle.ac.uk>; "Jim Webber"
<jim.webber@arjuna.com>; "Thomas Rischbeck" <thomas.rischbeck@arjuna.com>;
<arnaud.simon@arjuna.com>
Sent: Tuesday, June 24, 2003 7:44 AM
Subject: Stateful services (was Web Service Description and stateful
services)


>
> All,
>
> [snip]
> >
> > In order to provide stateful service, the service provider must be
> able to
> > distinguish its service requestors. So, we just need to define a
> standard
> > way of providing a requestor differentiator.
> >
>
> I do not believe that just identifying the requestor can be enough.
> Please allow me to describe the way I perceive state (in all its forms)
> in relation to web services and see whether others agree.
>
> I see three totally different uses of the term "state".
>
> 1. Service state: A service decides to maintain some state between
> different operation invocations. For example, imagine a counter service
> that has operations to increase and decrease a value. This particular
> service makes no consumer related assumptions. Anyone can
> increase/decrease the value and everyone sees the same value. This kind
> of state is totally irrelevant to the Web services architecture. There
> is no need for standardisation here.
>
> 2. Application state: As part of the semantics of a service, information
> needs to be maintained between different interactions with one or, why
> not, more consumers. We usually refer to this kind of state as session
> state when one consumer and one service are involved. However, this does
> not be the case. Application state can be maintained as part of a larger
> interaction, an activity, involving multiple participants. You can
> imagine an activity spanning a number of services (I don't distinguish
> between consumers and services anymore). The activity context carries
> the necessary information for the services involved to reconstruct the
> application state associated with that particular activity.
>
> Something similar is already done with WS-coordination and
> WS-transactions. However, in these protocols the
> coordination/transaction context carry protocol specific information
> that would not be necessary in an activity context.
>
> Imagine a counter service that provides unique counters to consumers
> upon request. A consumer may request from the service to get its "own"
> counter. The service returns an activity context (a token, an id, a URI,
> whatever) that is used from that point forward between every
> interaction. The consumer and the service have some common way of
> reasoning about the application state (the value of the counter). The
> activity context can be passed to other services that are allowed to
> "share" the same counter.
>
> OGSI uses the term "stateful web services" to represent this kind of
> interaction. It uses the notion of "grid service instances" to create
> new services that are identified by a unique URI (the Grid service
> handle). This unique URI is the way consumers and service reason about
> application state in OGSI.
>
> I personally prefer the context approach since it does not break the
> "web services are components" definition of WSA. The transient nature of
> grid service instances remind me of objects rather than components.
>
>
> 3. State as in "data resource": Data resources may need to be exposed or
> made available for consumers/services to refer to. You can imagine a
> huge file that resides behind a service. Instead of putting the file "on
> the wire", a service may choose to send an ID or, more probably, a URI
> to other services so they can refer about the same thing. I don't see
> why anyone would to expose "internal" resources like that but
> high-performance computing scientists tend to do that a lot.
>
> In terms of standardisation, it is my view, as with the first case, that
> nothing needs to be done here either. This feature is application domain
> specific. Different domains need to define different ways of reasoning
> about data resources. Have a look at how the life-sciences people have
> come up with LSIDs, which are URIs identifying life-sciences related
> data resources.
>
>
>
> So, that leaves us with case 2, where standardisation could help. An
> extensible protocol, similar to WS-Coordination but without the same
> restrictions, could allow different forms of interactions to be created.
>
>
> Am I way off from people's view on this?
>
> Regards,
> --
> Dr. Savas Parastatidis
> Chief Software Architect, North-East Regional e-Science Centre
> School of Computing Science, University of Newcastle upon Tyne, UK
> http://savas.parastatidis.name
>
>
>
>
>

Received on Tuesday, 24 June 2003 09:15:51 UTC