Web Things, by Mark Baker

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.