Tag Archives: standards

Snake oil on the Web

Jorgen tries to convince us that Web 2.0 Needs WS-*. But he’s going to have do a lot better than arguments like this;

And, as if to underscore why I don’t see the REST / POX / AJAX “religion” achieving too much traction among enterprises, try explaining the phrase “The Web is All About Relinquishing Control” to any corporate security manager!

Well, if Jorgen had read what Alex was saying about relinquishing control, he might not think that such an insurmountable task;

This is possible because no one owns the web, and consequently no one can control it. The web is everyone’s property, and everyone is welcome to join in. It’s the world of sharing. The need for control has been relinquished, and it is left to the participants to sort their discrepancies out. The web as a medium and as a technology is not going to offer any assistance in that regard.

In other words, relinquishing control is largely about adopting public standards in lieu of pursuing proprietary interests, in particular the public Web standards that make inter-agency document-oriented integration (relatively) simple to achieve. If you are responsible for securing an Intranet, it should be your first and primary consideration to trust messages which are based on publicly vetted agreements, like most Web messages, and similarly, to distrust those messages whose complete semantics are not publicly vetted, like most SOAP messages.

Standards as axioms

An important, nay, foundational part of my mental model for how Internet scale systems work (and many other things, in fact), is that I view standards as axioms.

In linear algebra, there’s the concept of span, which is, effectively, a function that takes a set of vectors as input, and yields the vector space spanned by those vectors; the set of all reachable points. Also, for any given vector space you can find a set of axioms – a minimal set of vectors which are linearly independent of each other (orthogonal), but still span the space (note; I use “axioms” here to refer to a normalized set of basis vectors).

So given, say, HTTP and URIs as axioms (because they’re independent), I can picture the space reachable using those axioms, which is the set of all tasks that can be coordinated without any additional (beyond the axioms) a priori agreement; in this case, the ability to exchange data between untrusted parties over the Internet. I can also easily add other axioms to the fold and envision how the space expands, so I can understand what adding the new axiom buys me. For example, I can understand what adding RDF to the Web gives me.

More interestingly (though far more difficult – entropy sucks), I can work backwards by imagining how I want the space to look, then figure out what axiom – what new pervasively deployed standard – would give me the desired result.

As mentioned, I try to evaluate many things this way, and at least where I know enough to be able to (even roughly) identify the axioms. It’s why Web services first set off my bunk-o-meter, because treating HTTP as a transport protocol is akin to replacing my HTTP axiom with a TCP axiom, which severely shrinks the set of possible things that can be coordinated … to the empty set, in fact. Oops!

See also; mu, the Stack, Alexander, software architecture.

Uniform Interface, take 12

Greg Reinacker responds to the earlier discussion Jon Udell and I were having about uniform interfaces. The emphasis of his response is on my generalization post to www-ws-arch, in particular the part where I generalized from getStockQuote() to getQuote(). He may very well have a point that this step is pointless, I don’t know. But it was just an example of a step; perhaps a better example could be found. The main point of the post was the first step and the last; from the unparameterized, good-for-retrieving-one-thing-only method, to the good-for-any-safe-retrieval method.

Then, as I responded to Jon, the value of doing that is because deploying new interfaces is extremely expensive. If you’ve got an interface that can do what you need, then you’re better off using it.

Greg did have this to say in his conclusion, which I’d like to comment on;

You can retrieve anything the same way, but you can’t process it without knowing more specifically what it is.

I can’t emphasize enough how important this point is. Being able to retrieve anything is a big win. Processing it is indeed an issue, and a non-trivial one (as I just alluded to), but with Web services, you’ve got both the problem of being able to get the data and the problem of knowing how to process it. The Web solves the first problem, and that’s just with the GET method!