RE: Issue 7 - processing model for SOAP headers

Tim wrote:
> ...
> The issue I see with what you are suggesting is that it opens the door 
to all sorts
> of complexity. Does the message below say that you're supposed to go to 
B before C 
> (i.e., order of headers matters)? Can A send the message directly to C 
and if it 
> can, does C have to play the interB role or is it okay to ignore the 
first header? 
> Are you allowed to tell B and C that you are performing different 
actions? What if 
> any security issues does this raise? Finally, does the presence of 
ref-p's for B's 
> To imply that you need EPRs for both B and C and that you can resolve 
conflicts 
> between their refp headers?

All of the questions you raise here are not WSA specific however; they 
apply to
SOAP (and the use of intermediaries) in general.  WSA could choose to 
disallow the
use of the headers this way but w/o any statement to that effect it leaves 
the door
open for it to be used as I described.

-Doug

> 
> Given the complexity that intermediaries add, I try to keep them very 
much separate
> from the logical message exchange. I would like to see WSA focus on that 
instead of
> adding targeted headers for intermediary processors.
> 
> Thanks,
> Tim-
> 
> From: Doug Davis [mailto:dug@us.ibm.com] 
> Sent: Friday, January 14, 2005 1:51 PM
> To: tim@mindreef.com
> Cc: 'Marc Hadley'; public-ws-addressing@w3.org; 
public-ws-addressing-request@w3.
> org; vikasd@yahoo.com
> Subject: RE: Issue 7 - processing model for SOAP headers

> 
> Tim, 
>   Would you consider this scenario valid? 
> 
> msg from A->B looks like: 
> <env> 
>   <header> 
>     <wsa:To actor="interB"> URI of B</wsa:To> 
>     <ref-p's for B's To> 
>     <wsa:To> URI of C</wsa:To> 
>     <ref-P's for C's To> 
>   </header> 
> </env> 
> 
> then msg from B->C looks like: 
> <env> 
>   <header> 
>     <wsa:To> URI of C</wsa:To> 
>     <ref-P's for C's To> 
>   </header> 
> </env> 
> 
> -Doug 
> 
> 
> 

> 
> "Tim Ewald" <tim@mindreef.com> 
> Sent by: public-ws-addressing-request@w3.org 
> 01/14/2005 01:23 PM 
> 
> Please respond to
> tim
> 
> To
> 
> <vikasd@yahoo.com>, "'Marc Hadley'" <Marc.Hadley@Sun.COM>, 
<public-ws-addressing@w3.org> 
> 
> cc
> 
> Subject
> 
> RE: Issue 7 - processing model for SOAP headers
> 
> 
> 
> 
> 
> Vikas,
> 
> I am not assuming this is session level, but service level. Here's how I
> believe it works. You have a message going from A through an 
intermediary B
> to an ultimate receiver C:
> 
> A --> B --> C
> 
> You want B to load balance, so it is picking one of a number of C's 
based on
> some algorithm. A sets the wsa:To to be the logical URI that identifies 
the
> service. That value never changes as the message traverses the path. A 
sends
> the message to the physical URL of the intermediary B. B looks at the 
wsa:To
> and whatever else it needs, selects an instance of C and forwards the
> message to it using the physical URL of the ultimate receiver C. B does 
not
> change the wsa:To, it is always the logical URI of C. The physical 
address
> from A to B and the from B to C change as the message traverses it's 
path.
> 
> All of this suggests not only that the WG needs to define the processing
> model for headers, but that it has to be reconciled with the notion of a
> message path from an ultimate sender to an ultimate receiver as defined 
by
> SOAP.
> 
> Thanks,
> Tim-
> 
> 
> > -----Original Message-----
> > From: Vikas Deolaliker [mailto:vikasd@yahoo.com] 
> > Sent: Friday, January 14, 2005 12:51 PM
> > To: tim@mindreef.com; 'Marc Hadley'; public-ws-addressing@w3.org
> > Subject: RE: Issue 7 - processing model for SOAP headers
> > 
> > 
> > Tim,
> > 
> > You are assuming a session level load balancer. In that 
> > scenario you are right, the physical address remains the 
> > same. In a service level load balancer the load balancer will 
> > change the To: as well. The load could be balanced on the 
> > same physical address or multiple physical addresses. 
> > 
> > Having the original source/destination URLs as separate 
> > fields then would be necessary to satisfy the requirement 
> > stated by the original author from Sun.
> > 
> > 
> > Vikas 
> > 
> > -----Original Message-----
> > From: Tim Ewald [mailto:tim@mindreef.com]
> > Sent: Friday, January 14, 2005 7:40 AM
> > 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.
> > > > 
> > > > 
> > > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > 
> > 
> 
> 
>