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.

Savas goes beyond the call of duty, and responds to two of my posts simultaneously. I’m glad he did, because the “uniform” question I asked came about as a result of my initial response to him. He writes;

However, doesn’t the consumer now need to understand the specification of the type that governs the returned document’s structure? Isn’t this similar? In fact, I think it’s worst because the service may return information to a consumer that the consumer did not understand. Hence, we allowed an interaction to take place for nothing.

I’d say that the capacity to receive data you don’t understand is highly underrated. 8-) What you might not understand now, you might understand later.

So, my view on this is pretty simple; stuff that changes shouldn’t be fixed in a design-time element like a service description. IMO, that includes the schema(s) that a service inputs and/or outputs. Which brings us to …

One of SOA’s principles, as described by Don Box, suggests that services will only interact with one another only when they have determined, based on policy assertions and metadata about the document structure of the information, that they can meaningfully exchange information.

Ok. But as I see it, until some advanced form of AI comes along, a service will only ever interact with other services that conform to the preconceptions hardcoded into it. A constrained interface (the uniform interface, in particular) shines when you keep this in mind, because it suggests that any service can exchange information with any other service. If Web services don’t do similarly, then they have necessarily forged islands of interoperability (where each island is comprised of all services that share the same preconceptions).

WS-I heralds breakthrough architectural style
Thursday April 1, 2004 6:00 am ET


San Jose, USA. -- The WS-I today announced the creation of the "NULL
architectural style", the next step in the evolution of large scale
distributed systems.  It is a generalization of so-called Service
Oriented Architecture ("SOA") styles, which have so far been used
primarily behind corporate firewalls.

The NULL architectural is characterized as having no architectural
constraints, providing the ultimate in flexibility for today's dynamic
enterprise.  "By removing all architectural constraints, we have built
the perfect base from which to develop dynamic, loosely coupled systems",
said Ben Dover, WS-I spokesperson.  "It seemed the next obvious step.
First, we improved upon the Web by disregarding its most important
constraints.  So clearly, disregarding the constraints of Web services
themselves must be an even better idea!".  He added, "As one can do no
better than to have no architectural constraints, this is quite
literally the ultimate in architectural styles!".

About the WS-I

Waste Services Incorporated is a 'Total Waste Management' company
providing a complete, integrated and professional range of waste
management services including waste collection, ... Erm, no, that's not
us, really.  We do profiles, not waste.  Yah, that's the ticket.

Answer me this; is it the objective of the Web services architecture to permit a document (e.g. a purchase order) to be submitted to any service for processing?

If so, then how is this different than having every service implement a common “process this document” (aka POST) operation? That’s what uniform means.

Savas says that iTunes is doing a proprietary version of Web services. I don’t think so. He writes;

If, however, they wanted to describe the structure of that information, how would they do it? They’d probably use XML Schema.

Yep, agreed there. I think RDF would be a better solution, but given they’re using plain old XML, XML Schema would be the way to go.

And if they wanted to describe the message exchange patterns, the contract for the interactions with the store (e.g., “when the XML document with the order information for a song comes, the response will be the XML document with the song”)?

Hold on. Why would they ever do that? Why would they want to artificially restrict the type of documents returned from an interaction? That would mean that if they wanted to insert a step between order submission and and song download, that they’d have to change the interface and its description? No thanks. I would prefer that the client determine what to do based on the type of the document that actually arrives. Let’s keep the perpetually-static stuff in the protocol, and let everything else happen dynamically.

And if they wanted their service to be integrated with other applications without having to read Apple specifications on how to include the information in HTTP requests and how to read HTTP responses?

I don’t follow. One need only look at the HTTP spec to determine how that’s done. SOAP buys you nothing in that case, AFAICT. It buys you other things (better extensibility, richer intermediary model, etc..), but none of those seem relevant to ITMS at present.

Via Mnot, Aaron’s reverse engineering ITMS.

So let me understand… ITMS is presenting an HTTP/URI based interface intended for use by automata, and not human-controlled browsers? How is such a thing possible?! THE WEB IS FOR HUMANS (isn’t it?)! Head .. about to … explode. 8-)

Steve responds to my response to his article.

One of Mark’s comments was about my discussion around the difficulties of using URIs to represent some types of endpoints such as message queues. I don’t disagree with Mark that you could devise a way to do it, but it’s just that there’s no good standardized way to do it. I mean, if worse came to worst, you could use a URI with the stringified OMG interoperable object reference format (“IOR:” followed by any number of hex digits), especially given that a single IOR can simultaneously represent any number of endpoints, regardless of the complexity of any individual endpoint being represented. But I suspect most people would not want to take that approach.

But there is a standardized way, which I recommended; the http URI. You don’t need any more standardization than that, as an http URI provides sufficient information to enable anybody to grab data from it via GET (aka, it enables the late binding of the identifier to data).

FWIW, I agree that the URI-construction mechanism has its problems, and I try to avoid it when I can, especially where queues are created frequently. I just mentioned it as another option.