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 Monday, 17 January 2005 15:43:38 UTC