Before I talk about the optional elements on a WS-Eventing subscription, I’d like to quickly cover the response message you get back when your subscription request is accepted.
Taking a Header
Most of the stuff in the response message header is just bits of information from your request header, regurgitated back to you; your <ReplyTo> address from the request becomes the <To> address on the response, for example. Our example subscription request is shown below, as is the associated subscription response. I’ve color-coded it to show which bits get copied from one place to the other. I offer my apologies in advance for the lack of subtlety in color choices.
There is also the bit of fluff that says “yes, this really is a subscription response” – I’ve highlighted that in yellow below.
The Meat of the Message
More interesting is the new data that the service returns to you; namely, the <Id> and <Expires> elements. The act of receiving the subscription response tells you that your subscription was accepted; so why do we need these extra elements at all?
It turns out that these elements exist for administrative purposes. The service assigns an ID for your subscription, so that you can uniquely identify that subscription in later messages from you to the notification service – for example, if you want to unsubscribe, or extend your expiration time. The service gives you an expiration time because it doesn’t want to clog itself up with a bunch of stale subscriptions; if you want to keep your subscription alive, you better go renew it every once in a while.
Here is the subscription response message again, with the ID and expiration elements highlighted:
That’s the end of WS-Eventing for Dummies, Part II. I hope you enjoyed reading it as much as I enjoyed writing it. Next time, I’ll talk about some of the optional elements on the subscription request.