Nick links to
DaveO’s “leaky abstraction” bit
from a while back, and comments;
Good discussion (as usual) of design issues (incl design conflicts) between SOAP and WSDL MEPs. Also points out that apparently SOAP envelopes don’t contain MEP metadata, so SOAP intermediaries cannot tell be examining a SOAP envelope which MEP it is part of! This seems like a huge design oversight and proof of how little experience we have with protocols with first-class treatment of intermediaries. Perhaps SOAP and WSDL have bitten off more than the critcal mass of programmers can chew on.
It’s a feature, not a bug! I can’t find it, but I remember when MEPs were introduced
back in the early days of XMLP, that I expressed concern that MEP information would find
its way into the message.
The problem is that application protocols determine the “MEP”, not the SOAP envelope.
For example, if the transfer protocol is HTTP then you know you’re in the middle of a
request-response interaction because it’s HTTP. Want to use HTTP with a new
MEP that enables, say, out-of-order responses? Tough! HTTP
doesn’t support it.
Well, I suppose you could define an
HTTP extension
to support it, but you still don’t need anything in the SOAP envelope.
It’s just another example of how
protocol independence
really is the root of all evil in Web services.
As for Nick’s suggestion that we lack experience with protocols with first-class treatment
of intermediaries, I disagree; as an industry, we have a huge amount of experience
with them, in particular with SMTP and HTTP, both of which have been deployed for ages, and
at massive scale. Unfortunately, the overlap between those with that knowledge and experience,
and advocates of WS-*, is essentially the empty set. 8-(
“The traditional distributed computing guys, like myself, have difficulty adjusting to the difference that XML makes”. Amen to that.
(
link) [
del.icio.us/distobj]
“you can pretend the browser is simply a proxy which has timed out”. Smart.
(
link) [
del.icio.us/distobj]
“Which shows why you shouldnt try and put too much intelligence in the XSD, because you may turn out to know less than you think”. My biggest complaint with schemas, in a nutshell. That’s why I don’t use them. At all.
(
link) [
del.icio.us/distobj]
Speaking
of
tuple space based systems…
Google Base is a place where you can easily submit all types of online and offline content that we’ll host and make searchable online.
Contrast that with this (
snippet);
The tuples have just a few key properties: […] (2) They are persistent, remaining available long after the application that created them has gone on to other tasks. (3) They do not have names or other external identifiers and are stored in no particular order. Instead, they are located by querying their content…
Of course, nothing says they can’t also have identifiers.
Now, if Google Base would just support RDF – which is as sloppily
extensible as
Adam requires
– we’d even get the “tuple”
(read; triple) part of tuple spaces. Or, failing that, at least
microformats.
I’ll be there. Drop me a line if you want to get together.
(
link) [
del.icio.us/distobj]
I found this example of the old Google XML search API at work, before the SOAP API. View the source. Bring it back!
(
link) [
del.icio.us/distobj]
For the compound-document inclined …
(
link) [
del.icio.us/distobj]
The new
Yahoo Maps API
described with
RDF Forms;
<rf:Indexable xmlns:rf="http://www.markbaker.ca/2003/rdfforms/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
rdf:about="http://api.local.yahoo.com/MapsService/V1/geocode">
<rf:indexedBy>
<rf:IndexParam rf:shortName="appid">
<rdf:predicate rdf:resource="http://developer.yahoo.net/faq/index.html#appid"/>
</rf:IndexParam>
</rf:indexedBy>
<rf:indexedBy>
<rf:IndexParam rf:shortName="street">
<rdf:predicate rdf:resource="http://en.wikipedia.org/wiki/Street"/>
</rf:IndexParam>
</rf:indexedBy>
<rf:indexedBy>
<rf:IndexParam rf:shortName="city">
<rdf:predicate rdf:resource="http://en.wikipedia.org/wiki/City"/>
</rf:IndexParam>
</rf:indexedBy>
<rf:indexedBy>
<rf:IndexParam rf:shortName="state">
<rdf:predicate rdf:resource="http://en.wikipedia.org/wiki/State_codes"/>
</rf:IndexParam>
</rf:indexedBy>
<rf:indexedBy>
<rf:IndexParam rf:shortName="zip">
<rdf:predicate rdf:resource="http://en.wikipedia.org/wiki/ZIP_Code"/>
</rf:IndexParam>
</rf:indexedBy>
<rf:indexedBy>
<rf:IndexParam rf:shortName="location">
<rdf:predicate rdf:resource="http://en.wikipedia.org/wiki/Location_%28geography%29"/>
</rf:IndexParam>
</rf:indexedBy>
</rf:Indexable>
Ideally, such a form would be returned on a GET to
http://api.local.yahoo.com/MapsService/V1/geocoding
when application/rdf+xml is declared in the Accept header as the
preferred representation format.
I grounded most of the parameters in
Wikipedia URI space,
but Yahoo might want
to be more precise and define their own terms where Wikipedia isn’t suitable.
Also, Wikipedia doesn’t yet do RDF, so you can’t get any of the
(eventual) goodness that comes from
WebClosure. Of course,
the form is useful without that.
Tony hits the
nail on the head
What is SOAP? It’s an HTTP POST containing XML, and an HTTP response containing XML. You can make an echo server by – here it is – simply serving a static XML file. That’s it. Just put an XML file on your http server and you’re done.
Indeed.
Alternately, if you feel the need, you can POST the content to the echo service.
If you want to wrap it in SOAP too, even that’d be fine. Just watch that immediate
child of soapenv:Body, because what you
ABSOLUTELY do not need, is an
“echo
operation“. You
just need the content to be echoed, and the address of the service;
document in, document out.
That’s document exchange. That’s REST.
Can we get some real work done now, please?