RE: [wsn] Proposal for "simple pull"

["Vambenepe, William N" <vbp@hp.com>]

Thanks David. I like the simplicity. A few comments:

 

1) I'd rather not say in BaseN how the producer advertises the maximum limit on number of messages (because this would require either metadata support or WS-ResourceProp which we don't currently need for the simple cases). Or at the very least, if we really have to define a QName for this information, make it a MAY rather than a MUST.

 

2) I'd like to add the possibility for the subscriber to set the max number of messages to retrieve (actual number could be less if fewer events have been emitted or if the producer can't store that many). Either as part of each GetStoredMessages request or once as part of the subscription.

 

3) I am fine with the information about the dropped messages being an optional element rather than a notification as I originally proposed.

 

My logic for (2) is that I see pull-type used in cases where the producer is very capable (access to large and reliable storage mechanism) but the consumer is lightweight. The limited party here is the consumer and the producer accepts to do more work to help out the consumer. So the consumer should be able to decide how many messages to retrieve, not the producer who might not understand the constraints that the consumer is under and the goals that the consumer has in retrieving this information.

 

Regards,

 

William

---

From: David Hull [mailto:dmh@tibco.com]
Sent: Monday, February 14, 2005 11:03 AM
To: wsn@lists.oasis-open.org
Subject: [wsn] Proposal for "simple pull"

Intended Application:

This proposal is aimed at configurations in which the consumer, perhaps because of a firewall or other security measure, is unable to receive notifications directly.  To support this, we offer a basic facility for storing and forwarding notifications.  This facility is not intended to cover all possible cases of pull-based delivery.  It is expected that the consumer will poll the delivery address reasonably frequently relative to the rate of notifications.

Policy:

NotificationProducers MAY advertise a pull notification capability.  If so, they MUST advertise a maximum limit on the number of messages to be stored for a given pull subscription.  Subscribers MAY request pull notification when making a subscription.  In such a case, the ConsumerReference element MUST be empty.  The SubscrptionPolicy element MUST indicate [exact spelling TBD] that pull notification is requested.

Delivery of notifications:

The response to the subscribe request MUST provide an endpoint through which the consumer may retrieve messages.  This endpoint MUST support the GetStoredMessages request/reply.  The GetStoredMessages request is empty.  The GetStoredMessages reply MUST contain, in order, the most recent notifications for the subscription since the previous GetStoredMessages request (or in the case of the first GetStoredMessages request, since the subscription was established), up to the limit advertised by the NotificationProducer.  If the limit was exceeded, the response MUST also include the number of notifications produced but not delivered for the current request. [This probably means a Notify message plus an optional "messages dropped" element].  Note that the GetStoredMessages response may contain no messages at all. [TBD whether this is just an empty Notify message or something yet smaller]. In all cases, the GetStoredMessages response should be delivered promptly, as opposed to delaying until a message arrives.