RE: Issue 7 - processing model for SOAP headers

Vikas,

My comments are inline... 

> If I get an URI out of a repository, I agree with you that 
> there might be a context there to help me process. If I get a 
> URI on the wire as I am network device, where is my context? 

Depends where/how you got the URI. If it was embedded in anchor tag in an
(X)HTML page it's a link that can be dereferenced. If it appears in a
namespace declaration, it is an opaque identifier of a namespace that may or
may not be dereferencable. My point is, there is always some context, unless
someone builds a service that simply returns a URI with no other
information, which is likely to be useless.
 
> The resolution of the logical to physical is part of the 
> network and is dynamic so I cannot use another intermediary 
> for that like the DNS or something. 

I don't understand why not. The mapping of DNS names to IP addresses is
dynamic and uses a well-known lookup mechanism. The same could be done here.

> Let's step back for a moment to recap where I am coming from. 
> 
> I read in the Core Spec of WSA 1.0 that "[address]: URI 
> (Mandatory). It says this address is logical/physical". The 
> resolution of this logical address to physical address should 
> depend upon it's binding to the wire transport. So in the 
> WSA-SOAP binding it should define how a logical address can 
> be resolved to physical. If the binding was some other 
> transport then that transport should define the resolution. 
> 
> My recommendation is either we should remove the text which 
> says "logical/physical" in the core spec and say the address 
> is logical ONLY and the transport binding will specify how to 
> resolve it down to physical.
> Alternative is to assume that transport at the end of the day 
> is HTTP and that the address is physical.

I don't think that we should limit ourselves to HTTP only traffic or assume
that the wsa:To is a physically reachable URL. Instead, the binding should
define the mapping from the logical to the physical, as the wording from the
spec suggests. So I think we're in agreement.
 
> Now let's say all address are now logical and my transport 
> binding resolves it to physical. Then a message is likely to 
> travel multiple transports. It is for this reason, that I 
> need the 'physical' address of the original destination. As I 
> have no way to keep state information of how many transport 
> hops this message took to get to me. 

This part I don't understand. I assume that like IP routing, the mapping
from logical to physical would be done in a series of steps. As long as each
node (may or may not be a SOAP intermediary) can map the logical To to the
physical address for the next hop, the message will move along making as
many hops over as many transports as necessary. Maybe another way to look at
it is that in a sense, the logical URI used in the wsa:To *is* a physical
address the same sort of way that a DNS name is a physical address. You can
program against a machine using it's DNS name without knowing where it
actually lives or even what it's IP address is.

Tim-

> 
> Thanks 
> 
> Vikas 
> 
>  
> 
> -----Original Message-----
> From: public-ws-addressing-request@w3.org
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of Tim Ewald
> Sent: Monday, January 17, 2005 7:44 AM
> To: vikasd@yahoo.com; 'Marc Hadley'; public-ws-addressing@w3.org
> Subject: RE: Issue 7 - processing model for SOAP headers
> 
> 
> Vikas,
> 
> Is logical vs. physical really that complex? A service has a 
> logical name that is a URI. There is a physical address that 
> is a URL. They might be the same or they might not. We have 
> this split already for namespace URIs, which are logical 
> namest that may or may not be dereferencable.
> 
> If you got a URI out of a repository, you'd need to know if 
> it was a logical To or a physical endpoint - or a namespace 
> for a schema or an identifier for something else. In other 
> words, you need context. I assume that would come from the 
> repository itself, i.e., "this value is a logical service URI".
> 
> You are right that a client would have to have some way to 
> map logical service URI to physical URL. There are lots of 
> possible ways to do that. For instance, you could look in a 
> local cache of mappings to see if there is an explicit one. 
> You could send the message to a well-known physical URL that 
> knows where logical services live. You could send it to the 
> domain name in the logical URL and hope that guy knows where 
> to send the message on to. And you could chain these 
> techniques together.
> 
> Tim-
> 
> > -----Original Message-----
> > From: Vikas Deolaliker [mailto:vikasd@yahoo.com]
> > Sent: Friday, January 14, 2005 5:06 PM
> > To: tim@mindreef.com; 'Marc Hadley'; public-ws-addressing@w3.org
> > Subject: RE: Issue 7 - processing model for SOAP headers
> > 
> > 
> > Tim,
> > 
> > In the model you describe, you are implicitly 
> distinguishing between a 
> > logical URL and physical URL.
> > 
> > Assuming that A received the URL from some discovery provider like 
> > UDDI, how can it tell if it is a logical or physical?
> > For logical URLs how does the node resolve it down to physical? 
> > Assuming it figured out the URL is logical through some out-of-band 
> > method, does it now have to process all SOAP headers?
> > 
> > I think this logical/physical split is quite complicated. 
> It would be 
> > simple to just have URL be physical all the time.
> > Since the URL has http:// in front of it means it has to be 
> physical 
> > HTTP server.
> > 
> > If the original source and destination URLs are necessary to be 
> > transferred, then we should add them as separate fields.
> > 
> > I agree we need to discuss this somewhere. 
> > 
> > Thanks
> > Vikas
> > 
> > 
> > 
> > -----Original Message-----
> > From: public-ws-addressing-request@w3.org
> > [mailto:public-ws-addressing-request@w3.org] On Behalf Of Tim Ewald
> > Sent: Friday, January 14, 2005 10:23 AM
> > To: vikasd@yahoo.com; 'Marc Hadley'; public-ws-addressing@w3.org
> > 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.
> > > > > 
> > > > > 
> > > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > 
> > 
> > 
> 
> 
> 
> 
>

Received on Tuesday, 18 January 2005 15:16:35 UTC