Why bad design always trumps hype; the fatal flaw of Web services

by Mark Baker

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?


2003-04-02 11:16:23
I thought SOAP was billed as "firewall invisible" from the get-go. It could run over port 80 and be mostly indistinguisable from regular web traffic at the firewall level.

This was big bonus I thought. Developers could do interesting (and probably dangerous) without the networks security folks being able to shut you down.


With a little apache and proxy configuring, it would be possible to serve regular httpd requests and a soap web service on the same website, port, and url.

heh heh heh.

2003-04-02 12:15:14
Yep, you're right; it was, and continues to be, billed that way. The problem is that this is a bug, not a feature. Firewalls exist for a reason, and are backed by big corporate IT dollars to do a job. Any attempt to bypass that job is doomed in the medium/long term.

What needs to be done is to try to accomplish the task while being friendly with the firewall. That means, at least for the Web, using HTTP methods to get stuff done, not other kinds of methods that the firewalls don't know about (e.g. all those defined in WSDL documents).

2003-04-02 13:58:21
I agree with your general point, but...
What bothers me is the equation of the hype about web services with a particular implementation of web services (i.e. the SOAP stack). What I find exciting is the IDEA of web services -- new services built by loose coordination of remote data resources.

Here are some examples of "web services" that are not SOAP based:

- CDDB lookup. (Any CD Burner app uses these services to look up song authors and titles.)

- Internet ad serving from DoubleClick and AdForce. Just put the right tag in your web page, and some one else's server automagically stuffs in the appropriate ads, fetched off yet someone else's server.

- Amazon offers both SOAP and REST-based versions of their web services interface. Reportedly, 85% of the usage is of the simple REST interface. POST to a given URL, get back XML.

2003-04-03 10:35:02
I agree with your general point, but...
Hi Tim,

For better of worse, the term "Web services" means the SOAP stack to most people. I wish it were otherwise, but it is not.

I understand the position of those who want to encompass many different architectural styles under the "Web services" umbrella, and respect what they're trying to accomplish by doing so. But it only serves to confuse developers, as "Building a Web service" becomes meaningless, since it says nothing about which architectural style is being used, and it's the architectural style that determines the properties of the solution.

2003-04-03 11:52:55
Hmmm, How about the firewall guys build smarter firewalls instead of restricting the business needs of the entire industry. The firewall could consult some policy service that understands what business agreements allow what web service operations from who. There are technical solutions to this.. oh wait, I think there are some firewall guys who are already working on this... are your eyes shaded by your past jobs?

Web services hype exists because they solve set of business problems. They are a disruptive technology and will cause ripple effects of change through existing products and architectures. Get over it.

2003-04-03 14:49:02
soft soaped
Not everybody thinks of the SOAP stack when they talk about web services. I was just reviewing my vision statements:


and when I drafted these almost a year ago I was referring to web services as replacing shrink wrapped products over the long term. This was appropriate before the term "web services" got hijacked by the proprietary players behind the WS-I.

The idea of transmitting portable data as XML over HTTP has amazing possibilities still barely explored. SOAP is just one spec, a weak one, and now it's fragmenting. Perhaps y'all got snake charmed, but I think it's high time to shake it off and generate some fresh thinking.

Oh, and for the record...


was me, too. Perhaps now I have greater impact posting anonymously. Regardless I've got no time to waste being ignored, because it's time to get back to serious coding. Bye O'Reilly, and thanks. Of course, you're welcome.

2003-04-04 01:11:59
Well, yes, but why port 80?

You're doing "local optimisation" - trying to solve a narrow problem yourself- instead of cooperating to find a globally optimal solution.

For most services, the HTTP vocabulary of GET (read-only), PUT (idempotent write), and POST (non-idempotent update) is quite sufficient to express the permission classes, and http.config files and firewalls already have perfectly adequate tools for setting the permissions.

Otherwise we'll end up with an implementation of TCP over HTTP and stuff the whole internet through port 80. Then the firewalls will dig deeper and it'll happen again ...


2003-04-04 08:48:47
It's not a matter of "smarter" firewalls. They'd have to be very (VERY!) *busy*, because they'd have to be constantly upgraded to understand new WSDL documents as they're created. It's an integration issue; Web services integration is O(NlogN) in practice, while Web integration is O(N). This is an inescapable truth. Note that no system with integration complexity greater than O(N) has ever succeed on the Internet, based on my investigations. Think about it.

It's the Web itself which will continue to "cause ripple effects of change".

Mark Baker (I'm logged in, I swear!)

2003-04-04 08:56:54
soft soaped
Very nice list!