Category: Architecture & Design

Martin LaMonica wrote an interesting piece in Cnet lamenting the lack of “simplicity” in web services today. According to the article “Tim Bray, co-inventor of XML and director of Web technologies at Sun Microsystems, said recently that Web services standards have become ‘bloated, opaque and insanely complex.'”. I think Bray is being far too kind.

One the the criticisms we had with the Unix operating system kernel (BSD or System V – it didn’t matter which) while creating 386BSD was the continual problem of managing a “bloated kernel” into which everyone wanted to throw their special cool thing whether it belonged there or not. When we introduced modularity in 386BSD Release 1.0 however, the reduction in complexity was not easily visualized by traditional kernel programmers used to a monolithic design, and also relegating them to a piece of the pie instead of the entire pie seemed to a few more vocal critics as “demeaning”. Web services is facing the same bias, only this time from companies anxious to have their particular widget inscribed in the annals of orthodoxy even if they are so odd that they actually belong as a special case module.

So where’s the simplicity in web services? We’ll get it when we get out of low-level design and understand the architecture better (see William F. Jolitz’s article Web Services and DataCenter Environments in the April 2003 edition of Dr. Dobbs Journal article for more information). The key is architecture in design first. This is the only way you get reliability, scalability, and security from the get-go.

Unlike kernel design, web services don’t even have an established user base yet, while people have made use of ad hoc Internet solutions using databases, scripts, and HTML / XML successfully. So perhaps, like OSI could not displace TCP/IP, web services will also “eat themselves into the grave” before they ever achieve acceptance.

Dennis Rockstroh of ActionLine in the Merc attempted to handle the frustration of a Sony Vaio user recently. Turns out the poor man continually had the power just blit out on him while working on his laptop. Back and forth to the factory it went, never seeming to get any better. Dennis helped the gentleman get a replacement laptop from the factory, but no one seemed to understand why such a problem was occurring and why it required a complete replacement to rectify. Sony didn’t wish to discuss it, and the frustrated user couldn’t figure it out other than noticing that wiggling the power connector sometimes worked.

How do I know this? Because I bought a Vaio PCG-FX-310 for my husband a few years back, and soon after acquiring it, the power connector began to fail. But since I’ve been putting together systems since the days of Symmetric Computer Systems, plus all that work on 386BSD and X86 systems from lunchboxes to desktops to laptops, we didn’t just sit around griping about the problem – we tried to figure out exactly why this happens – both as a good little example of the importance of design in a consumer product, and as an illustration of the difference between American and Japanese audiences.

Dropped by Miro Samek’s talk “Hierarchical State Machines: a Fundamentally Important Way of Software Design” at PARC last week, and still thinking about it. While the title is a bit over-the-top, some of the ideas such as a “quantum language” fit quite nicely in an RTOS. Of course, it’s architecture, architecture, architecture.

Mr. Samek himself sees the “framework” as applicable to many areas, such as real-time embedded systems, GUIs, or networking servers. He also is working on a realtime preemptive kernel which he says he will release soon. Why? As he put it himself “Obviously, what I’m doing is cottage-industry, but that’s all I can do alone.” Sounds like a good enough reason – just to try and see if it flies. That’s what exploration is all about.