RE: SOAP & Web arch

Mark,
 
I have to disagree with you on this point. As to the exact part of Web architecture we are discussing I think you are referring to the principle that first class entities must be identified by URIs. 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. 
 
HTTP is actually broken in this regard: HTTP Proxies are part of the HTTP processing model but are not first class entities in that they do not have a URI. The result of this has caused us many problems in lots of situations such as determining which HTTP server along the path inserted which HTTP header fields. Not to mention that it is impossible to determine who generated an HTTP fault along an HTTP message path. 
 
The SOAP extensibility model was designed as a superset of the HTTP model. If I recall correctly you will actually not find anything in the SOAP spec that refers to the scenario you mention but as always, when dealing with supersets, one has to be careful with the mapping (note that the references you provide are not part of the HTTP binding). However, this doesn't mean that SOAP is breaking the Web principle above. In fact I would argue that it captures it in a consistent manner which HTTP doesn't. This is goodness; this means we learned something from HTTP.
 
While it is certainly true that SOAP can be used in many ways, this is part of the game when designing for extensibility and I won't disagree that many of the uses have little to do with Web architecture. However, I am in complete agreement with Noah that it is possible to use SOAP in a manner entirely consistent with Web architecture.
 
As to whether XML is a useful foundation for a protocol, I would simply state that it is not possible to have a structured extensibility model without a structured language for expressing it. XML certainly has its downsides but is not unique in this way and if used sensibly is not a hindrance. What I think may confuse matters is to look at SOAP and HTTP as equals. While the SOAP extensibility model is actually very clean and semantically a superset of HTTP this does not mean that SOAP is a useful replacement for HTTP in terms of actual protocol model. However, when used responsibly it fills a gab that HTTP doesn't fill in terms of functionality.
 
Thanks,
 
Henrik

________________________________

From: www-tag-request@w3.org on behalf of Mark Baker
Sent: Tue 28-Mar-06 7:16
To: noah_mendelsohn@us.ibm.com
Cc: Rice, Ed (ProCurve); Roy T. Fielding; www-tag@w3.org
Subject: SOAP & Web arch




Noah,

On 3/28/06, noah_mendelsohn@us.ibm.com <noah_mendelsohn@us.ibm.com> wrote:
> I believe it is possible to use SOAP in a
> manner that's perfectly consistent with Web architecture.

That's not the case unfortunately, as it has at least one major flaw
(the use of XML being another, as Roy mentioned).  There's an
ambiguity in SOAP 1.2 that's at the root of the problem behind
endPointRefs-47; that the ImmediateDestination property is defined as
the means for addressing both the next HTTP hop, as well as the
ultimate recipient of the message;

"An identifier (URI) that denotes the responding SOAP node"
 -- http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#tabreqcon

"The identifier of the immediate destination of an outbound message."
 -- http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#tabreqresprops2

Implementations have, from what I've seen, unanimously opted for the
second interpretation which, unfortunately, is incompatible with Web
architecture.  This is because ImmediateDestination is bound to the
HTTP Request-URI in the HTTP binding, and the HTTP Request-URI is
understood, per the HTTP spec as well as deployed server components,
to identify the ultimate recipient.

I do agree that Roy probably overstated the case though, at least with
respect to the spec itself (both 1.1 and 1.2).  But of the SOAP
implementations I've seen, *none* of them are setup to use SOAP in a
manner consistent with Web architecture, so I think his position is a
reasonable one.

Mark.
--
Mark Baker.  Ottawa, Ontario, CANADA.       http://www.markbaker.ca

Received on Wednesday, 29 March 2006 08:56:27 UTC