Re: [wsn] Pull-type notification

[David Snelling <David.Snelling@UK.Fujitsu.com>]

William,

I general +1 to all of this.

There was one thought I had during the meeting (it was actually during 
RF, so I didn't mention at the time).

There is a simple way to address the single operation issue. The real 
reason we need a different operation is the fact the the Pull requires 
two EPRs in the response. One approach is, to include a pull flag in 
the standard subscribe message. Its just a boolean after all (and yes I 
know all about control coupling, but we also want t sparse interface). 
Then the subscription contains an RP containing the Pull EPR. The other 
RPs could be optional (buffer length etc), but this one would be 
required.

The only drawback, is that Pull would require the use of RP.

That's my two cents.


On 5 Feb 2005, at 0:27, Vambenepe, William N wrote:

> Hi all,
>
> Thanks Steve for the "pull-type" proposal and thanks Matt for the
> excellent minutes on 2/2, they made me feel like I was in the room for
> the "pull-type" discussion.
>
> Since there was no final decision on the "pull-type" question and since
> I am very interested in this issue (as the person who initially raised
> it), I would like to send some comments on Steve's proposal and on the
> discussion that took place.
>
> I think we need to put in place a simple, self-contained and useful
> mechanism in BaseNotif. Advanced features should be pushed to
> specialized policy statements and/or extension specs. So I agree for
> example with the group that a generic queueing mechanism is out of 
> scope
> for us but if/when someone comes up with it people should be able to 
> use
> it in conjunction with our "pull-type" support.
>
> Specifically, I think we can simplify our task in BaseNotif by not
> worrying about buffer size and buffer utilization. We have to recognize
> that of course the providers of "pull-type" subscription will have
> limits in how many messages they can store and they might have to drop
> old ones. But advanced support for this (such as being able to 
> advertise
> quality of service on your persistence and/or exposing how much of your
> buffer is currently used) is best left outside of BaseNotif.
>
> As a result, I would like to modify Steve's proposal by
>
> - Removing the MaxBufferSize and CurrentBufferSize properties
> - Removing the BufferSize attribute in the subscription request
>
> Basically, when I subscribe I know that not all messages will be
> persisted for ever and that the notification producer will do its best
> but doesn't guarantee anything. Anything beyond that is out of scope 
> for
> BaseNotif in my view.
>
> In addition, I would like to make three modifications to the 
> GetMessages
> request proposed by Steve:
>
> The first change might actually just be a clarification since I am not
> sure how Steve intended it to work. If there are 100 messages in the
> queue and I do a GetMessages(40) then I will receive the 40 most recent
> messages and the entire queue will be cleared. Basically, every
> GetMessages request clears the entire queue in addition to getting some
> or all of the most recent messages.
>
> The second change is to have the GetMessages request contain 2 optional
> elements (or attributes): MaxMessages, as currently defined, but also
> OldestTime. If MaxMessages is present then don't send me any more than
> this many messages. If OldestTime is present then don't send me any
> message older than this date. The two filters can exist on their own or
> co-exist. Yes, they are transitive.
>
> The last change is to create a special topic called "MessagesDropped".
> The payload for this topic contains the number of messages dropped, the
> date of the oldest message dropped and the date of the most recent
> message dropped. This topic would be defined so that the event is only
> emitted when the GetMessages request comes. So, even if my
> implementation has dropped messages at several times in the past since
> the last Get Messages request, there will only be one "MessagesDropped"
> event for each GetMessages request (think of it as the Schroedinger's
> cat of notifications, only realized when there is an observation). Note
> that it doesn't matter if the messages were dropped because of space
> limitations or because the GetMessages request asks for less messages
> than are available in the queue. This is just a way to tell people that
> they've missed something.
>
> Now to the question that the group wasn't able to agree on by the end 
> of
> the meeting (overload the subscribe operation or create a new
> operation). At the messaging level, there is no major difference
> between:
>
> (1)
> <Subscribe>
>   <ConsumerReference/>
>   <TopicExpressionDialect/>
>   <SubscriptionPolicy>
>     <UsePull>true</UsePull>
>   </SubscriptionPolicy>
> </Subscribe>
>
> and
>
> (2)
> <Subscribe>
>   <ConsumerReference/>
>   <TopicExpressionDialect/>
>   <Delivery>http://.../pull</Delivery>
> </Subscribe>
>
> and
>
> (3)
> <SubscribeForPull>
>   <ConsumerReference/>
>   <TopicExpressionDialect/>
> </SubscribeForPull>
>
> So the difference is not really a messaging difference but rather a
> metadata difference. Because based on which of the three formats above
> we choose, the "can I subscribe for pull-type notification" question is
> answered in a different piece of metadata.
>
> With (1) and (2) it is describe using a TBD policy statement expressed
> in a TBD policy framework retrieved through a TBD metadata retrieval
> mechanism. With (3) it is described by the WSDL.
>
> (1) is the most generic mechanism (there are many ways to qualify a
> subscription and this is one of them). (2) is less general (there are
> many ways to deliver a notification and this is one of them). (3) is
> most specific.
>
> I prefer (3) because this makes the simple pull-type feature available
> out of the box in BaseNotif. Also, (3) doesn't prevent a mechanism like
> the ones in (1) or (2) to be overlaid (to distinguish between different
> types of push-type delivery and different types of pull-type delivery).
> It just recognizes that there is a major differences between pull-type
> and push-type delivery and that the semantic difference of a
> subscription to one or the other is sufficient to warrant using the
> premier metadata mechanism for Web services (WSDL) to denote it.
>
> Regards,
>
> William
>
>
>
-- 

Take care:

     Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
     Fujitsu Laboratories of Europe
     Hayes Park Central
     Hayes End Road
     Hayes, Middlesex  UB4 8FE

     +44-208-606-4649 (Office)
     +44-208-606-4539 (Fax)
     +44-7768-807526  (Mobile)