WSN1.4 verification comments (Pull type subscriptions)

[Matthew I Roberts <matt.roberts@uk.ibm.com>]

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

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.

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..."

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.

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.

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)

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.

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).

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.

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.

Thanks,

Matt


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