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:40:18 UTC