1. Thanks for explaining the role of Subscription Manager as a Producer Side Extraction.
Then simply delete all references to Subscription Manager in text below. As I noted, I thought the Subscription Manager was on the Consumer/Subscriber side. In fact, if there is no accepted definition of Subscription Manager, we should not use it in the Issues List.
2. The difference in use case 2 and 3 is that in 2. the Subscriber has experienced a transient failure and has recovered. However, in 3. the Subcriber has permanently failed and is replaced with a backup Subscriber that does not have a list of current subscriptions. These are different real world scenarios/ use cases. You observe correctly, that in both cases, the Subscriber needs to query the Notification Producer to re-populate it's data base of active subscriptions. Nonetheless, they are different use cases.
Hi Sanjay
Three use cases were provided in support of the Query capability between a Consumer/Subscriber/Subscription Manager and a Notification Producer/Broker:
[Note that in my view, the Subscription Manager and Subscriber are actually the same entity. The Subscriber and Consumer could also be the same entity, but the general case is that they are different entities with a local/ out of band interface between them. The message exchange between the Consumer and Subscriber/Subscription Manager is a local issue, not subject to standardization in WS-N specs]
<Sanjay> I believe the SubscriptionManager as per our current model is more of a provider side abstraction, and it does not so much fit in the mix of the Subscribers and Consumers on the client side. I think the SubscriptionManager and the NotificationProducer both live on he provider side an need to work hand in hand, in the sense that the SubscriptionManager interface is used for managing the space of active Subscriptions, which in turn is referenced by the NotificationProducer for identifying the recipients of Notifications.</Sanjay>
1. Subscribe Response or associated EPR is lost- either because that message was never received, or the Consumer did not get it from the Subscriber.
a] Consumer is receiving "unknown" Notification messages and either generates a Query Request, or (via out of band mechanisms) requests the Subscriber/Subscription Manager to query the Notification Producer/Broker to determine if the subscription is active.
b] A similar case is that the Subscriber/Subscription Manager sent a Subscribe Request, but never got back a Subscribe Response message. After a time-out, it Queries the Notification Producer/ Broker to see if the subscription was confirmed
<Sanjay>What identifier would the Subscriber use to query for the lost SubscribeRequest? I believe these kind of situations are usually handled by resending the SubscribeRequest for a few number of times (assuming idempotence!) and by raising an error to the application/administrator if there is still no response.</Sanjay>
2. Subscriber/Subscription Manager loses all state information, e.g. power fail then power restore. It has lost all information regarding subscriptions. Upon power-up/restart, it Queries the Notification Producer/Broker to get a list of active subscriptions and (optionally) the properties associated with them. [It had saved the EPR of the Notification Producer/Broker, and includes that in the Query request message]
3. Subscriber/Subscription Manager experiences a hard failure and is replaced by a "hot standby" Subscriber/Subscription Manager, which needs to populate it's data base of active subscriptions. After being activated and placed in service, the new Subscriber/Subscription Manager would then Query the Notification Producer/Broker to get a list of active subscriptions and (optionally) the properties associated with them.
<Sanjay> I am not sure I see the difference between the use cases 2 an 3 above. In both the cases, the Subscriber has failed and is trying to regain its state </Sanjay>
-----------------------------------------------------------------------------------------------------------------------------------
alan
Alan Weissberger
1 408 863 6042 voice
1 408 863 6099 fax
----- Original Message -----
From: "Patil, Sanjay"
Date: Sat, 7 Aug 2004 02:36:26 +0200
To: "'Alan Weissberger'" ,wsn@lists.oasis-open.org
Subject: RE: [wsn] Proposed text for System Management issue
Hi Alan,
I will update the issue as you suggested in the next revision.
Regarding the use cases, could you please send me a little detailed description (than what is currently in the minutes). Specifically, I am not very clear about -- whether you meant Subscriber instead of SubscriptionManager in the second use case, and what exactly do you mean by the hot standby in the third use case.
Thanks,
Sanjay
Hi Sanjay
Comment in line
----- Original Message -----
From: "Patil, Sanjay" <SANJAY.PATIL@SAP.COM>
Date: Fri, 6 Aug 2004 20:05:14 +0200
To: wsn@lists.oasis-open.org
Subject: [wsn] Proposed text for System Management issue
Please review.
Thanks,
Sanjay
WSN1.8: System Management for WS Notification
WS Notification TC to work on a new separate deliverable - a concrete specification for system management functions. This specification will define a WSDM specialization for managing NotificationProducers and NotificationBrokers.
AW: Instead of "WSDM specialization," which seems vague to me, I prefer:
"The specification will use WSDM mechanisms, methods, and procedures" for managing .......
In addition, add a sentence: "The specification will include a Query capability between Consumer/Subcribers and Notification Producers/ Brokers."
Note that I provided three use cases for this Query capability, which are recorded in the f2f minutes taken by Steve Graham.
-------------------------------------------------------------------------------------------------------------------------
alan
Alan Weissberger
1 408 863 6042 voice
1 408 863 6099 fax
Specifications
Proposed Recommendations
Notes
During London F2F on July 30, 2004, the above text for the issue was agreed upon while discussing the use cases raised by the email - http://www.oasis-open.org/archives/wsn/200407/msg00087.html
Status: Open
Date: July 30, 2004
Contact:
Alan Weissberger