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).

HTTP/POX XML Based EDA / Pub Sub ??

I googled around a bit.

Found mod_pubsub, but it didn't look terribly active (WIKI down). Anyone worked with that?

Also there is JEP-0060: Publish-Subscribe. I just glanced at it - looked like it manages the subscriptions via XML (non-SOAP) messages. I guess that would work too, but assume that is basically the WS-* sans the SOAP / cruft.

I need to catch up with what is already out there.

It would be great if there was a decent / simple spec. for this and there were either web server plugins, app servers, etc. for many platforms. For all I know, I have been drinking the JMS Kool-Aid & muttering things about WS-* (what I considered the somewhat available alternative) for too long and there is a viable solution to HTTP/POX XML Based EDA Pub Sub today.

Anybody have any experience using HTTP / POX XML (be it via HTTP Headers or something like JEP-0060) for EDA / Pub Sub?

27-MAR-06 Update, found this: The Goal A Jabber manifesto of sorts

Started a thread over at Jive - figure they might have some thoughts. Jive Thread

04-APR-06 Update, found this on the Yahoo SOA Mailing list: Reach Reliable Messaging Transport Protocol (RRMTP/1.0)

HTTP Extensions

Don Box mentioned HTTP Extensions I think that this would have had a much better chance of actually being used by people that have complex integration problems to solve then the mess we now find ourselves in with WS-*.

For one, there is no SOAP or XSD. Chance of success just went up 10x because of that alone. Second, all the header cruft would not be in the XML document. Developers wouldn't be impaling themselves with generated code, schema problems, parser problems, etc.

Those headers would be *much* easier to parse (one would assume). Much less chance to cut ourselves on interop.

I would assume that some faction of REST/POX will eventually want to do something like this. In a previous post on HTTP, XML, REST, and $100, I mentioned event driven architecture (EDA). I don't see that happening without either this or the equivalent of what the WS-* world has (I saw on Tim Bray's blog EDA is being revisited in WS-* land). Including the headers in the XML document is what makes WS-* awful IMHO. With POX + HTTP Extensions (or something like it), the service developer would have the power of owning the XML contract outright (just has to be a well formed XML doc). You could add complexity as you went (via HTTP extensions), and the XML wouldn't change. Setting/Reading the headers could be set via configuration in relatively simple (compared to WS-*) frameworks. Seems like appropriate separation of concerns to me.

Obviously, web servers would have to evolve (plugins), but this path actually seems plausible - I just don't see WS-* resulting in a workable integration solution.

What's the catch?

Gauge My Eyes Out

I read Tim Bray's post on some recent course correction around web services specifications and wanted to gauge my eyes out. Web Services mania started in 2000. It's 2006. Can we just call it a failure already and go back to the drawing board?

HTTP, XML, REST, and $100

In response to: Don Box's Spoutlet: HTTP, XML, REST, and $100 I’d target event driven architecture & or pub/sub using HTTP,XML,REST. Not sure how good Microsoft MQ is these days , but last time I checked it was pretty weak in the pub/sub area compared to good JMS impls. This has been my biggest hang up with the state of the art of web services. I think that currently, you really can’t build an event driven architecture with web services. And most of the WS-* specs have an extreme P2P bias which in a large integration will just collapse like it always has (pointed haired n(n-1) problem). Yeah there is WS-Notification, but are there really any decent impls? Do the interoperate? I don’t want all that cruft in my events anyway. Not sure if you are already have something like this I have been away from Microsoft projects for some time. I have a hard time believing that event driven architecture can even work over HTTP (yeah you could have a service or too that work that way, but I wouldn’t bet my business on all of them working that way). My general background … I am a B player Microsoft developer (at best). I am conversant in .NET because I went to a training at Microsoft for a week and I did a couple C# projects with web services and messaging. My experience with WS-* was very unpleasant. I worked with CORBA, DCOM, and RMI before that and they were almost easier to make interoperate. I am a little dated though. I gave up on web services in late 2003 and haven’t really looked back. I do follow the arguments though and find myself in the Lo-Rest/POX corner. I make my living integrating large financial systems in an event driven architecture/Lo-Rest that is Java based. I read most of some write up on Indigo on a plane a couple weeks ago. Like I was with .NET, I was impressed. I said to myself, “This is about as good as anyone is going to make WS-* -- it is a pity that WS-* is so fatally flawed that it doesn’t really matter.” I was confronted though knowing that Microsoft would salvage something from it ;)