For most avid blogophiles, RSS/ATOM is a simple means of publishing content in a format that content aggregators can easily read and interpret to provide us with news feeds when and where we need them. It’s all about the article feed - or is it?
While it’s clear the predominant use of RSS/ATOM is really driven around article feeds, actually there is nothing to prevent the underlying payload from being any form of data that we like. Data exposed by RSS/ATOM has some interesting architectural implications.
- The most interesting one is that properly formatted and consumed RSS/ATOM feeds understand WHEN they were relevant and provide means to know WHAT you’ve already read. While this could be implemented into a direct call Web Service, it’s nice that it’s already built into RSS/ATOM and abstracted away from the calling application.Â
- Interfaces become simpler — while applications need to understand the data, the exposed service is clearer. Reading a RSS/ATOM feed is well understood without needing to know all the properties, use WSDL or other description services you can access the available information.
I don’t believe that SOAP based web services will be replaced, however there are opportunities to look at the use of RSS/ATOM for moving data when a complex service interation is not required, which is a typical issue most first time SOA efforts come up against.  Even then, services like Yahoo pipes, will provide a mechanism for extracting a interacting across multiple RSS/ATOM feeds.
In the services based world, we should be de-constructing objects to their simplest deliverable form, then aggregating them to maximise re-use where needed. For data transfer options on a subscription basis, RSS / ATOM looks like a good choice.
Interestingly, ATOM is in fact one technology of choice for the underlying data synchronisaton capabilities for Lotus Expeditor
I predict it’s probably only a matter of time until Yahoo has a Pipes Appliance (something like the Google search appliance — a “black box” that can be installed on your own network) which Enterprises can use as a glue between syndication services within their domains.
If you’re considering a SOA strategy, then RSS/ATOM syndication is one tool in the box that can help with data synchronisation across applications, leaving your Web Service designers to focus on the real value of services which is complex, business services replication.
For some SOA implementations, particularly those not needing compensation, this is one more stragtegy to help remove the need for process orchestration services, allowing applications to use RSS/ATOM to pull data from one place to another.
May 8th, 2007 at 2:00 pm
We have found the same thing for Particls. We specifically wrote an input adapter architecture that would let 3rd parties grab content from any data store using any API they chose.
We assumed many people would want to use proper Web Services and SOAP as well as access local applications and data stores.
We have found though, that for 99% of cases, it is easier to just transform the data to RSS and give it to the feed reader.
In this day and age of increasing complexity and information that people seem to gravitate towards the ‘good enough’ solution. From VHS to MP3 through to RSS and mashups.
Sony keeps forgetting this reality with their format wars and Microsoft is often late to the party - but when they come, they bring their full weight and inertia.