WS-Eventing for Dummies



WS-Eventing is a standard that enables interoperable publish/subscribe systems.  The spec itself is quite short and sweet – I recommend taking a look at it.  As a tester, I’m quite pleased by the simplicity because it makes implementations easier to test (and hopefully more robust).  I hope that you, as developers writing to the spec, find it easy to create those implementations.


So let’s see how subscriptions work with WS-Eventing…


The Simplest Subscription


I’m writing a client app, and I want to receive notifications about shark attacks.  I know there is a server out there that sends such notifications to anyone who subscribes.  Here is a first cut at a subscription message:


<Envelope>


    <Body>


        <Subscribe />


    </Body>


<Envelope>


(This is not valid WS-Eventing)


 (For legibility I’m stripping out the namespaces; please refer to the spec to get that info.)


What’s It All About?


Ok, that’s not a valid WS-Eventing subscription message; it is missing a few things.  First off, there is no mention of shark attacks there; we’ll fix that first:


<Envelope>


    <Header>


        <To>http://www.ocean.com/notifications/shark-attacks</To>


    </Header>


    <Body>


        <Subscribe />


    </Body>


<Envelope>


(This is not valid WS-Eventing)


Who Cares?


Well, that looks pretty sharp; but unfortunately having received our subscription, the service has no idea where to send the shark attack notifications!  We need to let it know where to send that all-important shark attack info, and we do it like this:


<Envelope>


    <Header>


        <To>http://www.ocean.com/notifications/shark-attacks</To>


    </Header>


    <Body>


        <Subscribe>


           <NotifyTo>


               <Address>http://www.me.com/shark-attack-notification-handler</Address>


           </NotifyTo>


        </Subscribe>


    </Body>


<Envelope>


(This is not valid WS-Eventing)


Did It Work?


Ok, that’s starting to look pretty good.  I’ve got a little surprise for you, though – according to the WS-Eventing spec, you get a response message to let you know that your subscription succeeded!  Wow, that’s cool – but now we have to let the service know where to send the response message.  We’ll use WS-Addressing’s handy-dandy ReplyTo header for that:


<Envelope>


    <Header>


        <ReplyTo>http://www.me.com/subscription-response-handler</ReplyTo>


        <To>http://www.ocean.com/notifications/shark-attacks</To>


    </Header>


    <Body>


        <Subscribe>


           <NotifyTo>


               <Address>http://www.me.com/shark-attack-notification-handler</Address>


           </NotifyTo>


        </Subscribe>


    </Body>


<Envelope>


(This is not valid WS-Eventing)


Insert Tab A Into Slot B


What else could we possibly need?  Well, honestly that’s the most important stuff, but the WS-Eventing spec does require a few more elements.  For example, we need to be able to handle multiple subscription requests from the same subscriber.  If you sent two copies of the message above (perhaps with shark-attacks and jellyfish-attacks), then you wouldn’t have any way to distinguish the two subscription responses that come back.  So let’s add an ID to each message that the service will return to us in the associated response:


<Envelope>


    <Header>


        <MessageID>http://www.me.com/subscriptions/583</MessageID>


        <ReplyTo>http://www.me.com/subscription-response-handler</ReplyTo>


        <To>http://www.ocean.com/notifications/shark-attacks</To>


    </Header>


    <Body>


        <Subscribe>


           <NotifyTo>


               <Address>http://www.me.com/shark-attack-notification-handler</Address>


           </NotifyTo>


        </Subscribe>


    </Body>


<Envelope>


(This is not valid WS-Eventing)


Administrivia


We still don’t have a valid WS-Eventing subscription message, but we are so close!  All we need now is a little bit of header fluff that says “yes, this really is a WS-Eventing subscription.”  And here we go…


<Envelope>


    <Header>


        <Action>http://schemas.xmlsoap.org/ws/2004/01/eventing/Subscribe</Action>


        <MessageID>http://www.me.com/subscriptions/583</MessageID>


        <ReplyTo>http://www.me.com/subscription-response-handler</ReplyTo>


        <To>http://www.ocean.com/notifications/shark-attacks</To>


    </Header>


    <Body>


        <Subscribe>


           <NotifyTo>


               <Address>http://www.me.com/shark-attack-notification-handler</Address>


           </NotifyTo>


        </Subscribe>


    </Body>


<Envelope>


(This is finally valid WS-Eventing)


And there it is.


There’s More Where That Came From


There are some optional elements in the subscription message that I haven’t discussed; and there are some other messages defined in the WS-Eventing spec.  I’ll talk about those in the future.  In the meantime, let me know if you found this useful.

Comments (29)

  1. John Collins says:

    Thank you for posting this discussion on WS-Eventing. I just wish more people would cut to the chase in describing how new things work.

  2. Sami Vaaraniemi says:

    Your one-piece-at-a-time approach to describing how WS-Eventing works is certainly easier to read and digest than the spec. I look forward for more posts like this.

    Do I qualify as a dummy now?

  3. Vijay says:

    Pretty cool idea ! Definitely helpful.

  4. WS-Eventing for Dummies

  5. Microsoft’s Bruce Williams has written an introduction to WS-Eventing for dummies: part 1 and part 2 [via Aaron Skonnard]…

  6. anonymous says:

    please explain other specs too.

  7. I’m most familiar with WS-Eventing, because the Indigo product area I test uses it. If you have a particular question about a different spec, though, I can try to answer it. (Or if there is a particular spec that is confusing, I could try to address that.)

  8. Best of breed content in reference to the WS-* specifications and the SOAPWSDLUDDI trio.

  9. ? WS_* ? WS-Eventing ? ? – WS-Eventing for Dummies…

  10. Hank Wallace says:

    The NotifyTo element specified in the spec doesn’t seem to require an Address element. Which is right?

  11. Its tricky because it refers to another spec (WS-Addressing), but it does in fact require the Address element. The content of the NotifyTo element needs to be an ‘endpoint-reference’, and according to WS-Addressing this means it consists of an Address element and optionally some other goo.

  12. Joseph Chiusano says:

    WS-Eventing is a specification, not a standard. 🙂

  13. whoops, you’re right! Split the difference and call it a "proposed standard"?

  14. Marina says:

    Very interesting… Can a Web Service subscribe to the events generated by a remote object in .NET?

  15. Its possible. This spec doesn’t dictate the format of the notifications (aka event messages) that get sent to the subscriber. It just tells you how to use some SOAP messages to register and unregister subscribers. In theory the subscription message could contain enough information to construct a local proxy to a remote delegate, and register that proxy delegate for events on a local CLR object.

  16. As we become more and more comfortable with embracing, or at least utilizing the Service Oriented Architecture…