This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 9613 - Eventing: Support WS-Management's persistent subscriptions
Summary: Eventing: Support WS-Management's persistent subscriptions
Status: CLOSED REMIND
Alias: None
Product: WS-Resource Access
Classification: Unclassified
Component: Eventing (show other bugs)
Version: LC
Hardware: All All
: P2 enhancement
Target Milestone: ---
Assignee: Gilbert Pilz
QA Contact: notifications mailing list for WS Resource Access
URL:
Whiteboard:
Keywords: externalComments
Depends on:
Blocks:
 
Reported: 2010-04-28 22:19 UTC by Gilbert Pilz
Modified: 2010-07-28 09:11 UTC (History)
2 users (show)

See Also:


Attachments

Description Gilbert Pilz 2010-04-28 22:19:47 UTC
The WS-Man WG has identified the need for persistent subscriptions in WS-Eventing. A persistent subscription is a subscription that is guaranteed (by the Event Source) to survive such occurrences as the shutdown/restart of the Event Source's container, the shutdown/restart of the Event Source's VM, or the reboot of the device hosting the Event Source. Although any Event Source is allowed to provide such a quality of service in the current specification, the important aspect of this feature is the Subscribers knowledge of this guarantee.

It is the opinion of the WS-Man WG that this feature is sufficiently general as to warrant inclusion in the base specification.

---

Proposal:

1. Add an optional element to the wse:Subscribe element (e.g. wse:Persistent) that indicates that the Subscriber is requesting a persistent subscription.

2. Create a new fault that MUST be generated by the Event Source if that Event Source is unable/unwilling to create a persistent subscription in the face of a request to do so.

3. Add a parameter to the wse:EventSource assertion that indicates the endpoints ability to create persistent subscriptions.

4. Define a mechanism to allow a client to specify whether the request should be performed with or without the use of this feature in a way similar to the way mustUnderstand works.

[1] http://www.dmtf.org/standards/published_documents/DSP0226_1.1.pdf
Comment 1 Robert Freund 2010-05-11 21:15:20 UTC
Add to end of sec 4.5 ", if possible"

add to the end of the 2nd para in sec 4
.. via a SubscriptionEnd message if an EndTo was present in the Subscribe message.
Comment 2 Tom Rutt 2010-05-11 21:40:27 UTC
Proposed WG Response to Originator:

WS-RA WG Response to originator of Bug 9613: Eventing: Support WS-Management's persistent subscriptions

The WS-RA WG considered the WS-Management Last Call comment, 
Logged as Bug 9613.

Persistence is a difficult topic.  For example, we do not understand 
why an event source which can handle persistence of subscriptions 
would not persist all of its subscriptions.

We see this as a quality of service concern, and after due consideration, 
we have decided that ways to accommodate such concerns are domain 
specific and outside the scope of the WS-RA work.

These kind of Quality of service concerns should be dealt with in an 
implementation or domain specific manner.  For example, a management workstation could be able to determine the kind of event sources it is 
dealing with, and have a table in its own state to know whether each event 
source supports persistence of its subscriptions. 

However, our discussions made us realize that the spec needs a 
clarification regarding the possibility of an event source / subscription 
manager going down before it can send a subscription End message to an 
EndTo epr.

We agreed to close this Bug with the following changes to the WS-Eventing specification:

Add , if possible. to the end of the first paragraph of 4.5 Subscription End

add the following to end of 2nd para in section 4:
via a SubscriptionEnd message if an EndTo was present in the Subscribe 
message.
Comment 3 Robert Freund 2010-06-08 17:41:44 UTC
2010-06-01
Discussed with Rich Landau of Dell who attended as an observer.
WG confirmed close with no action after arguments concerning difficulty of defining persistence in a non-domain specific manner.