Older blog entries for simonstl (starting at number 11)

aesthetics across communities

I've been thinking more about my earlier comments on aesthetics and think that maybe I took too simple a view. I value the aesthetics of the underlying XML, but there are lots of people out there who only value the aesthetics of what you can do with the XML - Web Services people are one group, but there are lots of other programmers and database people out there with their own aesthetics.

To those folks, the state of the XML underneath their transactions is "mere" aesthetics. It doesn't affect the performance of their applications in ways they notice or understand. XML-RPC has some bizarre structural anomalies in its parameter markup, but no one cares. I'm reminded of a comment I heard at last year's XML 2001 show: "Why would I go to a Web Services conference? It's not like I need to learn how to use XML badly."

Developers who work primarily with XML focus on document structure, while Web Services developers focus on application structure. It's kind of like the difference between building a house designed for a particular group of occupants (XML) or building a set of houses stamped out identically regardless of who will live there or why (Web Services).

People do seem awfully content to live in Generica, delighted by the aesthetics and cost of carbon-copy houses, malls, and lots and lots of roads. Maybe that's a better strategy for reaching a large audience in any case.

Ports, portals, portholes, pinholes

This may not make sense at first, but diaries seem like a good place to ramble through metaphors a bit.

For most of the early years of the Internet (as TCP/IP was arriving and the ARPANet->Internet transition was going on), the Internet and the computers on it were pretty much wide-open. Developers could build applications connecting an address and a port to an address and a port. With thousands of ports available, a limited number of people actually on the Internet, and a relatively open architecture, this model did quite well for a lot of years.

As the Web arrived and more people starting connecting to the Internet, all those open ports had to be hidden behind firewalls and private - though still TCP/IP - address spaces. Instead of wide-open access, developers created "portals" of various kinds, providing Web-based access to all kinds of information. Instead of connecting directly to the systems with the information, Web sites presented intermediate views. Access to information was now constrained by the portal.

Portals quickly grew huge, as different people in an organization used different parts. Fortunately, simple techniques like bookmarks let people find their way around without having to start from the beginning again. Some developers took advantage of the visibility of URLs to create meaningful and memorable identifier for information as well.

I see Web Services as moving to what I'll call a "porthole" model. Information is available, but through pretty small openings. Instead of the multiplicity of URIs that Web development has thrived on so far, Web Services (on the SOAP model) proposes to use far fewer URIs but let them have multiple services behind them. Less "space" is exposed to the world, but information still flows through that space. figuring out which porthole you want requires either advance knowledge or a query process (UDDI, WSDL) that itself likely (though not necessarily) goes through portholes.

It seems that the landscape for information exchange keeps shrinking. While ports remain available at the foundation, and portal models continue to dominate "traditional" Web site development, portholes are the next big thing. I'm not sure what pinholes will look like.

aesthetics

Today I'm pondering the importance of aesthetics in computing. There seem to be a lot of people out there who are perfectly fine with whatever, so long as it works. If the underlying data or code is wildly inefficient or overcomplicated, it's just fine, so long as what appears in their inbox/object/screen/whatever is what they expected.

