Edwin writes;

Sean’s point is valid: unified interfaces are more scalable than typed objects. But the truth is that it is not enough. HTTP has 4 verbs: GET, PUT, DELETE, POST. MOM as 2 verbs: SEND and RECEIVE. Does it mean that integration is easy now. No! We have just move the complexity somewhere else. The patterns related to the design of integration applications are far more complex than simple state transfer.

Certainly, as there’s the issue of how one integrates that state once
its received (ala topic maps, and the
Semantic Web). But complexity hasn’t
been moved, it’s been reduced, because a very important problem –
how one gets and submits data between applications – has been solved (to be
clear, I mean solved by HTTP, not by Web services 8-).

I just ran into Tim Bray’s
“Sharecropper”
blog entry. Tim writes;

You’re not a sharecropper, especially not a sharecropper, if you’re building on the Web platform. If you can define your value-add as a series of interactions via a browser, or an interchange of XML messages, nobody can whip the land out from under you.

If you want to understand self-description, look no further than that last
sentence fragment, “nobody can whip the land out from under you”. What that
means is that the semantics of the message are grounded entirely in the realm
of public specifications. I
don’t happen to believe
that “XML messages” are necessarily very self-descriptive, and I’d expect Tim to
agree; I’m sure he was just over simplifying.

Werner thoughtfully
relays some of his experiences
in technology evangelism.

This is interesting, much appreciated, and respectfully received, but alas,
not completely relevant to my situation from my POV.

The Web has already won. I’m just out there letting people know that.
Many think that the Web needs Web services in order to enable
machine automation, but they are mistaken.

What would you do if you knew how to solve many problems within the
constraints of an existing, insanely succesful architecture? I think I’ve tried it all;
simple examples,
more complex examples,
comparisons, and
explanations
(I could dig up more).

Moreover, what would you do if you had studied many large scale systems,
and noticed that they all shared
one common constraint.
but that the “approach du jour”, which was being promoted as suitable for
large scale use, didn’t use it?

Werner writes;

I had a sort of knee-jerk reaction when Mark took this opportunity to once again show the world why REST is the way to build systems.

Actually, I didn’t, I was just drawing an analogy; I was showing how
transport becomes transfer when data is exposed to the application. I
wasn’t suggesting that because of this, that all transfer apps over RS-232
needed to be RESTful, though I believe that many (not all) can be. Again,
this is an example of the generality of the Web and REST being mistaken for
universality; how do I say that there exists a 70% solution for things you
might want to do over the Internet, without people thinking that I’m saying
that it’s a 100% solution?

I’m not going to respond to the points about evangelizing, because I don’t
feel that this is what I’m doing; technology evangelists primarily
attempt to encourage uptake of their technology for the purposes of
benefiting that technology. That’s not what I’m doing. I’m out there
promoting the Web because it’s vastly superior to the Web services
approach – so much so, that Web services will fail to see much use on
the Internet (i.e. they’ll fail).

Seth Ladd asks;

Not sure why the SemWeb needs a graph of POST data. Why not just POST a graph of RDF triples raw?

Sounds good, because RDF Forms is for doing the latter, not the former. The issues
that it tackles for that problem (at least for Container – Indexable is something
different) are; how an automata is directed to a data processor (via hypermedia using
rdf:type), and a declaration of the accepted media type(s) that can be processed.

I caught this “blog” entry
of Ray Lane’s via Google News today, and of course
the title caught my eye. But I’ve been caught by titles before, and the article normally
turns out to say, in effect, Yes, they are the answer.

So this was a nice surprise;

The software industry’s answer to all this is Web services. That’s the next big thing. It’s supposed to solve a lot of problems. When you talk to most of the large suppliers, they spill a bunch of acronyms and say all this will allow you to integrate. But it won’t; it just won’t.

So far so good. He goes on to talk about why he feels it won’t work …

There are standards, and certainly messaging and integration are easier, but we don’t know yet how to handle the semantic differences between industrial messages that are coming from suppliers to OEMs to whatever. XML, Sun ONE, Orion, Longhorn, on-demand computing, yada, yada, yada. There are a lot of solutions, a lot of hammers looking for the nail.

I disagree with the first sentence; what Web services are, does not
make messaging and integration easier (though SOAP arguably does, a little –
Web services as a whole make it significantly harder). The second part,
I completely agree with though; we don’t know how to solve those problems.
But we’re trying.

Werner comments
on RS-232/SOAP and transport vs. transfer;

But I do think Mark is pushing the limits by suggesting that the reads & writes on the rs232 registers are in reality similar to hidden REST-like HTTP GET & POST verbs.

Well, I was simply suggesting an analogue existed, not what it was.
But since he asks … 8-)

Though I fully understand that RS-232 is not, by definition, a
transfer protocol, many (most, I would say) uses of it were/are as a
transfer protocol. This is because the abstractions exposed by the
protocol are often made directly available to applications, rather than
being hidden from the application by other layers. This makes this
use of RS-232 more than just “move these bits to the other side”;
it makes them “submit this data to the application for processing”,
i.e. POST

Also, RS-232 has no notion of “GET”; you won’t find anything in the
spec that defines how to request data (not just “receive”, as
you would with a “read”).

Dave Winer writes;

These people seriously need to take a refresher course in what the Web is about and how important links are and stop screwing around with them.

So what’s this then?

Sigh, I wish I could churn out well written analogies like Sean does.
This time, it’s
RS-232 and HTTP.
Unfortunately, I don’t think this one will register with many Web
services folks for one simple reason (that I’ve
talked about before);
the more general the interface, the harder it is to distinguish transport
from transfer.

I expect that he’ll get feedback saying that SOAP is more like RS-232 than HTTP.

Maybe HTTP should have been called “DTP”, the Data Transfer Protocol.

Update; oops, well so much for that theory. The
first comment
I’ve seen on the article nailed it.

I don’t know why exactly – probably something to do with years of noodling
on Web architecture – but I seem to have a knack for sniffing out self-description
problems.

So while working on
RDF Forms (specifically the
implicit intent
section), I realized that RDF Schema
is not self-descriptive; by virtue of not defining its own media type, it does not
permit a message sender to declare whether the semantics of the message depends upon
RDF Schema being understood or not.

Issue submitted.

Joyce Park writes;

The fact that existing web services standards are widely perceived to be manipulated for private gain, never finished in a usable form, difficult to understand, and entirely failing to deliver interoperability — those would not be reasons for shallow adoption of course.

No, of course not. 8-)

Keep your eye on the ball.