RE: SOAP & Web arch


Just looking at SOAP 1.2, the references you mentioned yesterday are for
the generic SOAP request/response MEP which by itself isn't directly
tied to HTTP. 

The SOAP 1.2 HTTP binding states that the RequestURI is the value of the
URI carried in the property of the
message exchange context. [1]

There is no reason why the immediate destination and the ultimate
destination can't be the same and in case of the HTTP binding the two
will collapse to always be the same. As you state, this is required in
order not to break HTTP semantics for indicating the ultimate
destination of the message. As such I don't think there is an
inconsistency in the SOAP 1.2 spec. It does mean, however, that one has
to be careful when using the SOAP req/res MEP in a context that does not
support the full SOAP semantics.



> -----Original Message-----
> From: [] On Behalf
> Of Mark Baker
> Sent: Wednesday, March 29, 2006 07:51
> To: Henrik Frystyk Nielsen
> Cc:
> Subject: Re: SOAP & Web arch
> Hey Henrik,
> On 3/29/06, Henrik Frystyk Nielsen <> wrote:
> > Mark,
> >
> > I have to disagree with you on this point. As to the exact part of
> architecture we are discussing I think you are referring to the
> principle that first class entities must be identified by URIs.
> Actually, no, my concern was that the ultimate recipient of the
> message wasn't identified by the value of the Request-URI.
> > This is exactly the purpose of the SOAP intermediary model. As such
> the SOAP intermediary model exactly fits this Web principle: SOAP
> headers can be addressed to named intermediary roles and faults are
> identified by the issuing node.
> If that's all that was going on here, I would agree, as I see definite
> value in being able to address (indirectly) intermediaries.  But SOAP
> headers - wsa:To in particular - are not being used to address
> intermediaries, they're being used to address the ultimate recipient
> of the message.  And, as I discovered after some investigation, and
> much to my embarassment (since I should have caught it while a member
> of the XMLP WG) this was in part due to an ambiguity in the SOAP 1.2
> spec itself.  See my previous message for the details.
> FWIW, I do agree that SOAP 1.1 can be used in a manner completely
> consistent with Web architecture.  And were it not for this problem, I
> would agree that SOAP 1.2 could be too ... and in fact I said so many
> times, before I discovered this problem.
> Cheers,
> Mark.
> --
> Mark Baker.  Ottawa, Ontario, CANADA.

Received on Wednesday, 29 March 2006 17:42:48 UTC