RE: [wsn] WSN1.4 verification comments (Pull type subscriptions)

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

Thanks for the detailed review Matt. See my comments inlined below
between <vbp></vbp>.

I think you found a lot of very good editorial issues for the editors to
fix. As far as the content being faithful to the F2F discussions, I
think that is it very close to the resolution (including the aspect of
the resolution that I loath) and the editors did a good job. Considering
how hard it is to retrace a whiteboarding session based only on minutes
I think you did an amazing job, but I think you also got a couple of
misunderstanding with regards to making the interface between the
notification producer and the pull point a "private contract". This is
indeed how we started but we moved away from it during the conversation.
See my comments inlined inside your review for more on this.

I believe at this point all that is needed for committee draft on this
issue is the editorial fixes listed below. The other issues would result
in revisiting decisions made at the F2F, which I think is better left
for the public review period. At this point we have a TC agreement on
this issue.

(BTW, as part of this review I realized that the minutes from the F2F
had been sent to the mailing list but not uploaded in the site, so I
took care of that, assigning the name of the minute taker to the
document. So I am the only who caused the notifications that were sent
to the list saying that Martin, Lily, Sid and Steve supposedly uploaded
their files seconds appart).

Regards,

William

-----Original Message-----
From: Matthew I Roberts [mailto:matt.roberts@uk.ibm.com] 
Sent: Monday, June 20, 2005 8:27 AM
To: wsn@lists.oasis-open.org
Cc: Steve Graham; dmh@tibco.com; Murray, Bryan P.
Subject: [wsn] WSN1.4 verification comments (Pull type subscriptions)





Steve/David/Bryan,

Please find below my comments relating to verification of 1.4 (Pull type
notification) against BaseNotification draft 1.3j. Unfortunately I
wasn't able to attend the F2F where this was discussed so I've been
working from the minutes and other documents, however that might prove
an advantage in some ways!


a) There is no explicit description of how to use the new PullPoint.
Although a knowledgeable reader can infer the pattern from the text I
think it would be better to call it out directly. I suggest inserting
some text or diagrams to show the application creating a pull point,
then issuing a subscribe request containing the PullPoint EPR, then
pulling a message from the PullPoint

<vbp>This is editorial, I trust the editors to handle this
approprietly.</vbp>

b) The GetMessages message defines the MaximumNumber element which is
marked as optional. The text of 5.1.2 describes that if this element is
not specified then "the requestor is asking to receive all messages held
by the PullPoint". I couldn't find this mentioned in the F2F minutes,
and I am concerned that this behaviour permits the possiblity that an
extremely large number of messages might be returned (assuming the
PullPoint buffers messages indefinitely). I suppose technically this is
what the application requested, but I think we should explicitly
consider that this is what we want.

<vbp>Yes there is a risk but I think this is not specific to this
mechanism. A GetResourcePropertiesDoc request on a ServiceGroup can also
be overwhelming. And on resource-constrained devices (especially those
for which the resource in short supply is bandwidth) it doesn't take
very much to be overwhelmed. So I would expect some orthogonal mechanism
to be devised if one wants to put a byte-size limit on responses.</vbp>

<vbp>In any case, the current text faithfully reflects the group
decision at the F2F as far as I recollect it.</vbp>

c) Line 939 contains the sentence "The number of messages appearing is
determined by the wsnt:MaximumNumber component of the GetMessages
request message" when describing the GetMessagesResponse. The first time
I read this I was struck by the thought that it suggested that we would
always return exactly the 'MaxNumber' of message in the response
(although this is not suggested anywhere else). I would be more
comfortable clarifying this sentence to something like "... is
determined by the rules associated with the wsnt:MaximumNumber..."

<vbp>Editorial.</vbp>

d) Line 909 describes the MaximumNumber element as being of type
xsd:nonNegativeInteger which allows use of the number 0 (zero). There
seems to be little benefit to allowing this (since the number of
messages returned is always 'n <= MaximumNumber' so I suggest modifying
this type to xsd:positiveInteger.

<vbp>One possible use of a GetMessages with a request of no more than
zero messages is to "ping" the pull point to make sure you can still
access it without removing any message from its queue. Not a huge deal
but since I don't see how nonNegativeInteger hurts I don't see a need to
change it. But if people feel strongly about this let's discuss this on
the mailing list and the TC can instruct the editors to make the
change.</vbp>

e) Line 1063 (the wsa:Action for CreatePullPointResponse) seems to be
half highlighted in Blue when the other similar bits of text are all
black.

<vbp>Editorial.</vbp>

