Extension Handling 101: Example 3

Continuing in our series on extension handling here is Example 3:

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
            xmlns:wsa="http://www.w3.org/2005/08/addressing"
            xmlns:wse="http://www.w3.org/2009/02/ws-evt"
            xmlns:dev="http://www.smalldevices.org/evt-ext">
  <s:Header>
    <wsa:Action>http://www.w3.org/2009/02/ws-evt/Subscribe</wsa:Action>
    . . .
  </s:Header>
  <s:Body>
    <wse:Subscribe>
      <wse:Delivery>
        <wse:NotifyTo>
          <wsa:Address>http://www.example.com/MyEventSink/OnStormWarning</wsa:Address>
        </wse:NotifyTo>
        *<dev:Pauseable>
          <dev:Duration>P3H</dev:Duration>
        </dev:Pauseable>
***      </wse:Delivery>
    </wse:Subscribe>
  </s:Body>
</s:Envelope>

Hooray! Our implementation understands and supports the dev:Pauseable 
extension! We know that it means that the Subscriber wants to create a 
"pauseable" Subscription and enable the use of the "Pause" and "Resume" 
extension operations. We also know that the dev:Duration sub-element is 
an indication that the Subscriber would like us to persist the 
Notification messages for paused Subscriptions at least 3 hours (don't 
worry, this is all meticulously described in a specification that can be 
found be de-referencing the RDDL document at 
http://www.smalldevice.org/evt-ext . . .). In compliance with this 
meticulously crafted specification we create a pauseable Subscription 
and respond with the following:

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
            xmlns:wsa="http://www.w3.org/2005/08/addressing"
            xmlns:wse="http://www.w3.org/2009/02/ws-evt"
            xmlns:dev="http://www.smalldevices.org/evt-ext">
 <s:Header>
    <wsa:Action>http://www.w3.org/2009/02/ws-evt/SubscribeResponse</wsa:Action>
    . . .
  </s:Header>
  <s:Body>
    <wse:SubscribeResponse>
      <wse:SubscriptionManager>
        <wsa:Address>
          http://www.example.org/oceanwatch/SubscriptionManager
        </wsa:Address>
      </wse:SubscriptionManager>
*      <dev:Pauseable>
        <dev:Duration>P1H</dev:Duration>
      </dev:Pauseable>*
    </wse:SubscribeResponse>
  </s:Body>
</s:Envelope>

Notice that we have extended the SubscribeResponse with a dev:Pauseable 
of our own because this is what the specification of the "pauseable 
extension" told us we MUST do. This behavior is not mandated by 
WS-Eventing, *nor should it be*. This gives us a hint as to how our 
Subscriber from Example 1 knew we didn't honor her request to engage the 
dreaded "time dilation" extension. It's likely (though we will never 
know because we can't seem to find the spec for this extension anywhere) 
that acceptance of the time dilation extension is signaled via some 
extension to SubscribeResponse but, because we have no interest in 
supporting this extension, we don't really care.

And so concludes Example 3.

- gp

p.s. Extra credit to anyone who can justify the asymmetry between the 
extension points in the Subscribe and SubscribeResponse messages.