Understanding XML

From SOA to ROA

I spent much of last week in New York at the Sys-Con AJAXWorld conference (held, with some irony, across the street from the corporate headquarters of Bear Stearns while that company imploded in the news - the normally well dressed Wall Street types coming out of that particular building were looking rather singularly disheveled). Jeremy Geelan, the CEO of Sys-Con and himself a rather dapper Englishman, threw a good conference as he normally does, bringing together thought provoking speakers with people exploring the cutting edge of today's technology.

However, one of the things that I observed at this particular conference was something that echoed a seminar I'd participated in a couple of weeks before at the GITA Geospatial Infrastructure Conference in Seattle. For all of the hype about SOA (and there's a lot of hype about SOA), it's not faring as well as one might expect when people actually have to implement real-world SOA stacks.

One of the major problems that people are dealing with is the fact that while SOA systems are reasonably good at facilitating machine to machine based communication, they don't tend to scale all that well outside of the department-to-department level; there is usually a huge disconnect when those machines need to communicate their results back to human beings (or vice versa). It's not pervasive, yet, but I think its part of what is in fact driving a significant resurgence in the idea of REST-oriented architectures (ROAs).

For the record, ROAs differ from SOAs in one significant way - SOAs are focused on service requests - in essence asking the server (as a proxy to some abstract object) to perform a certain action. In contemporary parlance it's verb oriented. ROAs, on the other hand, treat the web (or web-like systems) as a giant database of resource, and assume that the processing takes place outside of the immediate scope of this database. Put another way, an ROA is noun oriented instead.

This may sound like a fairly arbitrary distinction, especially since most web processes combine nouns and verbs in some fashion, but it turns out that this distinction is important, so important in fact that ROAs are essentially being "discovered" simultaneously all over the place as developers (and companies) realize that there are better architectures for working with the web.

In general, the dominant "emergent" ROA seems to be built around the W3C stack (not surprisingly), and consists of the following:

• Atom Syndication Format. This provides both the messaging and enveloping technology, and sits atop the massive RSS infrastructure currently found on the web.
• Atom Publishing Protocol (AtomPub). AtomPub provides a simple, semantically neutral way of publishing content (including data) to a server and retrieving dynamic feeds from that server, as well as to handle the underlying messaging and transactioning.
• XQuery establishes a data abstraction layer behind AtomPub for performing queries and updating content, and it can be used to implement or augment AtomPub on a server system (even if that server is local).
• OpenSearch is increasingly serving in the role of a discovery mechanism to determine which queries are possible against the published content.
• XForms and other RIAs have long been optimized for working with XML content (and with JSON, which can be readily serialized from many XML servers); they actually work quite well in displaying and editing this content.
• HTTPS and OpenID are being tapped for the security and authentication aspects of such communication.

There are additional ancillary technologies - XSLT 2 is often paired with XQuery, for instance, XSD and Schematron are handling type and rules based validation, and so forth - that are used at various points in this particular stack, but aren't as integral as the ones mentioned above.

One thing that you might notice in the above breakdown is that, if you're familiar with the SOA stack, there's an analog for most of the same pieces that you might expect in WS-*: enveloping payloads, message transport, authentication, discovery, presentation, and so forth. This is neither accidental, nor is it some nefarious plot to undermine the WS-* stack, but is instead an awareness that there's an alternative approach that addresses many of the same basic needs in a distributed data network, an approach that for the most part has arisen organically.

I always pay special attention to organic development efforts, especially when they take place over as broad a scope as is evident with ROA. Organic technologies either fall apart early on as market solutions provide better local alternatives (localized eddies of chaos that get absorbed over time), or they reach a point where they become coherent enough that other technologies get absorbed within them. The Web itself is an example of such an organic technology, having reached a point where attempting to fight the web would be like fighting the Jet Stream - it can be done, but at great costs in fuel and constant attention to changing conditions to keep from getting blown off course.

ROA, built on (and around) syndication around resource-oriented operations that push the non-publishing processing onto alternative asynchronous operations, is built around the way that the web works. Moreover, it is a meta-architecture that can actually mesh with SOA systems at the point where data is moving across the wire as XML. It also represents a growing shift in the awareness that data is more than just what's stored in a relational database (though it also acknowledges that most data will still, for reasons of efficiency, reside precisely in such systems).

For some time xml.com has focused on pieces of ROA - xforms, xquery, atom, etc. - largely without any conscious effort to do so. One of my goals, moving forward, is to try to start tying these technologies together as a complementary stack to the SOA infrastructure, to showcase companies and projects that are exploring the edges of this next big wave. If you are working on such a technology or a piece of it, and you're interested in having a case study done showcasing your efforts, please contact me at kurt@oreilly.com and let me know what you'd doing.

Insights: Martian Headsets

Standards development, and development using standards, can be an exercise fraught with peril at times. Joel Spolksy wrote an interesting article entitled Martian Headsets about the headaches that the Internet Explorer 8.0 team face in trying to both hew closer to open standards and simultaneously deal with their own legacy applications. An excerpt:

You're about to see the mother of all flamewars on internet groups where web developers hang out. It'll make the Battle of Stalingrad look like that time your sister-in-law stormed out of afternoon tea at your grandmother's and wrapped the Mustang around a tree.

This upcoming battle will be presided over by Dean Hachamovitch, the Microsoft veteran currently running the team that's going to bring you the next version of Internet Explorer, 8.0. The IE 8 team is in the process of making a decision that lies perfectly, exactly, precisely on the fault line smack in the middle of two different ways of looking at the world. It's the difference between conservatives and liberals, it's the difference between "idealists" and "realists," it's a huge global jihad dividing members of the same family, engineers against computer scientists, and Lexuses vs. olive trees.

And there's no solution. But it will be really, really entertaining to watch, because 99% of the participants in the flame wars are not going to understand what they're talking about. It's not just entertainment: it's required reading for every developer who needs to design interoperable systems.

Standards Watch

It's been a fairly busy week on the W3C front, with a number of secondary specs moving through the process: