W3C home > Mailing lists > Public > public-ws-resource-access@w3.org > September 2009

Re: proposal for 7478

From: Gilbert Pilz <gilbert.pilz@oracle.com>
Date: Wed, 30 Sep 2009 13:09:15 +0100
Message-ID: <4AC34A6B.7050808@oracle.com>
To: Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>
CC: "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Such a constrained device probably wouldn't work correctly in a complex 
environment in which there was no expectation that any of the Event 
Sources of interest could support the desired expiration time, but 
that's not a valid constraint for this use case.

- gp

On 9/30/2009 12:10 PM, Ram Jeyaraman wrote:
>
> Ø  The use case for minimum expiry time's is an Event Sink on a 
> constrained device that seeks to optimize the number of Subscriptions 
> that it can support. If you imagine such an Event Sink attempting to 
> support hundreds of Subscriptions it is clear that, if each 
> Subscription requires the Sink to renew every 30 seconds, most of the 
> device's bandwidth will be taken up in issuing and processing 
> Renew/RenewResponse messages
>
>  
>
> What would such a constrained device do when it lives in a complex 
> environment where there are no prior controls or knowledge of event 
> sources in that environment? Specifically, what would it do when it 
> does not find any event source that is willing to offer the requested 
> expiry time?
>
>  
>
> *From:* public-ws-resource-access-request@w3.org 
> [mailto:public-ws-resource-access-request@w3.org] *On Behalf Of *Ram 
> Jeyaraman
> *Sent:* Wednesday, September 30, 2009 11:40 AM
> *To:* Gilbert Pilz
> *Cc:* public-ws-resource-access@w3.org
> *Subject:* RE: proposal for 7478
>
>  
>
> Ø  <gp>This simply isn't true. A Subscriber can always choose to send 
> a Subscribe message without an Expires element. To quote the proposal:
>
> A Subscriber MAY indicate that it is willing to accept a Subscription 
> with any expiration time by omitting this element from the Subscribe 
> request.
>
> </gp>
>
>  
>
> Indeed. I was incorrect in my characterization about the event 
> subscriber being rigid in the newly proposed approach. Thanks for the 
> correction.
>
>  
>
> However, unless I am misinterpreting the proposal – it does NOT 
> provide a way for the event subscriber to provide a hint to the event 
> source about how much expiry time it desires. This is useful 
> information that will help the event source decide on how much expiry 
> time to grant. This is because the granted expiry time is a function 
> of the requested time and what could be reasonably granted by the 
> event source in real-time.
>
>  
>
> Thanks.
>
>  
>
> *From:* Gilbert Pilz [mailto:gilbert.pilz@oracle.com]
> *Sent:* Wednesday, September 30, 2009 9:52 AM
> *To:* Ram Jeyaraman
> *Cc:* public-ws-resource-access@w3.org
> *Subject:* Re: proposal for 7478
>
>  
>
> Comments inline . . .
>
> On 9/30/2009 1:26 AM, Ram Jeyaraman wrote:
>
> Here are some pros and cons of the existing and newly suggested 
> approaches.
>
>  
>
> Existing approach:
>
>  
>
> Pros
>
> Allows for building event subscribers in a complex environment where 
> the quality of service or capabilities of the event source are not 
> known /a priori/. That is, the event subscriber is adaptive and can 
> survive in complex environments where there is no control over or 
> knowledge of what the event source can offer in real-time.
>
> Cons
>
> The event subscriber does not receive the requested expiry time and it 
> cannot live with a shorter expiry time, it would need to unsubscribe. 
> This is not a functional issue but incurs an extra message.
>
>  
>
> Newly suggested approach:
>
>  
>
> Cons
>
> This does not adequately support the non-managed use case where the 
> event subscriber does not know about the quality of service or 
> capabilities of the event source /a priori/. This has the side-effect 
> of creating event subscribers that are very rigid and demanding in 
> their behavior.
>
> <gp>This simply isn't true. A Subscriber can always choose to send a 
> Subscribe message without an Expires element. To quote the proposal:
>
> A Subscriber MAY indicate that it is willing to accept a Subscription 
> with any expiration time by omitting this element from the Subscribe 
> request.
>
> </gp>
>
> Pros
>
> The subscription request fails-fast, that is, it is rejected when the 
> requested expiry time cannot be granted. This is an optimization. This 
> means that the event subscriber need not have to unsubscribe if it 
> decides not to keep the offered subscription with a less than 
> requested expiry time.
>
>  
>
> Observations:
>
>  
>
> The proposed new approach while it optimizes for the case where the 
> event subscriber does not want to keep a subscription with a 
> lesser-than-requested expiry time, it takes away the adaptability of 
> the event subscribers to complex environments.
>
> <gp>In the proposal for 7478, the Subscriber is allowed three choices: 
> (1) I don't care what the expiration is, (2) I would like a specific 
> expiration period, (3) I would like a Subscription that never expires. 
> Since this provides more flexibility than the Member Submission, I 
> fail to see how this "takes away" adaptability.</gp>
>
>  
>
> Question:
>
>  
>
> It is not clear to me why an event subscriber must always want at 
> least the minimum request expiry time to be granted. What is wrong 
> with sending an unsubscribe if the granted expiry time is not 
> sufficient or renewing to ask for more time? What is the need to 
> require such exact expiry times?
>
> <gp>Again, it's not true the Subscriber "must always want at at least 
> the minimum request expiry time to be granted". The fact that you 
> think this is the case leads me to believe that you really don't 
> understand the proposal. The proposal *allows* the Subscriber to ask 
> for a minimum request expiry time, but that is only one of the three 
> options outlined above.
>
> The use case for minimum expiry time's is an Event Sink on a 
> constrained device that seeks to optimize the number of Subscriptions 
> that it can support. If you imagine such an Event Sink attempting to 
> support hundreds of Subscriptions it is clear that, if each 
> Subscription requires the Sink to renew every 30 seconds, most of the 
> device's bandwidth will be taken up in issuing and processing 
> Renew/RenewResponse messages.</gp>
>
>  
>
> While I appreciate the thought and effort behind the proposed new 
> approach, my preference is to retain the existing approach.
>
>  
>
> On the other hand, if there is a compelling use case for optimizing 
> the protocol for the case where the event source does not want to keep 
> a subscription with less-than-requested expiry time, I am willing to 
> consider the approach that Doug suggested earlier:
>
>  
>
> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Sep/0047.html 
>
>
>  
>
> 2 - we need to make sure that the subscriber tells the source what it 
> expects w.r.t. the new subscription.  This means that when it asks for an
>
> expires time it needs to not only tell it the duration/dateTime, but 
> it should also indicate whether this is an upper limit or a lower 
> limit, or
>
> even just a suggestion.  Perhaps a new attribute on the Expires 
> element to indicate this would do it.  W/o this flag I don't think we 
> can get the
>
> level of interop we want by sticking with the current "random" expires 
> time approach.
>
>  
>
> This allows the event subscriber to be adaptive while simultaneously 
> providing the opportunity to fail-fast a subscription.
>
>  
>
> Thanks.
>
>  
>
> *From:* public-ws-resource-access-request@w3.org 
> <mailto:public-ws-resource-access-request@w3.org> 
> [mailto:public-ws-resource-access-request@w3.org] *On Behalf Of 
> *Gilbert Pilz
> *Sent:* Friday, September 11, 2009 7:09 PM
> *To:* public-ws-resource-access@w3.org 
> <mailto:public-ws-resource-access@w3.org>
> *Subject:* proposal for 7478
>
>  
>
> Notes:
>
> 1.) We've removed the use of xs:dateTime for specifying expiration 
> time. The reason for this is that the submission spec allowed Event 
> Sources that didn't have a wall clock to fail on the use of 
> xs:dateTime. This creates an interoperability problem because a 
> Subscriber has no way of knowing whether or not an Event Source can or 
> can't support xs:dateTime. An interoperable Subscriber must always be 
> capable of falling back to the use of xs:duration, so we might as well 
> just use that. Furthermore, some members of the WG have indicated that 
> they would prefer xs:duration over xs:dateTime because the former was 
> simpler to deal with (one example cited the problems of xs:dateTime's 
> that lack any timezone designation, etc.) This simplifies the parsing 
> for wse:Expires since it is now just a restriction of a xs:duration 
> and no longer a xs:union. The InvalidExpirationTime fault is no longer 
> necessary and has been removed.
>
> 2.) The existing text for /wse:SubscribeResponse/wse:Expires implies 
> that this element is optional ("if this element does not appear") 
> whereas the schema indicated that this element is mandatory. This 
> proposal changes the schema to indicate that Expires is an optional 
> element for SubscribeResponse.
>
> 3.) The presence/absence of wse:Expires has a different meaning for 
> wse:Subscribe then in does for wse:SubscribeResponse. For 
> wse:Subscribe it means "I don't care what expiration value you give 
> me". For wse:SubscribeResponse it means "the newly created 
> Subscription does not expire". Although this may seem little weird at 
> first, it is consistent with the negotiation model.
>
> 4.) This proposal includes the appropriate changes to Renew, 
> RenewResponse, GetStatusResponse as well as changes to examples.
>
> - gp
>
> ------------------------------------------------------------------------
>
> Change the outline of Subscribe to the following:
>
> *[Action]*
>   http://www.w3.org/2009/02/ws-evt/Subscribe
>
> *[Body]*
>   <wse:Subscribe ...>
>     <wse:EndTo> endpoint-reference </wse:EndTo> ?
>     <wse:Delivery ...> xs:any* </wse:Delivery>
>     <wse:Format Name="xs:anyURI"? > xs:any* </wse:Format> ?
>     <wse:Expires> xs:duration </wse:Expires> ?
>     <wse:Filter Dialect="xs:anyURI"? ...> xs:any* </wse:Filter> ?
>     xs:any*
>   </wse:Subscribe>
>
> Change the description of /wse:Subscribe/wse:Expires to the following:
>
> *[Body]/wse:Subscribe/wse:Expires*
>
> This optional element can be used by the Subscriber to negotiate the 
> expiration time of the requested Subscription.
>
> A Subscriber MAY indicate that it is willing to accept a Subscription 
> with any expiration time by omitting this element from the Subscribe 
> request.
>
> A Subscriber MAY request a Subscription with a minimum expiration time 
> by including this element in the Subscribe request with a positive 
> xs:duration value that specifies the minimum time between the 
> Subscription's creation time (based on the Event Source's clock) and 
> the time of its expiration. If the Event Source creates a Subscription 
> from such a Subscribe request, the expiration time of the Subscription 
> MUST be equal to or greater than the time indicated by the value of 
> this element, or the Subscription MUST NOT expire. If the Event Source 
> does not honor the requested minimum expiration time, the request MUST 
> fail, and the Event Source MUST generate a wse:ExpirationTimeExceeded 
> fault.
>
> A Subscriber MAY request a Subscription that never expires by 
> including this element with an xs:duration value of zero 
> ("P0Y0M0DT0H0M0S"). If the Event Source creates a Subscription from 
> such a Subscribe request, the Subscription MUST NOT expire. If the 
> Event Source does not honor a request for a Subscription that does not 
> expire, the request MUST fail, and the Event Source MUST generate a 
> wse:ExpirationTimeExceeded fault.
>
> ------------------------------------------------------------------------
>
> Change the outline of SubscribeResponse to the following:
>
> [Action]
>   http://www.w3.org/2009/02/ws-evt/SubscribeResponse
>
> [Body]
>   <wse:SubscribeResponse ...>
>     <wse:SubscriptionManager>
>       wsa:EndpointReferenceType
>     </wse:SubscriptionManager>
>     <wse:Expires> xs:duration </wse:Expires> ?
>     xs:any*
>   </wse:SubscribeResponse>
>
> Change the description of /wse:SubscribeResponse/wse:Expires to the 
> following:
>
> *[Body]/wse:SubscribeResponse/wse:Expires*
>
> This optional element is used to communicate the assigned expiration 
> time of the newly created Subscription. The absence of this element in 
> a SubscribeResponse indicates that the Subscription will not expire; 
> i.e. the Subscription has an indefinite lifetime.
>
> If the Subscribe request did not contain a wse:Expires element and 
> this element occurs in the SubscribeResponse, it MUST have a positive 
> xs:duration value.
>
> If the Subscribe request contained a wse:Expires element with a 
> positive xs:duration value and this element occurs in the 
> SubscribeResponse, it  MUST have a xs:duration value that is equal to 
> or greater than the request value.
>
> If the Subscribe request contained a wse:Expires element wtih the a 
> zero value ("P0Y0M0DT0H0M0S"), this element MUST NOT appear in the 
> SubscribeResponse.
>
> Note that, regardless of its expiration time, a Subscription MAY be 
> terminated by the Event Source at any time for reasons such as 
> resource constraints, or system shut-down.
>
> ------------------------------------------------------------------------
>
> Fix Example 4-1 and Example 4-2 to use an xs:duration value for their 
> respective wse:Expires elements making sure that the above 
> restrictions are adhered to.
>
> ------------------------------------------------------------------------
>
> Change the outline of Renew to the following:
>
> [Action]
>   http://www.w3.org/2009/02/ws-evt/Renew
>
> [Body]
>   <wse:Renew ...>
>     <wse:Expires> xs:duration </wse:Expires> ?
>     xs:any*
>   </wse:Renew>
>
> ------------------------------------------------------------------------
>
> Change the outline of RenewResponse to the following:
>
> [Action]
>   http://www.w3.org/2009/02/ws-evt/RenewResponse
>
> [Body]
>   <wse:RenewResponse ...>
>     <wse:Expires> xs:duration </wse:Expires> ?
>     xs:any*
>   </wse:RenewResponse>
>
> Change the description of /wse:RenewResponse/wse:Expires to the following:
>
> This optional element is used to communicate the assigned expiration 
> time of the newly renewed Subscription. The start of this duration is 
> the time when the Subscription Manager started processing the Renew 
> request.
>
> ------------------------------------------------------------------------
>
> Fix Example 4-3 and Example 4-4 to use an xs:duration value for their 
> respective wse:Expires elements.
>
> ------------------------------------------------------------------------
>
> Change the outline of GetStatusResponse to the following:
>
> [Action]
>   http://www.w3.org/2009/02/ws-evt/GetStatusResponse
>
> [Body]
>   <wse:GetStatusResponse ...>
>     <wse:Expires> xs:duration </wse:Expires> ?
>     xs:any*
>   </wse:GetStatusResponse>
>
> ------------------------------------------------------------------------
>
> Fix Example 4-6 to use an xs:duration value for the wse:Expires element.
>
> ------------------------------------------------------------------------
>
> Change the schema definition of the "ExpirationType" to the following:
>
>   <xs:simpleType name="ExpirationType">
>     <xs:restriction base="xs:duration">
>       <xs:minInclusive value="P0Y0M0DT0H0M0S" />
>     </xs:restriction>
>   </xs:simpleType>
>
> Change the definition of SubscribeResponse to:
>
>   <xs:element name="SubscribeResponse">
>     <xs:complexType>
>       <xs:sequence>
>         <xs:element name="SubscriptionManager"
>                     type="wsa:EndpointReferenceType" />
>         <xs:element name="Expires"
>                     type="tns:ExpirationType"
>                     minOccurs="0" />
>         <xs:any namespace="##other" processContents="lax"
>                 minOccurs="0" maxOccurs="unbounded" />
>       </xs:sequence>
>       <xs:anyAttribute namespace="##other" processContents="lax" />
>     </xs:complexType>
>   </xs:element>
>
> ------------------------------------------------------------------------
>
> Add the following fault to Section 6:
>
> 6.x ExpirationTimeExceeded
>
> This fault is generated when a Subscribe request specifies a minimum 
> expiration time that exceeds what the Event Source is willing to 
> support. This includes requests that use a zero xs:duration value to 
> specify an infinite expiration time.
>
> *[Code]*
>
> 	
>
> s12:Sender
>
> *[Subcode]*
>
> 	
>
> wse:ExpirationTimeExceeded
>
> *[Reason]*
>
> 	
>
> The requested expiration time exceeds internal limits
>
> *[Code]*
>
> 	
>
> /Optional xs:duration which specified the maximum expiration time 
> supported by the Event Source./
>
>  
>
> ------------------------------------------------------------------------
>
> Remove Section 6.2 "InvalidExpirationTime".
>
> Remove Section 6.3 "UnsupportedExpirationType".
>


Received on Wednesday, 30 September 2009 12:09:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 18:18:13 GMT