Web Things, by Mark Baker

Google Fight speaks on the REST vs SOA(P) debate. We now know, unequivocally, that people prefer napping to bathing. 8-)
(link) [del.icio.us/distobj]

“In 10 years, any physical object should be able to tag itself in a way that links it to relevant information and functions in cyberspace”. 8-)
(link) [del.icio.us/distobj]

Here’s a few quotes from a presentation I found. I’ve replaced the name of the technology with “____” below, and it’s the same technology in each quote. What is it?

A key concept of the data web is this idea that the response to any ____ request will either contain data or another address at which to ask for that data… If you get back data then you are done, if you get back another address you make a request of that address, you will get back either data or …

…

Using ____ we can consume and aggregate distributed data without having to make new copies and without complex multi-protocol clients.

…

An ____ data store is often depicted as a graph.

Here’s the offending presentation.

And here’s some of my past comments on this same technology. As I said there, those who don’t understand the Web, are doomed to reinvent it.

(link) [del.icio.us/distobj]

Heh, cool.
(link) [del.icio.us/distobj]

If contracts are so important, why are there so many of them, and why are their realizations auto-generated and disposable rather than mature and commodity?

I’ve talked about both the pluses and minuses of Amazon‘s approach to Web Services for some time now. Recently, I’ve heard that they’re in the process of greatly expanding those services, which is great. But I think that before they go too far with that, they should really dig a little deeper to learn why it is exactly that their “RESTful” data retrieval services are getting the uptake they are.

I don’t think it’s controversial to claim that Amazon see the REST vs Web services debate as primarily about encodings; either a message is encoded as a SOAP envelope, or it’s encoded as a URI, but in both cases the abstract message – the information being conveyed – is identical. I completely disagree, of course, and believe that there’s a very large architectural difference between those two approaches; that in http URI form, the URI isn’t the message, and instead, the surrounding HTTP message which encapsulates that URI becomes the real message, while the URI itself is treated as an opaque bag-o-bits. Through this encapsulation, GET becomes the operation.

What I just described I refer to as “accidentally RESTful”, and it’s sur– prisingly common. And while, for the simple data retrieval case, it is RESTful, and a significant improvement over vanilla SOA, you’ll find that as you add support for state-changing actions and just generally evolve that application over time, you’re going to run into many of the same problems you’d run into doing SOA.

Fair warning!

Update; oh, I suppose this is, in part, a response to something Dare said a couple of weeks back; those APIs he lists ARE RESTful, at least with respect to using the uniform interface.

John McDowall on simplicity;

Making simplicity a goal in integration is key to success – it can be an aspirational goal i.e. integration may never but point and click but unless the goal is simplicity rather than solving many imaginary problems then the possibility to asymptotically approach it will never happen. So setting simplicity of solution is always the right goal.

Bingo. Now, what architectural constraints can we adopt to induce simplicity?

Anyone, anyone? 8-)

Drummond mints a corollary to one of Kim Cameron’s Laws of Identity;

The identifiers in a universal identifier metasystem MUST only reveal information identifying a user with the user’s consent.

… and follows it up with this bold claim;

So half the Web breaks this corollary before we’re even out of the starting gate. But it gets worse. Look at one of the current bulwarks of online identification: DNS. A standard requirement for most DNS name registries is accurate, current contact data for the registrant that is published publicly as “Whois” data. Although many registrars now offer proxy registration services to preserve registrant privacy and prevent spam, there’s no escaping that a major component of our current Internet identifier infrastructure breaks the First Corollary squarely in two.

Hmm, how exactly does Web/Internet/DNS breaks that corollary? I can’t see it. Is it because of DNS (and if so, why the “it gets worse” comment)? DNS does certainly require a small amount of information be made available, and though I’m hardly a historian, the little I do know of the history of this data suggests that it represents the minimum amount that a mature industry – which has had to balance the needs of domain owners (anonymity) with those of the public at large (accountability) over many years – has reached concensus on requiring. So I doubt that any competing centralized solution would be able to reach widespread deployment without, in the steady state, providing a similar amount of info about registrants.

Also, who says that there’s a direct correspondence between a DNS name and the person who uses the email address? I don’t own gmail.com, nor yahoo.com, yet have email addresses at both of those domains. Google and Yahoo, in offering an email service, provide a degree of anonymity via proxy; if you want to learn more about me there, you have to go through them, and I’m not required to publish any info about myself there. Hushmail‘s probably the extreme case here, as they seem to exist to provide as-anonymous-as-possible email services.

As you’d expect from a chair of the XRI TC, he then claims that XRIs don’t have this problem;

So can XRIs fix this problem? Yes. The first principle of XRI architecture is that XRIs are abstract – the association between an XRI and the real-world resource it represents is entirely under the control of its XRI authority (the person or organization registering the XRI, at any level of delegation). So nothing in an XRI need reveal anything about the authority’s identity or messaging address.

… which, as I’ve shown, is also the case with even DNS-bound URIs.

Paul Hoffman likes this anti-smoking ad.

I dunno, it doesn’t seem like it would be too effective to me. Sure, it’s shocking, but why should shocking stop people smoking?

That said, it seems vastly superior to the hopeless Ontario Government campaign titled – get this – Stupid (with accompanying sucky tv ads). Uh huh. Disrespecting your target audience; smooth move.

What about an ad showing a bunch of old white guys sitting in a boardroom, schemeing about how to get teens hooked?