- From: Cutler, Roger (RogerCutler) <RogerCutler@chevrontexaco.com>
- Date: Tue, 9 Sep 2003 14:51:27 -0500
- To: "Martin Chapman" <martin.chapman@oracle.com>, "Savas Parastatidis" <Savas.Parastatidis@newcastle.ac.uk>, "He, Hao" <Hao.He@thomson.com.au>
- Cc: www-ws-arch@w3.org, "Jim Webber" <jim.webber@arjuna.com>
Seems to me that it would be friendly toward the reader if one explained this pretty clearly up front. If you just say that SOA services are stateless without explaining how one then layers stateful interactions on top that it might be a bit confusing. -----Original Message----- From: Martin Chapman [mailto:martin.chapman@oracle.com] Sent: Tuesday, September 09, 2003 2:09 PM To: 'Savas Parastatidis'; 'He, Hao' Cc: www-ws-arch@w3.org; 'Jim Webber' Subject: RE: Proposed text on 'SOA' (resend) I mostly agree about your comment below, but I think there is missing one piece that allows "statefulness" to be layered on top. In a pure "stateless model" I (mostly) don't care which web service process my request. But a necessry precursor to the stateful models is the ability to talk to the "same" web service over as series of interactions. Thus an identity model is required. Martin. > -----Original Message----- > From: www-ws-arch-request@w3.org > [mailto:www-ws-arch-request@w3.org] On Behalf Of Savas Parastatidis > Sent: Tuesday, September 09, 2003 11:37 AM > To: He, Hao > Cc: www-ws-arch@w3.org; Jim Webber > Subject: RE: Proposed text on 'SOA' (resend) > > <snip> > > Regarding statefulness/stateless... > > I personally see services as stateless entities. A service > should be defined with stateleness as a default behaviour. By > statelness I mean that there is nothing in the definition of > a service that allows it to correlate messages it receives or > sends. Statefulness is achieved through additional message > correlation mechanisms. > > If a token was to be sent as part of the message, that > doesn't mean that the service is stateful. Instead, an > application-specific mechanism has been employed to build > stateful interactions on top of a stateless architecture > (SOA). There is something to be said about a community-agreed > mechanism for achieving this but the fact still remains that > the semantics of a service do not need to change. So, I agree > with Bill's comment that this group should provide guidance > on how stateful interactions should be achieved in the same > manner that the group is talking about transactions, > orchestration, etc. However, that does not mean that anything > regarding stateful interactions should appear in the > explanation of SOA and the definition of a service. > > Just my 2c. > > Regards, > -- > Savas Parastatidis > http://savas.parastatidis.name > > >
Received on Tuesday, 9 September 2003 15:52:34 UTC