RE: Issue 7 - processing model for SOAP headers

Doug,
 
To date, I've assumed that all the WSA headers would be targeted at the
ultimate receiver. Intermediaries might look at them, but they wouldn't
change them (I realize that that might force them to be "active
intermediaries", but that seems to happen quite a bit anyway, given how
WS-Sec works). Marc raised the valid and critical question of the processing
model and suggested a model like that (albeit with relaying to avoid the
active intermediary requirement). I like that model because it keeps things
very clean and relatively straight-forward.
 
I can tell you from experience working with several teams designing a
WSA-aware message router for Microsoft.com, that people really struggle with
the shift from the very physical one-hop HTTP world of WSDL as it is
commonly realized today to the logical URI world of WSA. The example I
described is the path that I think is easiest. You as a message sender want
to get a message to a service. You know two things: a logical endpoint
(wsa:To) and a physical endpoint (the transport address) and that's it. It's
up to each node to pick the next transport address and send the message on
unchanged. This means that intermediaries do not have logical endpoint URIs
(unless they are sometimes used as services, but that's a different case).
 
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?
 
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.
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > 
> > 
> > 
> 
> 
> 
> 
>