[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue 1.4 Pull-type subscriptions - summary (repost)
At the end of this email I have given a set of pointers to the email discussion. Here is a summary of the main points 1. Discussion on requirements/use cases We have talked about a number of these. The main ones appear to be a) NC applications that are outside a firewall such that the NP (inside the firewall) cannot invoke the NC EPR. We can generalise this to include applications that are unable or unwilling to provide a NC EPR against which the NP can invoke (for example they might be running in a client environment) b) Lightweight consuming applications communicating with 'heavy-weight' NPs. The NCs do not want to be "fire-hosed" with data, but wish to pick up messages when they are ready for them (see [7]). There seems to be agreement that we should not be defining a general purpose queue/mailbox mechanism that could be used outside WSN, and we don't define explicit "put" operations, or allow several subscriptions to be multiplexed together. 2. How does an NP advertise pull capability? Steve's original proposal [1] is that the NP advertises this using the same mechanism as we use for other "policy" advertisement. A subscriber can then retrieve the data by examining the WSDL, calling WS-MetadataExchange, or some other mechanism (possibly WSRP). The sort of things that it could advertise would be a) Is the NP willing to do this style of PULL notification at all? b) Is there a limit to the size (bytes) of the message buffer? c) Is there a stale dateafter which non retrieved messages are removed from the buffer? William [7] suggests that it would be preferable if we could avoid having to have the NP advertise these things as this introduces a dependency on an advertising mechanism, overcomplicating the work for a simple NP - and also parameters of this sort could be requested by the subscriber. 3. What is the syntax of the message exchanges used to subscribe and to retrieve messages? Proposal [1] uses the normal Subscribe request, but includes a SubscriptionPolicy element that requests Pull. The subscriber is required to provide a <ConsumerReference> EPR, but this is ignored. Other options that have been discussed (verbally and in email) - As [1] but make the <ConsumerReference> optional when Pull is requested - Remove the need for an explicit SubscriptionPolicy - the NP infers it from the absence of a <ConsumerReference> - Remove the need for an explicit SubscriptionPolicy, but have the subscriber provide the EPR of the service that it is going to pull from. However we aren't defining a general purpose service of this sort. Proposal [1] made no change to the syntax of the subscribe response, however the EPR that it returned was to a "PullableSubscriptionManager", that performs the normal SubscriptionManager operations (pause/resume/query/delete/[modify] subscriptions) in addition to the new getMessages message exchange. Alternatives discussed include a modified subscribe response that returns two EPRs (the conventional SubscriptionManager and a new one that supports getMessages), or a putting a new property on the SubscriptionManager that contains the EPR that supports getMessages. Should getMessages return just a single message, or does the request include a "number of messages" parameter? Consensus appears to be the latter - I presume this would mean that for n>1 the NP would boxcar the messages together. 4. Semantics The discussion here has been about the nature of the "buffer" used to hold NotificationMessages before they are pulled by the NC. a) Is it FIFO or FILO? b) Who (if anyone) specifies its size? c) Under what circumstances do messages get discarded? d) Is there any indication that messages have been discarded? How many of these things should be specified using WSN, versus left to implementor choice? [1] Steve's proposal http://www.oasis-open.org/apps/org/workgroup/wsn/download.php/11249/pull%20proposal.1.pdf [2] Sanjay http://www.oasis-open.org/apps/org/workgroup/wsn/email/archives/200502/msg00003.html [3] William http://www.oasis-open.org/apps/org/workgroup/wsn/email/archives/200502/msg00009.html [4] Matt Roberts reply to [3] http://www.oasis-open.org/apps/org/workgroup/wsn/email/archives/200502/msg00016.html [5] Peter http://www.oasis-open.org/apps/org/workgroup/wsn/email/archives/200502/msg00022.html [6] DMH proposal http://www.oasis-open.org/apps/org/workgroup/wsn/email/archives/200502/msg00031.html [7] William reply http://www.oasis-open.org/apps/org/workgroup/wsn/email/archives/200502/msg00032.html [8] DMH reply to William http://www.oasis-open.org/apps/org/workgroup/wsn/email/archives/200502/msg00033.html [9] Peter http://www.oasis-open.org/apps/org/workgroup/wsn/email/archives/200502/msg00049.html Peter Niblett
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]