Web Things, by Mark Baker

A good one from Bill Grosso on what the year 2009 will bring, including a couple of bang-on comments about the Web/Web-arch
(link) [Mark Baker’s Bookmarks]

Adam writes;

The original impetus behind XML, at least as far as I was concerned back in 1996, was a way to exchange data between programs so that a program could become a service for another program. I saw this as a very simple idea. Send me a message of type A and I’ll agree to send back messages of types B, C, or D depending on your A. If the message is a simle query, send it as a URL with a query string. In the services world, this has become XML over HTTP much more than so called “web services” with their huge and complex panoply of SOAP specs and standards.

Wow! I actually had a weblog entry written, that questioned whether Adam’s transition away from a Web services company, and towards a Web company, might have had something to do with him “seeing the light” regarding REST vs. SOA. I decided not to post it because it was pure conjecture. But it seems my gut feel was partly right. However, he also adds;

Why? Because it is easy and quick.

Which is true, but not a very satisfying answer I’d say. Why is it easy and quick? Anyhow, I’m sure Adam will have lots of time to mull that question over in his work at Google. I look forward to seeing what cool stuff he comes up with there.

“It’s pretty clear to me that the RDF data model is simpler”. See, there is hope for BEA.
(link) [Mark Baker’s Bookmarks]

Sean discovers WS-MessageDelivery which triggers him to display a level of frustration that I didn’t expect to see, but that I’m happy about. We need more integration gurus to raise their hands and ask “Hello, what the $%@! are you people doing?!”, in the hope that those building this architecture may stop to take the time to think about what they’ve created and give it the principled architectural examination it requires. Sean writes;

You started at the wrong end of the pipe. SOAP always was and always will be and API-centric worldview. That is not the future. That is the past. Re-implemented badly. Sometimes I wonder. I really do.

I disagree that SOAP requires an API-centric worldview – I battled against enormous odds to ensure SOAP 1.2 didn’t – but I certainly agree that this is how Web services proponents and specs are using the SOAP specs.

On the other hand, to their credit, Web services promoters are trying to distance themselves from APIs. The problem is that they think they’ve done this with “document oriented SOAP” by removing the operation from the message. Unfortunately though, in their architecture, the operation is still in effect, it’s just hidden from the message which actually makes things worse than RPC (in case you wondered if that was possible!).

What Web services need is an architecture based purely on document exchange, not some RPC/document bastard. Luckily, one is readily available.

Good stuff from Lucas. IMO, a URI would be better than a bit, but I’d much prefer an RDF document to the URI, so that all that information could be in the stream itself.
(link) [Mark Baker’s Bookmarks]

First Bosworth, now Dietzen. Mnot for CTO!!
(link) [Mark Baker’s Bookmarks]

“Make the operations of your web service interface as granular as possible.”. Unfortunately, the quality of the advice given in the rest of the article isn’t quite so good.
(link) [Mark Baker’s Bookmarks]

A very cool and intuitive Python API for HTTP by Mark.

On a related note, being a command-line kinda guy, I’ve long lusted for a “Web shell” which allows me to do this (but lacked the time or skill necessary to build my own);

$ cat  http://example.org/some-uri # PUT
$ cat foo >> http://example.org/some-uri # POST
$ rm http://example.org/some-uri # DELETE

Idea courtesy Jeff Bone

Phew, that took longer than expected! Congratulations to Roy and the adhoc “URI WG”.

Norm continues the slagging of the XML serialization of RDF, RDF/XML.

So, since somebody’s gotta do it, I’ll put my neck on the line by saying that I really don’t have any big problems with RDF/XML.

For me, RDF/XML works because it makes the simple things simple. Consider the following document;

<Person xmlns="http://example.org/foofoo/">
  <name>Mark Smith</name>
  <age>55</age>
</Person>

IMO, if the serialization can’t support extracting the same triples as a human would intuitively expect to be there, then it’s broken, or at least not suitable for hand-authoring (which I’ve had no problems doing).

Yes, that’s simple, but I’d say it’s about 70% of what I do with RDF, and I’d expect that for many people, it’s probably at least 50% of what they do with it.

And yes, striping is a nuisance some times. And lists and collections are annoying. And don’t get me started on reification. But the simple stuff is simple.

Actually, I should come clean and say that despite my claims above about not having any problems with RDF/XML, I have had some. But you know what? The problems I’ve had are always with XML. XML is just a really sucky syntax for lots of network-centric things I do, thanks to its seemed-like-a-good-idea-at-the-time deterministic failure model. This is what requires you (unless you want to institute transaction semantics between your app and parser, uh huh) not to do any application processing until you’ve received the final “/>”; because you never know, it might not arrive, and it’s only then that you realize “Oopsie!”, that wasn’t XML after all. Streaming? By definition, impossible. Latency-sensitive apps? Forget about it!

I’m overstating the case, of course. I use XML, a lot. It’s the default syntax that my last project used on the wide open Internet due to its pervasive recognition and support. We also used it as the default output format for our embedded systems, since producing it is cheap. But for embedded consumption, and between instances of our own software, we use Turtle.