Replies inline (anyone else remember the pre-MsOutlook days when
"replies inline" was the default?)
Steve Graham wrote:
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?
Yes. I was deliberately personifying because the human-based example
seemed more concrete and easier to grasp.
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?
The idea here is to save messages on the wire. That is, I'd like to
send one physical message to a control endpoint for "all my
subscriptions". Of course, this only saves if setting it up doesn't
take too many messages. On could imagine -- but I'm not necessarily
recommending it -- that each Subscribe request could carry a
"subscription group" cookie, meaning "I want to be able to address this
subscription via this subscription group".
My feeling here is that trying to anticipate such use cases is a
rathole, in that we're unlikely to come up with a plausible mechanism
that will cover everything. Part of the point of the use case I gave
is that it's easy to add a condition ("different NP's, different
consumer EPRs . . .") to defeat any particular approach (NP manages
subscription groups, query by consumer EPR).
But on the other hand, a particular deployment may have the necessary
magic already lying around. E.g., there might be some other channel by
which I can manage delivery of my email, cell and IM. So it may be
useful to define a standard way for a subscriber to say (to whom??) "do
this to all these subscriptions at once" without requiring that
deployments support such capabilities.
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.
That's definitely not base notification. I still think it's useful to
consider, though, as a possible use case for WSN.
sgg
++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++
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.
|