- From: Gilbert Pilz <gilbert.pilz@oracle.com>
- Date: Tue, 22 Sep 2009 08:24:32 -0700
- To: Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>
- CC: "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
- Message-ID: <4AB8EC30.1070605@oracle.com>
It's true that the Event Source decides on the duration of the
Subscription expiry, but it is also true that the Event Sink decides
whether it is or isn't willing to live with what it is that the Event
Source decided. An Event Sink can send an Unsubscribe for any reason and
one of these reasons could be that it is unwilling to live with the
expiry that the Event Sink has chosen. Negotiating expiration duration
by an "Event Source proposes - Even Sink accepts or rejects via
Unsubscribe" is both inefficient and unworkable (what if the Event
Source never picks an expiration duration that the Event Sink likes?) A
much better process is for the Subscriber/Event Sink to *very clearly*
and *unequivocally* communicate the constraints it is willing to work
within and allow the Event Sink to either reject the request or pick
some expiration that fits within those constraints.
- gp
On 9/22/2009 6:44 AM, Ram Jeyaraman wrote:
>
> The general model is that the event source should decide on the
> duration of subscription expiry. This is because the event source may
> have specific policies or limits applied to each subscription due to
> resource limits or the number of event subscribers it needs to
> support. The event subscriber cannot always assume success, meaning,
> it may not always get what it asks for, and hence it has to be coded
> defensively. This is generally true of any network based application.
>
>
>
> Do you think the specification could make this clearer by anointing
> the event source as the entity empowered to make the decision about
> subscription expiry duration? And perhaps leave the expiry duration
> requested in the Subscribe request by the event subscriber as a hint?
>
>
>
> This allows for resilient defensive programming on the part of the
> event subscribers against failures and results in better end user
> experience.
>
>
>
> Thanks.
>
>
>
> *From:* 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 11:09 AM
> *To:* 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 Tuesday, 22 September 2009 15:25:27 UTC