f) The grey/gray box showing the GetMessages message (line 907) does not
reflect the {any} extensibility that is in the schema (which is done by
other examples in the file such as GetCurrentMessage at line 784). The
same is true for GetMessagesResponse (930), Destroy (1000),
DestroyResponse (1008), CreatePullPoint (1049), CreatePullPointResponse
(1057)

<vbp>Editorial.</vbp>

g) The way that section 5.2 is written it is implicitly possible to
provide a single PullPoint reference on multiple subscribe requests to a
given NP/NB, or similarly use a single PullPoint for subscriptions to
_different_ NP/NBs. The F2F minutes (and preceeding discussion) ruled
this out as a possibility, so I think we should tighten the text
somewhere to say either that it is definitely not supported to use the
same PullPoint for multiple subscriptions, or that it is at the
discretion of the implementor of the PullPoint.

<vbp>I don't know that we should say anything here. The subscriber is
free to try to reuse an existing endpoint on multiple subscribe, with
the same producer or another. Of course the endpoint is free to accept
or reject the notifications it receives. I can imagine that in many
case, notification producer will accept to create pull points but these
pull points can only be used for notifications produced by this
notification producer and they will refuse incoming notifications from
other publishers. Unless you have a contract with the creator of the
pull point you can't assuming anything. Policies could be develop to
express these contracts, but this would be outside BaseN. What in the
minutes makes you think that we want to specifically forbid this?</vbp>

h) 5.1.1 states that "The PullPoint interface supports the
NotificationConsumer interface (as defined in section 3)". This
statement is not backed up in the WSDL, and I believe it should be
removed since the F2F minutes state that "we don't define explicit 'put'
operations". This also makes it dramatically less likely that the same
PullPoint could be used by multiple NP/NBs (as mentioned in g) above)
since the mechanism for inserting messages into the PullPoint is a
private deal. We should consider inserting text stating that a PullPoint
can only be given to a NP that is associated with the CreatePullPoint
implementation that spawned the PullPoint (since in the general case the
NP will not have knowledge of the private deal for inserting
notifications into the PullPoint).

<vbp>As described above, I don't think that we decided to restrict pull
points to collecting notifications for which the producer is the same
entity as the pull point, even though this can reasonably be expected to
be a common case. The mechanism to send notifications to a pull point is
not a private deal. We specifically decided that we don't want the
notification producer to have to do anything differently if the
subscription points to a pull point rather than a "real" consumer. In
fact, in many cases the notification producer will have no idea whether
a pull point is used. The only thing is that in some cases, the
notification producer might recognize a pull point in the subscription
and might have a special, optimized, way to send notifications to this
pull point. But this is an implementation choice that the spec doesn't
need to have anything to do about. My only concern with this section is
an editorial concern. This sentence:

This interface [NotificationConsumer] allows NotificationProducers to
send Notification Messages to the PullPoint using a "raw" or "wrappered"
approach.

is not correct since the implementation of the NotificationConsumer
interface does not guarantee that "raw" messages will be accepted. The
text should say that the pull point should accept any format of
notification message, raw or wrappered.
</vbp>

i) There is no discussion in chapter 5 of what happens if the PullPoint
is destroyed before the Subscription (or vice versa). I think if we
assume that there is always a 1-1 correspondence between the PullPoint
and its Subscription that there is a reasonable case for suggesting that
the Subscription may be deleted when the PullPoint is destroyed (since
notifications received on the subscription have no possibility of being
received by the consuming application). I believe that there is a case
for letting the PullPoint live on when the Subscription is destroyed so
that any remaining messages can still be consumed, however this may
provide additional complexity for simple implementations. In any case I
believe we should comment on these issues in the spec text.

<vbp>From my recollection of the F2F, this "say nothing" approach is on
purpose. The lifecycles of the subscription and the pull point may or
may not be synchronized. In the absence of a policy statement or other
out-of-band agreement, you can't make any assumption.</vbp>

j) Line 950 talks about the handling of 'Raw' messages in the queue
point.
I believe that the net result of this description is that subscriptions
that specify the Raw flag cannot be received in the Raw format from the
PullPoint. Ths makes me wonder what the point of specifying Raw in the
Subscribe was in the first place - we should consider the statement that
it is not valid to specify use of Raw in a Subscribe call that provides
a PullPoint as the ConsumerReference. Since there is a private deal
between the NP and the PullPoint describing how messages should be
inserted the NP should be able to police this constraint.

<vbp>Again, the intent was that the notification producer can treat this
subscribe request as any other subscribe request.</vbp>

Thanks,

Matt


Matt Roberts
IBM WebSphere Messaging Design and Development Hursley Park, England.
+44 1962 815444 matt.roberts@uk.ibm.com MP 211 / DE3H22