RE: Proposed text on 'SOA' (resend)

Fully agreed.  Just also want to add:

The same "same" argument can also be applied on clients. 

From the service's point of view, it becomes stateful if it needs to
differentiate its clients. 

Hao

-----Original Message-----
From: David Orchard [mailto:dorchard@bea.com]
Sent: Wednesday, September 10, 2003 7:13 AM
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
> >
> >
> >
>
>