WS-Syndication
I’ve been talking a lot with Mark Hapner, one of the Java Web Services thought leaders here at Sun, about event handling and delivery in the Web Services context. Here’s where our conversation has led, in a nutshell: Most serious enterprise apps are going to have to do event handling, but WS-Eventing is kind of lame. That’s the bad news; the good news is that with RSS, we’ve built up plenty of experience with real-world event publishing and subscribing. Plus, we know how to ramp it up to Internet scale. So don’t Web Services already have all the event technology they need, ready to use?
WS-Eventing · The problem this is trying to solve is obvious: enterprise apps have to deal with unpredictable events. My issue with this spec is that it’s over-engineered; in particular:
The endpoint that manages the subscription can be different from both the endpoint that’s doing the subscribing and the endpoint that’s being subscribed to. Seems to me that some experience with actually doing subscriptions in the simplest possible way would be helpful in figuring if this is really necessary and if so, what the right way is to do it.
There’s a “filtering” capability built-in, with a basic XPath filtering package built-in, and a very general extension mechanism. But WS Endpoints include URIs which can have all sorts of filtering capabilities right there in the URI, so wouldn’t it be smart to prove that you’re going to need this before you wire it in?
A subscription can be given a duration, so it will lapse automatically after a specified time. However, there is also an “end subscription” message, and services are advised to use it redundantly with the duration facility. YAGNI.
WS-Eventing is not only over-engineered, it’s under-configured. It provides for an extensible family of protocols for event delivery, and wires in one method, direct message push. Well, as I’ve written before, the world only knows two message-delivery frameworks that work at Internet scale: store-and-forward and post-and-poll. Weirdly, WS-Eventing wires in, instead of either of these, a mickey-mouse approach that is widely known not to scale. Which is, at best, inexplicable.
Why Not RSS? · If you want to route messages around and deliver them to applications, why not use what we already know works? RSS contains a tasty selection of important predefined metadata, plus it’s extensible so you can ship your own XML around in the payload. We know how to generate, parse, and aggregate it, and there are well-shaken-down libraries available for Java and Python.
If you’re nervous about the fact that RSS comes in multiple flavors, or is a little shaky around embedded markup, or isn’t in a namespace, or doesn’t have a standards-organization stamp on the side, just hang on a few months and Atom will have all those bases covered.
Where To? · I think that writing a few WS-specific best practice notes around RSS or Atom would be a whole lot less work than polishing the rough spots off WS-Eventing, plus you’re starting off with something that’s known to work. Seems like an obvious choice to me.
