- From: Martin Chapman <martin.chapman@oracle.com>
- Date: Tue, 9 Sep 2003 14:59:19 -0700
- To: "'David Orchard'" <dorchard@bea.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>
Yes I meant web service instance. As for the ws address properties, why would you not either rely on payload data or info in a wsdl service element/enpoint uris? Martin. > -----Original Message----- > From: www-ws-arch-request@w3.org > [mailto:www-ws-arch-request@w3.org] On Behalf Of David Orchard > Sent: Tuesday, September 09, 2003 2:13 PM > To: 'Martin Chapman'; 'Savas Parastatidis'; 'He, Hao' > Cc: www-ws-arch@w3.org; 'Jim Webber' > Subject: RE: Proposed text on 'SOA' (resend) > > > > When you say "same" web service, do you mean the same type or > the same instance? > > I would say the equality function for stateless web service, > ie same type of web service, is a combination of the > interface and endpoint address. The equality function for > stateful web service, ie the instance, adds on service > specific parameters (aka ws addressing reference properties). > > I think the best way to differentiate stateful and stateless > web services is what is used to determine equivalence of the > service identifiers. > > I also want to make sure that the web services architecture > does not "value" stateless web services higher than stateful > web services. I personally think that much of the web is > built upon stateful retrievals, where things like cookie > variables are used to determine the service identifier. Some > will claim that stateless services are necessary to be higher > performance than stateful services, but that is simply > architecturally incorrect. After much discussion and > learning about how my company builds products and looking at > the characteristics of the typical interactions of web vs web > services, I will vehemently argue against any prevailing > wisdom that says stateless is by definition better than stateful. > > Cheers, > Dave > > > -----Original Message----- > > From: www-ws-arch-request@w3.org > [mailto:www-ws-arch-request@w3.org]On > > Behalf Of Martin Chapman > > Sent: Tuesday, September 09, 2003 12: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 17:58:59 UTC