Web Things, by Mark Baker

Robert sent me a great email that deserves to be on the Web. He doesn’t have a weblog, but gave me permission to post it here.

Might be of interest to you, if you haven't seen it already. Came across
this justification for constrained interfaces and unified namespaces...it
ties the argument to economics and the "Wealth of Nations" (Adam Smith).

Reiser File System v4 ( http://www.namesys.com/v4/v4.html )

"The expressive power of an information system is proportional not to the
number of objects that get implemented for it, but instead is proportional
to the number of possible effective interactions between objects in it.
(Reiser's Law Of Information Economics)

This is similar to Adam Smith's observation that the wealth of nations is
determined not by the number of their inhabitants, but by how well connected
they are to each other. He traced the development of civilization throughout
history, and found a consistent correlation between connectivity via roads
and waterways, and wealth. He also found a correlation between
specialization and wealth, and suggested that greater trade connectivity
makes greater specialization economically viable.

You can think of namespaces as forming the roads and waterways that connect
the components of an operating system. The cost of these connecting
namespaces is influenced by the number of interfaces that they must know how
to connect to. That cost is, if they are not clever to avoid it, N times N,
where N is the number of interfaces, since they must write code that knows
how to connect every kind to every kind.

One very important way to reduce the cost of fully connective namespaces is
to teach all the objects how to use the same interface, so that the
namespace can connect them without adding any code to the namespace. Very
commonly, objects with different interfaces are segregated into different
namespaces.

If you have two namespaces, one with N objects, and another with M objects,
the expressive power of the objects they connect is proportional to (N times
N) plus (M times M), which is less than (N plus M) times (N plus M). Try it
on a calculator for some arbitrary N and M. Usually the cost of inventing
the namespaces is much less than the cost of the users creating all the
objects. This is what makes namespaces so exciting to work with: you can
have an enormous impact on the productivity of the whole system just by
being a bit fanatical in insisting on simplicity and consistency in a few
areas."

More REST promotion from the master storyteller. “[…] I fear the most common noise in integration will continue to be the sound of crisp dollar bills heading towards the source of a strong flushing sound.” – classic
(link) [del.icio.us/distobj]

Cool. Of course, my company, Idokorro (Planetfred at the time), proposed this to the UDDI Advisory Group over three years ago, only to have it rejected because it wasn’t “protocol independent” (sigh). I hate to say, “I told you so” … erm, no I don’t.
(link) [del.icio.us/distobj]

I forgot about this argument, held by some, including Stefan;

Mark follows up with asking what a successful response to a message in “contract mode” would look like, and that an HTTP 200 response code would not have semantic meaning with regards to the message. Right, it doesn’t – that’s why the response code doesn’t matter as much as the response’s content itself, and why we have things such as WS-ReliableMessaging.

The issue with not using a response code is that it’s impossible to distinguish between success and failure in some cases. Consider a portType/interface/operation of “getLastFault”, whose intend semantics is, as it sounds, to return the last fault sent by this service; how do you know if the fault is a result of trying to find out what the last fault was (which is a real fault), or if that really was the last fault (which isn’t a real fault)? That’s why message metadata needs to be orthogonal to content.

But anyhow, the 200 example was just illustrative of the point that the contract changes depending upon which style of WSDL you’re using. So unless there’s some bit in the message which says which interpretation is intended, then the semantics of that interaction is ambiguous. And even without that bit, the contract itself is ambiguous.