RE: Proposed text on 'SOA' (resend)

By payload I mean the body e.g somewhere deep in a document being sent is
something like a purchase order that only the application understands; it's
not visible at the wsdl level, but its important for application "context".
Irrespective of any identity model at the infrastructure level and unknown
by the infrastructure, an application is aways free to  make context
associations an assumptions based on document contents. However the
infrastructure does have the responsibility that *if asked* the document is
sent to appropriate place. As far as I can see this "appropriate" place can
be expressed by the endpoint uris associated with a service. 
What other identity/context mechanism needs to be formalised at the basic
wsa level? IHMO, none.


Martin.

> -----Original Message-----
> From: David Orchard [mailto:dorchard@bea.com] 
> Sent: Tuesday, September 09, 2003 4:38 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 "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 Wednesday, 10 September 2003 14:00:48 UTC