WS-BaseNotification vs WS-Eventing

Question

According to literature on the web, I can see that there are two specifications related to Web Services Eventing:

1. WS-BaseNotification - submitted by OASIS in 2004
2. WS-Eventing - submitted by W3C in 2006

To me, both seem to have the same functionality. What is the most acceptable specification in the industry now?

Answer 1

I think most people these days would not use SOAP but rather rely on simpler protocols (AMQP/JMS in this case) but if you do need/want to use SOAP WS-Notification (which is the parent standard for WS-BaseNotification) is the more widely supported protocol (e.g. by ServiceMix or IBM WebSphere)

Answer 2

You can't compare SOAP (message encoding part of webservices stack) with AMQP or JMS (also transfer protocol). With SOAP 1.2 you can use JMS transport binding (only for RPC). AMQP builds on TCP, so you can use "SOAP over AMQP" as well as "SOAP over TCP". You can see this paper to see where SOAP in webservices stack relies.

To the question. Two competing standards:

1. WS-Eventing W3C Public Draft
2. WS-Notification 1.3 OASIS-Standard (replaced WS-Events), which grew to family of 3 specs:
   • WS-BaseNotification (very similar to WS-Eventing)
   • WS-BrokeredNotification (optional)
   • WS-Topics (optional)

are also converging in each version update. There is no "leader" in the industry. WS-Eventing is simpler sister of WS-Notification, which can be advantage in some cases. For example WS-Eventing doesn't define Pause/ Resume Subscription (but you can unsubscribe/subscribe), broker intermediary (but there is a way to do it), etc.

Implementation which can intelligently switch between these ws-* specifications can be found here. The way, how to add message queuing, isn't defined by any. This is where AMQP binding or websocket subprotocols binding will play the role in the future of webservices stack, I think.