RE: SOAP & Web arch

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. 

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

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>>
Cheers,
Dave

> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf
Of
> Mark Baker
> Sent: Thursday, March 30, 2006 7:58 AM
> To: noah_mendelsohn@us.ibm.com
> Cc: www-tag@w3.org
> Subject: Re: SOAP & Web arch
> 
> 
> On 3/30/06, noah_mendelsohn@us.ibm.com <noah_mendelsohn@us.ibm.com>
wrote:
> > Mark Baker writes:
> >
> > > So while the ambiguity I pointed out is a problem with the spec
> > > because it yields work which is incompatible with Web arch - as
> > > demonstrated by the WS-Addressing SOAP binding's failure to
populate
> > > the value of the ImmediateDestination property (presumably due to
the
> > > WG assuming that ImmediateDestination never identifies the
ultimate
> > > recipient, per that ambiguity) - I agree that there's at least one
Web
> > > architecture-friendly use of the spec.
> >
> > Mark, would it them be fair to say that your concern is primarily
with
> WSA
> > as opposed to SOAP?  No doubt SOAP can be used in non-RESTful ways,
but
> so
> > can HTTP.  For example, if I choose to make up my own non-URI
> > identification scheme and use it in representations sent over HTTP,
the
> > protocol can't stop me.  BTW: in saying this, I'm not offering an
> opinion
> > as to whether WSA is indeed misusing Web Architecture, as I'm still
> trying
> > to figure that out.  I'm merely pointing out that if there's a
problem,
> it
> > looks to me like it's WSA not SOAP that's the primary concern.  Do
you
> > agree?
> 
> Yes, I do.
> 
> And BTW, that description above about the WS-Addressing SOAP binding
> not populating the SOAP/HTTP ImmediateDestination property, is
> probably as succinct a description of the endPointRefs-47 issue as
> I've offered.
> 
> Mark.
> --
> Mark Baker.  Ottawa, Ontario, CANADA.       http://www.markbaker.ca

Received on Thursday, 30 March 2006 18:48:02 UTC