RE: Stateful services (was Web Service Description and stateful s ervices)

hi, Savas,

It seems to me that your OGSI example just shows all you need is a simple
requestor differentiator for stateful service.  Did I understand it
correctly?

I don't like the idea of passing context around.  It does not seem to scale.

Hao

-----Original Message-----
From: Savas Parastatidis [mailto:Savas.Parastatidis@newcastle.ac.uk]
Sent: Tuesday, June 24, 2003 4:45 PM
To: www-ws-arch@w3.org
Cc: Paul Watson; Jim Webber; Thomas Rischbeck; arnaud.simon@arjuna.com
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