Re: Extension Handling 101: Example 3

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.