The JEP-0066 messages for registering a subscription are very concise and relatively simple which I like:
<iq type="set" from="firstname.lastname@example.org" to="pubsub.jabber.org" id="create1"> <pubsub xmlns="http://jabber.org/protocol/pubsub"> <create node="generic/pgm-mp3-player"/> <configure/> </pubsub> </iq>
What I don't like, however is that just like SOAP, the actual message has the meta data in XML:
<iq type="result" from="pubsub.jabber.org" to="email@example.com" id="create1"/>
<iq type="set" from="firstname.lastname@example.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>
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.).
<iq type="result" from="pubsub.jabber.org" to="email@example.com" id="publish1"/>
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).