W3C home > Mailing lists > Public > www-ws-arch@w3.org > September 2003

RE: Proposed text on 'SOA' (resend)

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>
Message-ID: <011401c3771d$9f0d9410$1faf2382@us.oracle.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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:22 GMT