wsn message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsn] Controlling multiple subscriptions at once
- From: Steve Graham <sggraham@us.ibm.com>
- To: David Hull <dmh@tibco.com>
- Date: Thu, 5 Aug 2004 15:11:16 -0400
David:
Cool use case!
A couple of clarifying points, continued
discussion:
>I have a number
of subscriptions active, ...
In this case "I" means a subscriber?
One possible solution to manage the
subscriptions is to have your own collection of subscriptions (proxies
in some programming language), and allow this collection to receive certain
SubscriptionManager operations (java calls for example) and then iterate
through the collection issuing the corresponding message request to each
SubscriptionManager in the collection?
With regard to using IRP vs SubscriptionIDs,
I agree that there is no benefit to SubscriptionIDs.
With regard to "control message"
style topics, that was explicitly not a "goal" for WSN.
I am not sure if it would require charter modification.
sgg
++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++
| David Hull <dmh@tibco.com>
08/05/2004 12:26 PM
|
To:
wsn@lists.oasis-open.org
cc:
Subject:
[wsn] Controlling multiple subscriptions
at once |
Use case:
I have a number of subscriptions active, through various
"NotificationProducers" (say, a news source, a stock quote source,
latest baseball scores, flight information for my upcoming trip) and with
various consumers (my email, my cell phone, instant messaging via whatever
device is handy). At some point, I want to do something to all these
subscriptions at once (pause/resume/cancel, or maybe redirect the email
messages to a different email address, or whatever).
Currently, using the IRP, this would involve sending the appropriate message
to each "SubscriptionManager" involved. In this human-sized
use case, that might not be burdensome, but there should be similar but
more automated cases with larger numbers of subscriptions involved.
Using explicit subscription IDs probably doesn't help much, because there
are multiple NPs involved (and even with a single NP, different subscriptions
could have different subscription management endpoints, if only for load
balancing).
I don't know what WSDM could do here -- I need to come up to speed on that
a bit.
Possible Solution:
Use WSN. We would need some mechanism for a subscription
(whether specified as a single endpoint or as (manager endpoint, ID)) to
be able to accept control messages from a topic instead of just a request/response
connection. But with that in place, I only have to publish the control
message to the appropriate topic, and voila -- all the subscriptions will
hear it.
One possible mechanism would be to use the SubscriptionManager endpoints
as NotificationConsumers.
But how do I know if it worked? If I'm pausing a single subscription,
I'll get a response or fault back. But with multiple subscriptions,
I'll need to listen to an asynchronous stream of responses/faults (or if
there are many subscriptions, probably just faults, with success implied).
It just so happens we have a means of listening to an asynchronous stream
right at hand . . . just subscribe to a topic (or topic set). And
in fact, subject to security, anyone else can listen to the same topic
(or set) and find out when subscriptions are being modified or deleted.
Or when they're created, if we allow for that.
That said, I wouldn't want to require using WSN in such a situation.
I would prefer to have an administrative interface which uses notification
(with a small 'n') and which MAY do this notification via WSN.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]