Re: Extension Handling 101: Example 3

Gil,

Yeah, I wondered if you were chasing something else.

On 14 Jul 2009, at 23:11, Gilbert Pilz wrote:

> 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.

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. 

Received on Wednesday, 15 July 2009 09:24:08 UTC