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.
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > 
> > 
> > 
> 
> 
> 
> 
>