[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
* NotificationBroker, not NotificationProducer, provides
RegisterPublisher
* It might be better to take out the links from NotificationBroker
that stem from it being a NotificationProducer (e.g.,
NotificationBroker creates PullPoint), especially since
* CreatePullPoint is OPTIONAL and does not belong to the
NotificationProducer interface proper. Actually, on closer
examination it's OPTIONAL for both NotificationProducer and
NotificationBroker, but in different ways. I'll raise an issue.
* I'm not completely sure what "NotificationProducer delegates
SubscriptionManager" means. NotificationProducer is a Factory for
SubscriptionManager, so "creates" might be better.
* Hmm ... do we really need both Subscription and
SubscriptionManager? I suppose we do, but they're 1-1 with each
other.
* Topic filtering is OPTIONAL and (except for GetCurrentMessage,
RegisterPublisher and the topic-related resource properties), on
an equal footing with ProducerProperties, MessageContent, and any
filters defined by extension. One way to reflect this would be to
rename the "Topic" box to "FilterExpression" and then hang Topic,
ProducerProperties, MessageContent, and (say) OtherFilter off of it.
* In any case, GetCurrentMessage implies some sort of special
relationship between NotificationProducer and Topic, and similarly
for RegisterPublisher.
* Many of the relationships, particularly those in BaseN, are
OPTIONAL. I'm not sure how best to show this, but it should be
shown. The only really REQUIRED relationships are that are in
BaseN are the ones involving only Subscriber, SubscribeRequest,
Notification, NotificationProducer, NotificationConsumer,
SubscriptionManager and Subscription. E.g. "Subscription
references Topic" is optional. Again, GetCurrentMessage implies a
certain weak relationship between NotificationProducer and Topic,
but a NotificationProducer is free to fault unconditionally on
GetCurrentMessage. This might best be handled by showing separate
diagrams for the core and various parts, then combining them in
the master diagram you have.
In any case, thanks for the work and for the resulting cross-check of
the design. IMHO we should keep this diagram around for the Primer.
>
>
> 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?
>
> 2. Is the pull point essentially a dynamic (push/pop) notification queue?
>
> Thanks,
>
> Dan
>
> -----Original Message-----
> *From:* Marchant, Dan R. [mailto:marchadr@wellsfargo.com]
> *Sent:* Thursday, September 08, 2005 11:45 AM
> *To:* David Hull; marchadr@wellsfargo.com
> *Cc:* wsn@lists.oasis-open.org
> *Subject:* RE: [wsn] Strawman: "virtual consumers"
>
> 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
>
>
>
>
> -----Original Message-----
> *From:* David Hull [mailto:dmh@tibco.com]
> *Sent:* Thursday, September 08, 2005 11:16 AM
> *To:* marchadr@wellsfargo.com
> *Cc:* wsn@lists.oasis-open.org
> *Subject:* Re: [wsn] Strawman: "virtual consumers"
>
> 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
>>
>>
>>
>> -----Original Message-----
>> *From:* David Hull [mailto:dmh@tibco.com]
>> *Sent:* Friday, September 02, 2005 2:43 PM
>> *To:* wsn@lists.oasis-open.org
>> *Subject:* [wsn] Strawman: "virtual consumers"
>>
>> 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.
>>
>
--Boundary_(ID_ZH8i7LxHrrhBVDpLtq+dWg)
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<a class="moz-txt-link-abbreviated" href="mailto:marchadr@wellsfargo.com";>marchadr@wellsfargo.com</a> wrote:
<blockquote
cite="mid531A208962023843A1ED72F2785D162BCA27C1@msgswbmnmsp25.wellsfargo.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; ">
<title></title>
<meta content="MSHTML 6.00.2800.1515" name="GENERATOR">
<div><font color="#008080" face="Arial" size="2"><span
class="664571215-09092005">David,</span></font></div>
<div><font color="#008080" face="Arial" size="2"><span
class="664571215-09092005"></span></font> </div>
<div><font color="#008080" face="Arial" size="2"><span
class="664571215-09092005">I put together composite diagram to
illustrate the holistic view of the notifications framework.</span></font></div>
<div><font color="#008080" face="Arial" size="2"><span
class="664571215-09092005">Let me know if it is accurate or I am
missing anything.</span></font></div>
</blockquote>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]