marchadr@wellsfargo.com wrote:
David,
I put together composite diagram to
illustrate the holistic view of the notifications framework.
Let me know if it is accurate or I am
missing anything.
Also a couple more questions about the pull
point:
1. If a pull point is created on a
notification producer does this imply the messages of the notification
producer are not guaranteed to be there?
Or does the pull point have its own
message cache so to speak to pull from?
I'm not sure I understand that completely, but perhaps the next answer
may help.
2. Is the pull point essentially a dynamic
(push/pop) notification queue?
Not necessarily, or at least not quite. We deliberately don't
constrain its semantics to first-in-first-out, nor even require that
any messages sent to it be kept. All of this may be further
constrained by policy assertions (the great rug under which all things
are swept). The pull point is probably best thought of as a container
for whatever messages are sent to it, which delivers messages it has
accumulated (according to its policies) on demand. It should not
accumulate messages other than those it receives in its
NotificationConsumer role, and it may choose not to accumulate even
those. Naturally, realistic implementations will at least make a best
effort to accumulate a useful set of messages, but there are any number
of ways to define "best effort" and "useful set of messages", so we
leave it unconstrained in the core.
A NotificationProducer may allow the same PullPoint to be used in
multiple subscribe requests, in which case the pull point will
accumulate messages from all relevant subscriptions. In such a case,
it may not even notice that the messages are from different
subscriptions. Its core function is just to accumulate messages and
deliver them on demand. Again, it is the NotificationProducer, and not
the PullPoint, that does the filtering.
Please keep the questions coming. If nothing else, this is clarifying my
thinking, which fills a need in and of itself.
Thanks,
Dan
David,
Thanks this is helpful.
It might be nice to see a high-level diagram
showing how all the parts interact.
Maybe I will throw one together later this week
or early next week for you review.
Thanks,
Dan
marchadr@wellsfargo.com
wrote:
Some quick comments/questions:
1. In the brokered Notification 1.3
spec, there are references to a Publisher is this the same concept of
the Notification Producer?
Should there be some standardization of
terms, Producer is a publisher and visa versa?
A NotificationProducer accepts subscription requests and creates
Subscriptions. That is, it supports the SubscribeRequest operation and
the others in the NotificationProducer interface. A
NotificationProducer may relay Notification messages from some other
source, or it may create them itself. In either case "producing" a
message means handing it off to some delivery mechanism appropriate for
the NotificationConsumer specified in the subscription request.
A Publisher may send notifications whether or not there is known to be
interest. It need not support any particular interface. It uses
the RegisterPublisher interface.
The commonality is that both MAY send messages in Notify format, and
that is captured by the NotificationConsumer interface. The
SubscribeRequest to a NotificationProducer will contain a reference to
a NotificationConsumer. A NotificationBroker is-a
NotificationConsumer. A Publisher sends messages to a
NotificationBroker, which is-a NotificationConsumer.
I'm afraid that may only have clouded the picture, but I believe it's
at least true.
2. Should a producer be part of a Topic
Space? It seems the only reference to a topic space is the grouping of
topics, is there anything associated with a topic space other then a
topic tree?
A NotificationProducer MAY support filtering by topic, meaning that it
allows subscriptions for a particular set of topics.
The OPTIONAL Topic element of the RegisterPublisher request says which
Topics the Publisher wishes to publish to. The NotificationBroker may
refuse to register a publisher if it doesn't support the Topic.
Again, the answer depends on whether we are talking about
NotificationProducers (things that accept subscription requests) or
Publishers (things that send Notifications for whatever reason).
3. Should there be a way to filter specific
Message Types of a Topic? What if as a subscriber/consumer I only can
handle one of the message types within a topic?
Maybe this is part of the Topic
Expression?
This can be done through the Filter/MessageContent element of the
subscription request.
4. Can a pull point defining a specific set
of subscriptions? Do they get anything that is sent to them or do they
filter and subscribe to specific topics?
A pull point acts just like any other NotificationConsumer. In the
subscription request(s), you specify what message you want put into the
pull point, just like any other subscription. In other words, the
NotificationProducer does the filtering for all subscription requests,
including those which are directed to pull points.
5. Would the pull point notification be
considered a brokered notification, since the pull point is acting like
a broker in some ways?
The pull point is not acting as a broker, at least in that it doesn't
support RegisterPublisher or any other NotificationBroker interface. A
broker is basically the combination of a NotificationConsumer and
NotificationProducer, optionally with publisher registration. That is,
it can accept Notification messages (NotificationConsumer), push them
back out based on subscriptions made (NotificationProducer), and
optionally keep track of whose Notification messages it is handling
(RegisterPublisher etc.) A notification broker MAY support
CreatePullPoint, just like any other NotificationProducer.
A pull point, by contrast, accepts notification messages
(NotificationProducer) and allows them to be pulled out one by one
(PullPoint).
Note that the PullPoint's GetMessages operation is a destructive read
of possibly more than one message, while NotificationConsumer's
GetCurrentMessage operation is a non-destructive read of a single
message. I say this because it might appear that since
NotificationBroker can accept Notify messages and supports
GetCurrentMessage, it's essentially the same as a pull point. The
similar names, GetCurrentMessage and GetMessages, may be a source of
confusion.
Hope this helps.
Sorry if this is rehashing existing
questions.
Thanks,
Dan
Attached please find a revision of the current committee draft, as per
my action item from the last conference call. Change tracking is
turned on, so it should be easy to see what I've done. There are two
main changes, and a few more following from those (and perhaps a few
more such changes that I've missed):
- I've added this bullet item to the
definition of NotificationConsumer in section 2: "A Notification
Producer may be a physical web service, capable of receiving messages
over a network, or may be a virtual endpoint known only to a
given set of NotificationProducers. For example, the
"Pull Points" described in section 5 may be virtual. In
either case, the NotificationProducer will use the
NotificationConsumer, together with other information in a subscription
request, to effect the desired handling of Notifications, or will fault
if this is not possible."
- I've changed the first sentence of
section 5.1.1 (accumulating Notification messages) from "The PullPoint
interface supports the NotificationConsumer interface (as defined in
section
3)."
to "A PullPoint produced by the CreatePullPoint method MAY support the
NotificationConsumer interface (as defined in section
3)."
This may or may not imply changes to the WSDL, and we should discuss
this.
My natural inclination is to be a bit nervous of introducing a
"physical/virtual" distinction here, but I believe that such a
distinction is already implicit, and introducing it does not require
massive changes to either the semantics or the text describing the
semantics. Indeed, one could argue that it simply changes the text to
make the implications of the existing semantics more explicit.
In any case, the proposed text is very much open to further discussion,
and may well prove not to be the best way forward.
|