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.
|