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:
- WS-Eventing W3C Public Draft
- 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.