« Jython 2.2a1 | Main | Our dichotomy opens the combat »

Atoms in a small world

Just as Web Services start to embrace the Web and begin to pare the specifications down to manageable levels, syndication technologies begin to present new options for enterprise computing.

Mark Baker points to a piece by Jack Schofield in Computer Weekly comparing SOAP and RSS/Atom:

"It is clear that there are lots of server-based applications (not blogs) that could work by syndicating packets of XML data to client applications (not RSS aggregators). These will not rival Soap/web services as a system for executing transactions." -Jack Schofield, Quick and dirty substitute for Soap

I agree with Mark. If anything Jack Schofield is underestimating the impact syndication technology might have over the next decade. Last year I used Atom as the packaging format to ship system and business level events to a central monitor (I bet Coté would be up for a bit of that). I don't see why it would not be a good basis for enterprise concerns like messaging, authentication, or management interfaces. Atom, RSS and the Atom Publishing Protocol (APP) as a complement to REST could disrupt SOAP and WS.

The SOAP systems are going into their 3rd generation, but the same old skeletons of object mapping, synchronicity, design from code to wire and over-specification persist. For example, it would be curious to see how the Alpine Web Services proposal for Java might turn out if it targeted syndication XML instead of SOAP XML.

While the APP is 'just a' publishing technology and Atom is 'just a' syndication technology, there are five reasons to that microprotocols - namespaced module extensions that inform and affect application behaviour - will appear as an alternative to WS and SOAP based technologies by targeting enterprise computing concerns like reliable messaging and tracking. First such protocol driven extensions will tend to be mutually exclusive of each other and not an interdependent monolith as Web Services have turned out to be - that will make them easier to build and get deployed. Second, a good amount of Web Services complexity comes down to addressing - with syndication formats, addressing problems are dealt with using the Web's architecture and existing infrastructure rather than starting over. Third, with the exception of XML-RPC, none of the web syndication technologies carry the baggage of RPC-centric, protocol agnostic computing. While SOAP proponents are adamant the state of the art has moved beyond remote procedure calls, in the field many still have not learned the lessons and the tool kits have not yet caught up with best practices. Fourth and this should not be underestmated, a number of tricky issues around using XML in the protocols arena, security, and for carrying non-XML content were shaken out by the work on SOAP for others to learn from - this is reflected most notably in the Atom effort. Fifth, and perhaps most important, where traditional enterprise concerns cross over with consumer online services, they have tended to gravitate to plain XML over HTTP and REST-oriented approaches rather than SOAP Web Services. This is being done squarely to encourage the treatment of the service as a development and innovation platform and again comes down to speed and ease of implementation.

There's Plenty of Room at the Bottom

As next generation browser and aggregator applications fully support Atom, RSS and the APP, there's no reason to think that facilities like online order tracking and notifications will not be exposed using those formats. There's also sufficient reason to think that mobile technology will also support them. Incumbents, commercial innovators and application developers will tend to not invest time with the infrastructure as has been the case with Web Services - in truth when the pace and nature of innovation is happening outside consortia space, there's isn't much leverage to be had by controlling infrastructure. Instead they'll tend to target and compete using microprotocol extensions in a feature-driven approach. Microsoft are already going down that road with in terms of microformats with the RSS simple list extensions - which are incidentally usable via any syndication format. Extensions for enterprise concerns will surely follow.


The title of this post is taken from a section heading in Richard P. Feynmans wonderful essay There's Plenty of Room at the Bottom


July 19, 2005 09:07 PM

Comments

Randy Charles Morin
(July 20, 2005 07:52 PM #)

I think Jack was specifically referring to RSS and the Atom format (all GET all the time), not the API. In which case, the opposite opinion of Jack's article is in play.

Ward Harold
(July 21, 2005 04:48 PM #)

Bill, have you written anything, formal or informal, about your use of Atom to "ship system and business level events to a central monitor"? I'm tasked with doing something similar and would be glad to learn from other's experience.

Thanks ... WkH

Cote'
(August 1, 2005 10:57 PM #)

Speaking of writing stuff up, would you be interested in co-authoring an article on using RSS for sysmgmt/even type stuff? I don't have direct expierence doing it, but I spend a fair amount of time day-dreaming about it. It seems like you've got something interesting that has actual working code.

Post a comment

(you may use HTML tags for style)




Remember Me?

Trackback Pings

TrackBack URL for this entry:
http://www.dehora.net/mt/mt-tb.cgi/1611

Listed below are links to weblogs that reference Atoms in a small world:

» Atom 0.3 vs. Atom 1.0: End Users as Collateral Damage from Dare Obasanjo aka Carnage4Life
TITLE: Atom 0.3 vs. Atom 1.0: End Users as Collateral Damage URL: http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=6cb157b9-6449-4718-8c96-ddd9db22ffbc IP: 24.18.239.137 BLOG NAME: Dare Obasanjo aka Carnage4Life DATE: 07/21/2005 04:25:06 PM [Read More]

Tracked on July 21, 2005 04:25 PM

» Web Services Link Dump from Jeremy Smith's blog
Sam Ruby REST vs APIAt some point, you need to question the wisdom of having an API which abstracts away... [Read More]

Tracked on July 26, 2005 04:04 PM

» Note To Radovan: Writing In Bold doesn't make an argument clearer from James Governor's MonkChips
I recently wrote a rambling, everything but the kitchen sink screed on service registries. My argument was that it doesn't make sense to say UDDI is the only possible registry mechanism, when there are so many different service models coalescing,... [Read More]

Tracked on July 29, 2005 03:31 PM