I've defended spaghetti code and similar things in the past as necessary. In part it's just that spaghetti code is a step most people have to take on the way to getting a project to work - the emergence of refactoring as a topic all its own suggests that very few people get everything right the first time around. (There are a few, but they seem to be exceptions. I'm certainly not one of them.)

The problem isn't that first efforts are bad. The problem (as I see it) is that first efforts are sometimes cast in stone. Most frequently, this is because no one gets around to fixing them. If it ain't (badly) broken, don't fix it. Occasionally, though, a horrible mash gets canonized as some kind of standard.

That seems to be the case lately at the W3C. Members want their specs and they want them now, giving us charming things like W3C XML Schema and the lightly-modified but still deadly SOAP. While human-readability of markup probably isn't the best or only guidelines of the success or failure of a specification's use of markup, these specs reach new heights in creating XML documents that are actually embarrassing to show to an audience.

It's exasperating to me that XML people sometimes pick on Web developers because they take a more aesthetic approach. Sure, XML doesn't have much room for questions about syntax aesthetics, but there's enormous room for markup aesthetics, and we don't seem to take the time. We should learn from Web developers, not dismiss them.

I've been reading Jeffrey Veen's The Art and Science of Web Design for the last few days, and I'm delighted to see that this book manages to express an awful lot of aesthetic judgments I've shared without being able to explain them. Aesthetics seems a more obvious issue in Web design, with its generally explicit visual approach, but programmers and markup developers could use a similar set of discussions.

Maybe the answer is just to insist that people pay more attention to the aesthetics of what they're creating, even as the impatient howl for anything that works. I don't know how to make that stick, but it seems like it's at least worth considering. Talking about issues sometimes gets people thinking..

What the Web is, and a wannabe

Roy Fielding's posted a clear explanation of the fundamental conflicts between Web Services and the Web, while Noah Mendelsohn seems to think that having ambitions similar to the scope of what the Web has achieved makes something a part of the Web.

Oh, and David Orchard has concluded that those questioning the rightful place of Web Services in the Web and at the W3C have a "reckless and irresponsible attitude".

Funny, I thought I was being quite conservative, in a "conserve the Web rather than take reckless and irresponsible action" kind of way. Or is that just stop energy? I just can't win.

braden asks if I'm depressed by the quality of responses I got to my Web Services article. I wasn't depressed by the first two, who completely missed the point, but I'll admit to being depressed by his comments.

Too many developers seem to be just floating along with the Web Services current, sort of figuring that "everybody's doing it" in a mutually reinforcing march toward the cliffs. No one, even its supporters seems to be able to explain what value SOAP really adds - except, of course, that "everybody's doing it."

Web Services does share one tiny feature with the Web - it cuts across platforms, languages, and pretty much every other aspect of computing. Unlike the Web, its ambitions are enormous, its ownership is uncertain and unfriendly, and its architecture is a mash. HTTP was hackery, but had time to adjust before it reached a wide audience. Web Services is hackery, but its proponents insist on staying the Web Services course as previously charted.

To repeat a point I made replying to braden, "I don't see anyone building Web sites, for instance, that use a single URI and expect users to send POST requests to get back different pages." That's exactly what SOAP is all about.

I'm not sure I like the REST platform that much myself - BEEP or something similar seems like a better approach to dealing with these kinds of development issues. Despite that, I have to thank the REST folks for helping me express my persistent unease with Web Services more effectively. (And Keith Moore as well, whose RFC 3205 was a great start from a very different perspective.)

Clear the decks

Edd Dumbill suggests that the W3C should Kick Out the Cuckoo and send Web Services off to a new home before Web Services becomes an even larger threat to the coherence of the Web than it already is.

It's bad enough that Web Services are named that - even Anne Thomas Manes acknowledges that it's a misnomer, while insisting that the W3C should work on them. As she puts it, "Web services (based on the existing Web services architecture) aren't constrained by Web technologies." There's a name for publicly shared TCP/IP-based network technologies that aren't constrained by Web frameworks - they're called Internet technologies.

While kicking out Web Services may seem a tough thing to do, it's not very difficult to see it being a good divorce for both parties. The Web Services people can go off and do what they like without being scolded so often in public for lousy architecture and creatively unclear intellectual property policies. Its supporters can howl that "it works" or claim that it really doesn't matter without causing the same kind of collateral damage they currently seem happy to ignore.

The W3C can focus once again on the Web and things that make it work better, with a coherent architectual focus. Less pressure from impatient companies who want to slap the imprimatur of the W3C on things that aren't much to do with the Web might even be a good thing.

Descriptions should mean what they say

Okay, not all the time. If you have to mean what you say the time, life probably gets dull. However, for technical specifications, I suspect that transparency is generally a good idea, and titles should be descriptive.

I'm concluding that Web Services - as represented by SOAP, WSDL, and UDDI, really aren't "of the Web" in any significant way. They've hijacked HTTP for a while, and found a home at the W3C, but they really don't fit.

Why? I'm focusing on two areas, both in SOAP.

The first is what I'll call URI-abuse, where SOAP uses URIs badly on a number of counts. A single URI may represent multiple entirely different kinds of resource to SOAP, effectively depending on what kinds of calls or routing lurk behind that API. WSDL can help you figure out what's where, but there's nothing really natural about it. It's kind of like building a Web site that has only one URL and takes form requests exclusively to figure out what to present you. Yes, you could make that work in HTTP, but it's an alien approach. SOAP developers also seem fond of nearly random URNs for things like namespaces.

The second is a confusion, conflation, or something else between the envelope and the message. SOAP headers are part of the document, optionally part of the MIME headers, or both. While XML lets you do this - you can create elements for whatever you like - it's another practice I can't say I'd encourage. I always had doubts about things like HTML META tags using HTTP-EQUIV. It's a serious blurring between content and delivery system, which feels to me like another wrong turn.

I think the conclusion I'm reaching is that Web Services need a new name, and that they probably don't belong at the W3C, if the purpose of that consortium is to define and develop the Web.

Roy Fielding seemed to come to a similar conclusion yesterday, and Keith Moore and Len Bullard provide more good reasons to think about that today.

Hitting the fault line

Anne Thomas Manes pounded on the W3C for being academic, apparently because not everyone loves Web Services. After she insisted that the W3C's Technical Architecture Group step aside when "big business" had work to do, Roy Fielding replied quite powerfully:

"If this thing is going to be called Web Services, then I insist that it actually have something to do with the Web. If not, I'd rather have the WS-I group responsible for abusing the marketplace with yet another CORBA/DCOM than have the W3C waste its effort pandering to the whims of marketing consultants. I am not here to accommodate the requirements of mass hysteria."

I covered the discussion in my O'Reilly weblog, but it's awfully hard to express the extreme divergence of views any better than they've already done.

A later post from David Orchard and a reply from Fielding illuminate the divide even more.

Suds

The What does SOAP really add? thread continues on xml-dev. Leigh Dodds has a good summary of the opening of the discussion, and it continues.

Particularly worth reading are posts from Don Box (1 2 ) and Adam Turoff, as well Julian Reschke's explanation of how SOAP is generally opaque to XSLT processing (1 2).

In the meantime, similar discussion is going on at the W3C's www-tag list. Anne Thomas Manes and Paul Prescod are going back and forth (1 2 3 4 5)

I'm wondering more and more if maybe it's time to sever Web Services from the Web. Practice, both technical and business, seems pretty different for the two sets of specifications. Don Box is already talking about moving away from HTTP, and the founding of the WSIO suggests that the corporate behemoths want their patents along with the Web Services.

It doesn't seem like it's worth risking the foundations of a successful communications medium just for the sake of envelopes embedded in documents and inflicting W3C XML Schema on the universe.

It's a risky proposition, but maybe the Web Services folks should take their toys and go play at the WSIO. There they can openly control the process, use RAND licensing, and migrate away from the Web as we know it. With that clear separation made, the Web can go on as a royalty-free mode of communications of a wide variety of sorts.

More on SOAP

I asked some rude questions about SOAP today, and I'm pretty pleased with the answers I've had back.

Paul Prescod largely concurred with my worries (and he wrote a very nice bit on SOAP/WSDL and state issues earlier), so I figure I'm not completely cracked.

Mark Baker had a more precise list of what SOAP adds to XML messaging, which pretty neatly outlines what I'll be looking for in my next rereading of the specification, and Mike Champion offered a lukewarm endorsement of the "SOAP value proposition" that somewhat matches Mark's but also fits in the "everybody's doing it" category of answers.

I mentioned in a later message that I look at SOAP from a markup perspective, sort of the way a plumber might look at a building and its pipes. It's occurred to me since writing it that my largest concern isn't the different viewpoints of plumbers, contractors, and inhabitants. My largest concern is that there appears to be nothing in technology currently which resembles a building code inspector.

Lack of building inspectors seems like more reason to go with open source - at least you can do your own inspection, if you know what you're doing.