Steve Vinoski just published a column that compares the various web service eventing specs. He has this to say about the WS-Eventing spec from Microsoft, BEA, and Tibco:

Nevertheless, WS-Eventing could be better in several ways. First, if it were based on WSDL service references rather than WS-Addressing, it would be much cleaner, more elegant, and more easily applicable to bindings other than just SOAP over HTTP. Second, WSEventing has no event metadata discovery capabilities, as in HP’s WS-Events specification. Third, and perhaps most important, the intellectual property rights and royalty issues associated with WS-Eventing, WSAddressing, and other associated proprietary specifications are far from clear. Some complain about the relatively slow pace of standards development, but proprietary standards such as these serve only to slow technical advances in the Web services market, not speed them up.

I don’t see how the reliance on WS-Addressing ties WS-Eventing to soap.http://. To me, the beauty of WS-Eventing is that the spec treats an event notification as just another form of a SOAP message, and uses the well-defined rules in WS-Addressing to dispatch that message. WS-Addressing is itself agnostic to the underlying network transport, so it seems to me that relying on WS-Addressing to route event messages to their sinks would decouple the eventing framework from the transport, not tie it to the transport as Steve suggests.

Secondly, I think omitting metadata discovery capability from the WS-Eventing spec was a conscious decision on behalf of the authors. Because the players in WS-Eventing scenariors are just a specific type of service, it’s possible to use the tools developed elsewhere for discovering and describing services in the general case and apply those tools to a WS-Eventing scenario. Presumably, clients who use WS-Eventing would first use a mechanism based on WS-Discovery to discover the event source, obtain the necessary metadata via WS-MetadataExchange, and then communicate events according to WS-Eventing. I think this shows a good separation of concerns across the various specs.

Finally, I don't understand his comment about proprietary standards slowing down technical advances. Although BEA, MS, and Tibco may own the WS-Eventing spec, it’s an open and published specification and there’s nothing stopping me from going out and implementing it. If I do that, I have running code – and if I have running code, I can test it out, see how it works, and identify areas for improvement. If we wait until we have full consensus from a recognized standards body before we implement anything, all of the discussion will be based around theoretical and imagined implementations instead of real-life experiments. Basically, I think most of the arguments for iterative development are equally valid when it comes to the standardization process – and in that spirit, I’ll take working code over theory any day (even if that code is based on a “propriety” but published spec). I agree we need to reach consensus, but instead of waiting for the One True Standard to come down to us from On High, let’s get implementations of the competing standards out there in the real world, bang them together, and take the best ideas from each.

Update: I just found Steve's blog entry on Proprietary Standards, so I see a bit more where he's coming from with his comment. I don't know if I buy his argument, but I see where he's coming from.