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

RE: Proposed text on 'SOA' (resend)

From: David Orchard <dorchard@bea.com>
Date: Tue, 9 Sep 2003 16:37:54 -0700
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>
Message-ID: <014301c3772b$65706670$900ba8c0@beasys.com>

When you say "payload", I'm not sure what you mean.  We don't define such a
term.  I assume you mean message body.  Oh, we don't define message body.
Maybe message content?  oh, that's not defined either.

I'm being deliberately cheeky because we have simply got to start talking in
terms of terms we've already defined and making sure our definitions are
usable.

But what does payload data vs wsdl service uris have to do with stateless vs
stateful and defining what constitutes the identifiers?  I feel like you are
arguing about whether the message header should have data or message body,
which is totally orthogonal to the issue of whether the service is stateful.
From the perspective of the service, identifier information in the message,
beit message header, message body, or some outer envelope, makes it
stateful.

Dave

> -----Original Message-----
> From: Martin Chapman [mailto:martin.chapman@oracle.com]
> Sent: Tuesday, September 09, 2003 2:59 PM
> To: 'David Orchard'; 'Savas Parastatidis'; 'He, Hao'
> Cc: www-ws-arch@w3.org; 'Jim Webber'
> Subject: RE: Proposed text on 'SOA' (resend)
>
>
> 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 19:48:41 GMT

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