[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsn] Strawman: "virtual consumers"
marchadr@wellsfargo.com wrote: > See comments. Ditto. > -----Original Message----- > *From:* David Hull [mailto:dmh@tibco.com] > *Sent:* Friday, September 09, 2005 10:43 AM > *To:* marchadr@wellsfargo.com > *Cc:* wsn@lists.oasis-open.org > *Subject:* Re: [wsn] Strawman: "virtual consumers" > > 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. > > From a somewhat brief first look, this looks pretty good. A > couple of points: > > * NotificationBroker, not NotificationProducer, provides > RegisterPublisher > [Marchant, Dan R.] I'll updated it > * 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. > [Marchant, Dan R.] I may just put some carnality on it 1 to > 0..1? > I would prefer refactoring slightly so that the PullPoint stuff appears only on NP, but NB brings it in because NP is one of NB's roles. BTW I normally wouldn't correct a typo, but since you use also use it below, you probably mean "cardinality" and not "carnality" :-). > * > > > * I'm not completely sure what "NotificationProducer delegates > SubscriptionManager" means. NotificationProducer is a > Factory for SubscriptionManager, so "creates" might be better. > [Marchant, Dan R.] I interpreted the Subscription Manager as > another service that can be managed elsewhere. I was under > the impression that the NotificationProducer can provide the > SubscriptionManager functionality or "delegate" it to a > Subscription Manager service > Aha. All that means is that the physical /process /providing the NP service may or may not also provide the SM service. Put another way, the [address] component of the SM endpoint may or may not also be the address of the NP. From an object modeling perspective, the NP /object/ probably doesn't delegate to the SM /object/ in any meaningful way. > * > > > * Hmm ... do we really need both Subscription and > SubscriptionManager? I suppose we do, but they're 1-1 with > each other. > [Marchant, Dan R.] I thought there can be multiple > Subscriptions hence the reason to even have a Subscription > Manager? My impression was the Subscription was > per Subscriber that is subscribe to a particular > Notification Producer > This has been a pet peeve of mine. There is one SM per subscription. The SM is basically the Subscription (resource)'s manifestation as a web service. If that makes any sense. > * > > > * 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. > [Marchant, Dan R.] Good idea I will update the diagram with > this. > * In any case, GetCurrentMessage implies some sort of special > relationship between NotificationProducer and Topic, and > similarly for RegisterPublisher. > [Marchant, Dan R.] I'll look through the docs again to see > what is the best way to illustrate this. > * 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. > [Marchant, Dan R.] Carnality is a good way to do that. > I think just using cardinality loses the information that the various subsystems form coherent wholes themselves. It also doesn't reflect the various interfaces. If I say that an NP may create zero or more PullPoints (if I understand you correctly), that doesn't say that the NP interface can run just fine without supporting CreatePullPoint. I'm pretty sure this was our intention. > 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. >>> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]