Monday, March 27, 2006

Initial Thoughts on JEP-0060 Pub/Sub

I re-gandered the JEP-0060: Publish-Subscribe spec. It is a pretty cool specification. See a lot of similarities to JMS, but a fair amount of differences. I don't think that it is going to cut it though for what I am after, however. What I would like to see is a RESTful (or Web Style as Tim Bray is now calling it) event driven - pub/sub.

The JEP-0066 messages for registering a subscription are very concise and relatively simple which I like:

Example 1. Entity requests a new node with default configuration.

<iq type="set"
    from="pgm@jabber.org"
    to="pubsub.jabber.org"
    id="create1">
    <pubsub xmlns="http://jabber.org/protocol/pubsub">
        <create node="generic/pgm-mp3-player"/>
        <configure/>
    </pubsub>
</iq>

Example 2. Server replies with success

<iq type="result"
    from="pubsub.jabber.org"
    to="pgm@jabber.org"
    id="create1"/>
What I don't like, however is that just like SOAP, the actual message has the meta data in XML:

Example 9. Entity publishes an item with an ItemID

<iq type="set"
    from="pgm@jabber.org"
    to="pubsub.jabber.org"
    id="publish1">
  <pubsub xmlns="http://jabber.org/protocol/pubsub">
    <publish node="generic/pgm-mp3-player">
      <item id="current">
        <tune xmlns="http://jabber.org/protocol/tune">
          <artist>Ralph Vaughan Williams</artist>
          <title>Concerto in F for Bass Tuba</title>
          <source>Golden Brass: The Collector's Edition</source>
        </tune>
      </item>
    </publish>
  </pubsub>
</iq>

Example 10. Server replies with success

<iq type="result"
    from="pubsub.jabber.org"
    to="pgm@jabber.org"
    id="publish1"/>
While this is much better then what you get with WS-*, I still think there is a better way. I'm thinking RESTful messages to create subscriptions (PUT) (would include URL where subscriber is listening), remove subscriptions (DELETE) (etc.).
And then for the actual events that are delivered to subscribers, the payload could be anything ... XML, JSON, etc. The message id, correlation id, redelivered, etc., custom message properties ... anything for the "Header" would be HTTP HEADERS rather then embedded in the payload.

The power I see in this is that you could easily implement something like this on many different platforms. You could have web server plugins, app servers, whatever. These components would do the guaranteed delivery, durable subscriptions, routing to N subscribers of a topic, etc. and the service impls would be able to be writen in any language. And then we'd have event driven architecture on the web vs. just in one off messaging systems (e.g., JMS).

2 comments:

Anonymous said...

It seems to me like an intrepid technologist could use the JMS spec as a model and easily craft the HTTP header-based spec.

fuzzy said...

Yes yes!

That is exactly what I'm thinking. Basically you would put JMS Header stuff and JMS Properties in HTTP Headers.

I have to think more though. And I need to read more of the other stuff I have stumbled across.

I think that is the easy part - the harder part is the runtime. Like ok, you have say 1000 subscribers to a topic. So you basically loop through them and to PUTS back to the URL that came with the subscription.

Ok so that is easy enough.

But what about clustering etc.?

Peer to Peer or broker based blah blah blah.