Share via

WS-Eventing Part II: The Subscription Response

  • Article

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.

Subscription Request

<Envelope>

    <Header>

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

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

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

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

    </Header>

    <Body>

        <Subscribe>

           <NotifyTo>

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

           </NotifyTo>

        </Subscribe>

    </Body>

</Envelope>

Subscription Response

<Envelope>

    <Header>

        <Action>https://schemas.xmlsoap.org/ws/2004/01/eventing/SubscribeResponse</Action>

        <RelatesTo>https://www.me.com/subscriptions/583</RelatesTo>

        <To>https://www.me.com/subscription-response-handler</To>

    </Header>

    <Body>

        <SubscribeResponse>

            <Id>uuid:1541c2c1-d5a9-4ba0-ba09-e668a1158b45</Id>

            <Expires>2003-07-01T00:00:00.000-00:00</Expires>

        </SubscribeResponse>

    </Body>

</Envelope>

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:

<Envelope>

    <Header>

        <Action>https://schemas.xmlsoap.org/ws/2004/01/eventing/SubscribeResponse</Action>

        <RelatesTo>https://www.me.com/subscriptions/583</RelatesTo>

        <To>https://www.me.com/subscription-response-handler</To>

    </Header>

    <Body>

        <SubscribeResponse>

            <Id>uuid:1541c2c1-d5a9-4ba0-ba09-e668a1158b45</Id>

            <Expires>2003-07-01T00:00:00.000-00:00</Expires>

        </SubscribeResponse>

    </Body>

</Envelope>

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.

Comments

  • Anonymous
    February 14, 2004
    Enjoyed your post, but it highlights two important questions about WS-Eventing:
    1) are the To and Reply to in the Subscribe message headers really required. Presumably if stuff is just delivered to a specific http destination via basic SOAP the To header isn't really necessary.

    Some day we'll all have WS-Addressing-enabled SOAP stacks and we'll use those To headers for handy asynchronous and indirect (potentially over intermediaries) delivery. With today's SOAP stacks, its difficult to see what that To header buys you.


    2) So let's assume that the To header is required. In the SubscribeRespons presumably the To should match the ReplyTo of the Subscribe message (as your example shows). The spec should probably state that requirement.
  • Anonymous
    February 15, 2004
    Microsoft's Bruce Williams has written an introduction to WS-Eventing for dummies: part 1 and part 2 [via Aaron Skonnard]...
  • Anonymous
    February 16, 2004
    Adam - good comments! I think you pretty much answered your question #1 yourself. The WS specs that Microsoft works with are pretty determined about being transport-agnostic; and this means we can't assume that http is around, handling our session and response-reply requirements.

    Whether that's a good idea; and whether the spec should have special-case optimization the case where the transport is HTTP; are both good questions that I don't have immediate answers for; guess I'll have to go talk to the architects some more...

    As for question #2 - I believe the spec explicitly does not want to require that 'To' match 'ReplyTo' - I grabbed the following sentence from the relevant section of the WS-Addressing spec: "When formulating a reply message, the sender SHOULD use the contents of the [reply endpoint] of the message being replied to to formulate the reply message." I will again beg ignorance about the exact scenarios that make this desirable - did I mention that I'm the "Dummy"? <grin>
  • Anonymous
    February 16, 2004
    Best of breed content in reference to the WS-* specifications and the SOAPWSDLUDDI trio.