RE: [wsrf] Singleton Resource Pattern

["Glen Daniels" <gdaniels@sonicsoftware.com>]

Hi folks!

Here is how I see this.

Web services are not "stateful" or "stateless" at all.  They are simply
about message passing as the key architectural concept.  Some particular
places where messages go will react in a "stateful" way, and others will
not.  This aspect (and it really is an aspect a la AOP, I think :)) of
the service semantics is analagous to whether or not a service happens
to use particular security technology, or happens to be about processing
purchase orders.  In other words, one of many orthogonal and "layerable"
concepts on top of the core idea of sending well-specified messages back
and forth.

Now, when considering whether a particular Web service is stateful, all
that matters, I think, is that the service satisfy the statefulness
"contract".  For instance, I can imagine a counter service which accepts
an "incremement" message and a "getValue" message.  Particular
implementations of this service may a) always return 1 for getValue()
(i.e. fail to work :)), b) return a "session-based" value - in other
words, each user has some concept of "their" counter which increments by
one as expected each time increment() is invoked, and c) return a
"singleton/shared" value - getValue() returns the number of times ANYONE
has sent an increment() message. Which of the these choices a particular
service makes is orthogonal to the increment/getValue interface itself,
just as I think it should be orthogonal to the WSRP interfaces.

The point here is that the "bag of state" which is the counter value has
to somehow be associated with the received messages, but that can happen
in a whole variety of ways.  First, I can use REST-like patterns and
return a URL per "state bag".  No headers necessary in that case at all.
Second, I can do some transport-specific tricks if my binding supports
them; i.e. I could choose to have a "state bag" per remote IP address,
or I could use HTTP cookies, or the SOAPAction header.  Third, I could
use SOAP headers - WS-Context, WS-Addressing, and the Apache Axis
session headers all come to mind as viable choices here.

The problem of "where the message goes" (sometimes known as the dispatch
problem) is one that is not in any way limited to WSRP-type
interactions.  ALL Web service interactions can potentially encounter
this, and we should allow the wider community to solve it without
mandating a particular solution (always use WS-Addressing) in this WG.
Why would we want to limit the above set of solutions?

Just as there are a variety of different security requirements which
might layer on top of my getStockQuote interface, there might be a
variety of different ways of doing dispatch which could be layered on
top of GetResourceProperty()/SetResourceProperty().  I for one don't
think that allowing this problem to be solved separately in any way
reduces the value proposition of the WSRP style.  In fact, I think NOT
mandating it improves the number of potential scenarios in which WSRP
might be useful....

Make sense?

--Glen

> -----Original Message-----
> From: Jim Webber [mailto:Jim.Webber@newcastle.ac.uk] 
> Sent: Monday, July 12, 2004 7:59 PM
> To: Rich Thompson; wsrf@lists.oasis-open.org
> Subject: RE: [wsrf] Singleton Resource Pattern
> 
> Rich:
> 
> > What would get/setProperty mean against the standard stateless 
> > character of the base Web Services definition?
> 
> This is the kind of statement that gets us into trouble :-)
> 
> Web Services are "stateless" insofar as all of the 
> information required to execute an action are contained 
> within the message which instigates that action (c.f. the 
> architecture of the Web).
> 
> Pretty much all useful Web Services have state. The point 
> under consideration is whether it is a sensible idea to 
> present that state to consumers.
> 
> Jim
> --
> http://jim.webber.name  
> 
> 
>