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. Anonymous 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. Anonymous 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. Anonymous says:

    Pretty cool idea ! Definitely helpful.

  4. Anonymous says:

    WS-Eventing for Dummies

  5. Anonymous says:

    Great little write-up!

  6. Anonymous says:

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

  7. Anonymous says:

    please explain other specs too.

  8. Anonymous says:

    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.)

  9. Anonymous says:

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

  10. Anonymous says:

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

  11. Anonymous says:

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

  12. Anonymous says:

    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.

  13. Anonymous says:

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

  14. Anonymous says:

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

  15. Anonymous says:

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

  16. Anonymous says:

    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.

  17. Anonymous says:

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