RE: [wsrf] Singleton Resource Pattern

[Ian Robinson <ian_robinson@uk.ibm.com>]

My, how this acorn of a discussion is now a mighty oak.....

I will shortly send out an agenda for the F2F. I'll reserve some time for a discussion of the singleton resource pattern.

Can I take this opportunity to remind the TC that, with respect to "where the message goes", we as a TC need to define:

1. specifications that will allow the relationship between a Web service and state to be modelled in an explicit and standardized fashion
2. a framework within which Web services can access state in a consistent and interoperable manner, and an access pattern through which service requesters can interact indirectly with stateful resources through a Web service that encapsulates the state
   
   Regards,
   Ian
   
   
   
   

   "Glen Daniels" <gdaniels@sonicsoftware.com> 13/07/2004 01:19

   To:        "Jim Webber" <Jim.Webber@newcastle.ac.uk>, "Rich Thompson" <richt2@us.ibm.com>, <wsrf@lists.oasis-open.org>         cc:                 Subject:        RE: [wsrf] Singleton Resource Pattern

   
   
   
   
   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  
   >
   >
   >