RE: Issue 7 - processing model for SOAP headers

That's my understanding too.

Gudge

> -----Original Message-----
> From: public-ws-addressing-request@w3.org 
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of Tim Ewald
> Sent: 14 January 2005 07:40
> To: vikasd@yahoo.com; 'Marc Hadley'; public-ws-addressing@w3.org
> Subject: RE: Issue 7 - processing model for SOAP headers
> 
> 
> As I understand WS-Addressing, the To is the identifier for 
> the ultimate
> receiver and never changes. While a load balancer may select 
> a different
> *physical* destination for a message, it would not change the 
> *logical*
> destination, i.e., the wsa:To. At least that's how I think it 
> works. ;-)
> 
> Tim-
> 
> > -----Original Message-----
> > From: Vikas Deolaliker [mailto:vikasd@yahoo.com] 
> > Sent: Thursday, January 13, 2005 7:44 PM
> > To: tim@mindreef.com; 'Marc Hadley'; public-ws-addressing@w3.org
> > Subject: RE: Issue 7 - processing model for SOAP headers
> > 
> > 
> > Perhaps we can define SourceFrom and DestinationTo as 
> > separate from the immediate hop From: To:. The reason for 
> > this is one cannot rule out intermediaries whose purpose in 
> > life is to virtualize or load balance a service. For such an 
> > intermediary the changing the To: is very important. 
> > 
> > By having a original source and destination From/To, we can 
> > preserve all the headers as Marc points out and still be able 
> > to create a rich intermediary infrastructure. 
> > 
> > Vikas Deolaliker
> > Sonoa Systems, Inc.
> > 
> > 
> > -----Original Message-----
> > From: public-ws-addressing-request@w3.org
> > [mailto:public-ws-addressing-request@w3.org] On Behalf Of Tim Ewald
> > Sent: Thursday, January 13, 2005 6:29 AM
> > To: 'Marc Hadley'; public-ws-addressing@w3.org
> > Subject: RE: Issue 7 - processing model for SOAP headers
> > 
> > 
> > Marc,
> > 
> > I think this is desperataly needed. I've seen router 
> > implementations that change the value of wsa:To in transit. 
> > The WSA spec needs to say whether or not that is allowed.
> > 
> > This is also relevant to the discussion of issue 9 regarding 
> > multiple instances of headers. I mentioned in a separate 
> > message that there might be security issues there. With vague 
> > header processing rules, one can imagine all sorts of 
> > dastardly deeds, including inserting an extra wsa:Action 
> > header before the real one in order to get an intermediary 
> > (who might not be validating signatures on headers because 
> > they were targeted at the ultimate
> > receiver) to route the message somewhere it shouldn't. If the 
> > intermediary removed that header during processing, there 
> > might be no trace that it had been tricked.
> > 
> > Thanks,
> > Tim-
> > 
> > > -----Original Message-----
> > > From: public-ws-addressing-request@w3.org
> > > [mailto:public-ws-addressing-request@w3.org] On Behalf Of 
> > Marc Hadley
> > > Sent: Wednesday, January 12, 2005 4:00 PM
> > > To: public-ws-addressing@w3.org
> > > Subject: Issue 7 - processing model for SOAP headers
> > > 
> > > 
> > > Issue 7 concerns the processing model (or lack of) for the SOAP 
> > > headers defined by WS-Addressing. WS-A defines the 
> > following message 
> > > addressing properties, each of which is bound to an 
> individual SOAP 
> > > header:
> > > 
> > > wsa:MessageID
> > > wsa:RelatesTo
> > > wsa:ReplyTo
> > > wsa:From
> > > wsa:FaultTo
> > > wsa:To
> > > wsa:Action
> > > 
> > > All of the above headers (when specified by the sender) 
> seem to be 
> > > required at the destination endpoint but might also be useful to 
> > > intermediaries in the SOAP message path, e.g.
> > > wsa:To, wsa:Action, wsa:RelatesTo might be used for 
> message routing.
> > > 
> > > SOAP defines a processing model[1] for message receivers 
> > > (intermediaries and the ultimate recipient) that defines 
> > how a message 
> > > is processed, this includes:
> > > 
> > > - what SOAP headers are processed at a receiver (targeting)
> > > - understanding of headers and description of mustUnderstand 
> > > processing
> > > - relaying of SOAP messages including removal of 
> processed headers.
> > > 
> > > The specification of a particular SOAP header can define 
> additional 
> > > semantics that apply to that header, e.g. the specification of a 
> > > particular header might require that it be reinserted if 
> > processed by 
> > > a SOAP intermediary such that it survives intermediary 
> > processing and 
> > > remains in the message until it reaches the ultimate recipient.
> > > 
> > > Currently the SOAP Binding for WS-A doesn't discuss targeting or 
> > > replaying of WS-A defined headers in any normative way.
> > > The examples in the specification do not include a role/actor 
> > > attribute, this is equivalent to targeting the header to 
> > the ultimate 
> > > recipient but if we decide to specify this normatively then we 
> > > preclude processing of WS-A headers by a forwarding 
> > intermediary (note 
> > > that SOAP active intermediaries provide a way round this). My 
> > > preference would be to specify that all of the WS-A header 
> > blocks are 
> > > reinserted if processed by an intermediary and recommend 
> that they 
> > > carry a relay="true" and role=".../next" attribute. This 
> > formulation 
> > > woul dallow each header to be processed by a forwarding 
> > intermediary 
> > > whilst ensuring that all WS-A headers also survive to the 
> ultimate 
> > > recipient.
> > > 
> > > Beyond the simple reinsert processing model proposed above I also 
> > > think it would be worth adding sections to the SOAP binding 
> > > specification containing a processing model for each 
> > header. This may 
> > > be as simple as referring back to the relevant section in 
> the core 
> > > document or (in some
> > > cases) specifying that there is no processing model and that the 
> > > header is purely informational.
> > > 
> > > Thoughts, comments ?
> > > 
> > > Marc.
> > > 
> > > [1] 
> > http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#msgexchngmdl
> > > ---
> > > Marc Hadley <marc.hadley at sun.com>
> > > Web Technologies and Standards, Sun Microsystems.
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > 
> > 
> > 
> 
> 
> 
>

Received on Friday, 14 January 2005 15:52:06 UTC