Syndication and the enterprise

Bill deHora: I don`t see why [syndication] 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.

He makes five arguments as to why he belives syndication and microprotocols (“namespaced module extensions that inform and affect application behaviour”) will challenge SOAP in as an enterprise messaging platform.

1) Microprotocols are independent of each other
I’m not convinced that defining a bunch of small formats independent of each other is necessarily a good thing. Such an approach leads to redundancy and overlap between specs. Over time, I think we’ll see a bunch of microprotocols that define many different ways to say the same thing — which ultimately a net negative for interoperability. I think you actually want a set of protocols that build on each other and compose well instead of redefining basic things in slightly different ways.

2) Syndication avoids addressing problems
It’s true that the RESTful protocols like the ATOM Publishing Protocol use the web’s standard system of URI’s for addressing. So in that sense you’re eliminating some complexity there. However, addressing (the act of figuring out what your addresses should be) is significantly more important in a RESTful system. This is because with REST, your addressing scheme defines your information architecture, and you’ll likely want to give some thought as to how you design the URI spaces. You don’t want to just go naming things willy-nilly; you want to think about how addresses map to the logical relationships that exists between the resources they identify. Effectively, with REST you need to map all the concepts in your system into a nice set of hierarchical spaces so you can stick URI’s on them…and coming up with a natural categorization for a large system of interrelated concepts is challenging.

3) No RPC baggage
This is one point that I defintely agree with Bill on: most of the SOAP toolkits out there are stuck in the RPC mindset. I hope that Indigo will go a long way towards fixing that problem, at least on the Microsoft end of things.

4) Tricky XML-isms have been solved
I certainly hope we (as an industry) as working towards getting rid of these rough spots.

5) Enterprises trend toward REST “outside the firewall”
Bill’s right on this one to, as least according to current data. Most consumer-facing web services (Flickr, Amazon, etc) have adopted styles that are not necessarily academically RESTful per se, but certainly fall into the category of HTTP+POX. This is an area where the low barrier to entry helps of such an approach. The easier your services are to use, the more people will use them. However, part of me wonders if the reason these consumer-facing services can get away with such simplicitly is because there’s a relatively small risk of failure when things don’t quite work they way to expect them to. For example, it’s not a big deal if uploading photos to Flicker is non-transactional. If some man-in-the-middle sniffs the contents of my Amazon shopping cart, I’ll get over it. Business-critical systems do not have such a luxurious tolerance for failure. In order to eliminate that chance of failure one must add complexity, and that complexity comes with a certain degree of implementation cost. That’s why John Q. PerlHacker can’t go and implement WS-AT in four easy steps. It’s a tradeoff between simplicity and robustness, and it’s important to draw the line in the right place depending on the scenarios. Syndication does a great job of keeping the simple case simple, but I’m not yet convinced that the hard cases are possible.