When designing an architectural style from scratch, one always begins with an implicit style Roy Fielding termed the null style. While it is certainly possible to build software systems that conform to this style, it has the ignominious distinction that every system built with only it in mind, will literally be “good for nothing”; that such a system will possess no properties that would make it a good form of solution for any particular problem. It hopefully goes without saying that no amount of hype will save a null-style software system.

A few weeks ago, I asked a question of my weblog readers (note; my primary weblog is still down as I change ISPs - stay tuned) about whether they felt that it was possible to make a mistake when designing a software system that would guarantee its failure. I received two responses, both of which stated, no, it wasn’t possible to make such a mistake. I’ll describe here why I believe that to be incorrect.

Sometimes, an architectural property is an absolute necessity for a system to possess in large quantities for the environment in which it is to be used. As a rather trivial example, it should probably not come as a surprise to learn that a high degree of scalability is required of systems that operate on a large scale, for example with billions of components distributed across a network. Should a design mistake be made, either by neglecting to adopt a constraint which induces large degrees of scalability (and for which there exists no other constraint which can induce a similar degree of it), or by selecting a constraint which severely reduces scalability, systems conforming to such an architectural style will fail to scale, and therefore, as objectively as one can determine, be a failure. Again, no amount of hype will prevent this from happening.

As a more concrete example, let’s look at the visibility property. It is a property which all successful systems deployed on the Internet that I’m familiar with, exhibit in spades. The bulk of the visibility exhibited by each of these systems derives from their use of a coordination language, where each new software component added to the system uses the same coordination language as every other component. This permits intermediary components, such as firewalls, to understand the interactions as well as the sender and server components, and explains why those firewalls are able to do their job. Web services are not built with a coordination language, and their visibility is greatly reduced because of it, removing the ability of firewalls to do their job. Once again, no amount of hype will replace this lost visibility.

So while hype is almost always a positive force that can aid in acceleratating adoption, it is not, unfortunately, an architectural constraint, and therefore cannot induce any useful architectural properties. It is not a sufficient condition for success.

Hopefully this explains the two main reasons why I’ve taken such a strong position against the current approach to Web services. First, bad design cannot be masked. And second, that Web services’ lack of use of a coordination language is an example of bad design.

What say ye?