Re: Extension Handling 101: Example 3

Dave,

Excellent analysis, but the asymmetry I was referring to was the fact 
that the wse:Subscribe element contains a wse:Delivery child that 
contains "the collection of rules and parameters for the conveyance of 
notification messages from source to sink", whereas the 
wse:SubscribeResponse element contains no such element. If you agree 
that it is good practice for Event Sources to indicate the acceptance of 
non-mU extension requests in wse:Subscribe via a corresponding extension 
(not necessarily of the same QName) to wse:SubscribeResponse, it seems 
strange the it is so vital to have a wse:Delivery element to hold 
request extensions, but there is no wse:Delivery element to hold the 
corresponding response extensions.

- gp

On 7/14/2009 11:46 AM, David Snelling wrote:
> Gil,
>
> On 08 Jul 2009, at 00:55, Gilbert Pilz wrote:
>
>> p.s. Extra credit to anyone who can justify the asymmetry between the 
>> extension points in the Subscribe and SubscribeResponse messages.
>
> It's like a red flag to a bull - I can't resist.
>
> After careful study of the specification for Pausable 
> at http://www.smalldevices.org/evt-ext, I discovered that the 
> designers didn't want to force the event source to queue more messages 
> than it thought it could support, so allowed the implementation of the 
> source to agree to a shorter pause interval. They also had the 
> foresight to provide a mechanism for the source to notify the consumer 
> that the maximum duration of the pause was not what they originally 
> requested. The gals at SmallDevices really do understand extensions 
> and how to use them.
>
> However, they were not so good on basic XML. The only unit of time 
> allowed is H (hours) and zero is not permitted. The poor event source 
> at StormWarning.com normally sends a nearly continuous stream of 
> information pertaining to storms and the cost of cloud based storage 
> for hours paused subscriptions may put them out of business.
>
>
>> 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.
>>
>>
>
> Take care:
>
>     Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
>     Fujitsu Laboratories of Europe Limited
>     Hayes Park Central
>     Hayes End Road
>     Hayes, Middlesex  UB4 8FE
>     Reg. No. 4153469
>
>     +44-7590-293439 (Mobile)
>
>
>
>
> ______________________________________________________________________
>
> Fujitsu Laboratories of Europe Limited
> Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE
> Registered No. 4153469
>
> This e-mail and any attachments are for the sole use of addressee(s) and
> may contain information which is privileged and confidential. Unauthorised
> use or copying for disclosure is strictly prohibited. The fact that this
> e-mail has been scanned by Trendmicro Interscan and McAfee Groupshield 
> does
> not guarantee that it has not been intercepted or amended nor that it is
> virus-free.
>