RE: SOAP & Web arch

As someone who probably at least named the property
"ImmediateDestination" and possibly penned early drafts of the two
sentences that Mark has picked upon... it seems to me the concept of an
"ImmediateDestination" (and indeed "ImmediateSource") are called out as
MEP properties and that what is missing  from the the MEP specifications
is "UltimateDestination" property (and I guess, correspondingly
"UltimateSource" property for when that can be determined) and thence an
articulation of how they are used in the relevant protocol binding
specifications. "ImmediateDestination" and "UltimateDestination" are
clearly concepts that apply to a SOAP message path regardless of
underlying protocol (and could possibly be multi-valued to cover
multicast cases - hmmm).

However, winding the clock back a bit (to circa July 2002), and this may
still be the case (at least it was possible) IIUC an
"UltimateDestination" can be somewhat emergent as a consequence of
computations performed on SOAP headers (and possibly SOAP bodies) at
SOAP intermediaries. If that remains the case, then other than using
http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver as a means
of stating the obvious :-), there may be no available URI value to place
in the HTTP request line.

I guess this all begs the question of an explicit articulation of SOAP
message paths and operation through intermediaries which IIRC were left
as the subject of further work post SOAP 1.2.

Regards

Stuart Williams
--

> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] 
> On Behalf Of Mark Baker
> Sent: 30 March 2006 20:28
> To: David Orchard
> Cc: www-tag@w3.org
> Subject: Re: SOAP & Web arch
> 
> 
> Hey Dave,
> 
> On 3/30/06, David Orchard <dorchard@bea.com> wrote:
> > Does this apply to all SOAP meps?  In particular, does the 
> > immediatedestination get set to the address value for all meps, or 
> > just when HTTP is known to be the binding?  I'll yet again observe 
> > that the SOAP 1.2 request-response MEP tries to abstract away which 
> > protocol is in effect, so it breaks the MEP abstraction to talk
about 
> > immediatedestination when HTTP is the protocol.
> 
> Hmm, I don't see how that follows.  I agree that the Req/Resp 
> MEP is "protocol independent", but it does expose the 
> ImmediateDestination property which is not HTTP specific at 
> all AFAICT.  It only "meets"
> HTTP in the HTTP binding where the MEP is instantiated and 
> ImmediateDestination is bound to the HTTP Request-URI.
> 
> > Note that we added something like this into WSDL 2.0 " The SOAP 
> > "http://www.w3.org/2003/05/soap/mep/ImmediateDestination" property 
> > takes the value of the WSDL {address} property of the Endpoint
component."
> 
> Interesting, though I'm not sure how that impacts the message.
> 
> > So something like the following in WS-A SOAP binding would satisfy
you?
> > I'm not that I'm saying that I agree with it, just making sure it's 
> > crystal clear.
> >
> > <<current text>>
> > 3.4 Binding Message Addressing Properties When a message is to be 
> > addressed to an endpoint, the XML Infoset representation of each 
> > message addressing property that has been assigned a value is
inserted 
> > into the message as a SOAP header block subject to the following 
> > additional constraints:
> > <</current text>>
> >
> > <<new text>>
> > When using HTTP, the address value is also copied to the HTTP 
> > request-uri field.  In SOAP 1.2, this means the SOAP 
> > "http://www.w3.org/2003/05/soap/mep/ImmediateDestination" property 
> > takes the address value when the HTTP binding is used.
> > <</new text>>
> 
> That would be an HTTP-specific fix, sure.  But a generic fix 
> would be to simply say that the WSA address property should 
> also(*) be bound to the ImmediateDestination SOAP property.
> 
> This would, of course, require that all MEPs supported by WSA 
> have an ImmediateDestination property with these semantics.  
> That's certainly the case for the two defined by SOAP 1.2, 
> and I would expect it to be the case that other MEPs would 
> have something similar .. but I suppose it might have a 
> different name.  I'm not familiar with any other MEPs though 
> (or at least none come immediately to mind).
> 
> Either way would work for me.
> 
> Thanks.
> 
> (*) I presume the WG would want to keep the wsa:To header. 8-)
> 
> Mark.
> --
> Mark Baker.  Ottawa, Ontario, CANADA.       http://www.markbaker.ca

Received on Friday, 31 March 2006 12:50:08 UTC