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"
<SANJAY.PATIL@SAP.COM>
Date: Sat, 7 Aug 2004 02:36:26 +0200
To: "'Alan
Weissberger'" <AJWDCT@TECHNOLOGIST.COM>,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"
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