WSN F2F 30/7/04 Afternoon session
Friday, July 30, 2004
3:37 AM
Issue resolution continued
· WSN 2.11 - Consumer can't identify subscription causing notification
PN: observation sub issue of 2.9 trying to cancel subscription
MC: IRP aside; Would it be valid to have a property that is subscriberID that is scoped by the consumer? Resource Property of the subscription that is in the instance document
JT: In line with other notification systems (possibly consumer provided identity). No particular format.
SG: Currently don't have that functionality
WSRF wants to stay out of identifier business. Domain specific identifiers are appropriate (eg WSDM). A user of WSRF defining its identifier
AK: Believe it is in scope for WSN to define a subscription identifier. If you have an id that a consumer can use later then you can use that identifier for pause and resume.
IS: Does not solve this issue
AK: Subscription ID is service provider generated and sent back to consumer.
IS: Just having the ID does not help. Whom do you talk to about that identity.
AK: Consumer has no idea how to contact the producer
IS: Also does not know how to contact the subscription manager
SG: Subscriber role gets the EPR of the subscription manager
AK: Identity does not change the fact that consumer does not get EPR for Subscription manager
WV: Issue needs to address situations where subscriber and consumer are separate and the same
SG: Consumer, Notification Producer 1 and 2.
Subscribe to NP1, EPR1 and SubID = 5
Subscribe to NP2, EPR2 and SubID = 5
AK: Unique identifier in notification message to correlate to the subscribe message EPR
IS: Why not just use reference as opposed to identity?
SG: So EPR1 flows on the notify
So consumer can compare to EPRs (somehow)
And what about raw?
AK: wrt comparisons. The only thing the consumer can do is bitwise compare.
IS: Why compare?
A: Doing admin does not require comparison.
BM: If the consumer and the subscriber are the same then consumer could put something into the reference properties to get information back for comparison.
AK: That assumes that you are using WS-Resource qualified endpoint. What if you did not create the consumers EPR
BM: Consumer could keep track of EPRs and ref props
AK: Relies on WS-Addressing
WV: If someone subscribes on your behalf this will not help you
PN: Summarize:
Issue is not clear 2 aspects
1. Have subscription list (assumes subscriber -> consumer handshake) Subscriber associates number. EPR to subscriber imbeds that in consumers EPR
2. Consumer gets notification (no handshake). No way to cancel that
Imbed enough information in the notify to address the subscription
Explicit notify message do we want to make it mandatory?
Wrapped form that defines additional things for consumer.
Rough Proposal:
In notify message we put EPR that can be used to pause, resume, cancel, etc for the subscription.
AW: Why is that not identical EPR to the return of the subscribe.
PN: Use of the EPR returned will have the same effect as the EPR returned by the subscribe. Refers to the same subscription.
Proposal:
In notify message we put EPR that can be used to pause, resume, cancel, etc for the subscription. The EPR in the notify message refers to the same subscription returned by the Subscribe MEP.
DH: Subscriber putting something in the consumer EPR. Easter eggs in the notify message. There needs to be at least one way for the subscriber to pass information to the consumer. Consumer needs access to the subscription and the proposal covers that. Has nothing to do with the SPAMming issue.
MC: (at whiteboard) Look at current notification message structure
Section 3.1
<SOAP Hdr/>
<SOAP Body>
Notify
NotificationMessage
SubscriptionEPR * (0..unbounded)
Topic
ProducerReference
Message
</SOAP Body>
SG: Observed the following; optional producer reference. Can we get rid of that?
PN: No, Producer ref was original notification
SG: withdraw
AK: Likes the proposal; modulo WS-Resource discussion. In general good direction does not impose the same requirements as WS-Addressing.
DH: Optional unbounded? Why? We should be concerned with optimization. Not so much at the message format level. Not clear it will save CPU on either end. Saving space on the wire use compression…
MC: 0..unbounded discussion
15 subscriptions set up by the subscriber
Overlapping topic expressions
On match of 10 can send only one with multiple subscription ids
And can also send multiple messages.
PN: Impacts the consumer
MC: Some extra work on consumer
AW: Do we assume that we would never make multiple subscriptions to the same producer on the same topic?
Group: No
AW: So we need this functionality. Unless one of these is mandatory the consumer will not be able to decide.
AW: So reference property as a correlation context
GD: That pattern works but there needs to be work done on the subscriber side
Clarification subscription EPRs are all related to the same consumer.
PN: To do the boxcar the Notification Producer needs to compare the consumer EPRs
Optional or required
MC: Optional
PN: Control of optional
MC: Notification Producer
PN: Concerned about simple minded consumers
PN: Do we need no boxcar on subscription EPR parameter?
PN: There will be a class of consumers that will not be able to or want to do that.
PN: Amend to allow policy/parameter in subscribe request
DH: What is the exact amendment?
PN: Mechanism to allow subscriber to control boxcaring of subscription EPR on the Subscribe MEP (editorial changes by minute taker (added "on the Subscribe MEP"))
DH: If we add Subscription EPR 0..unbounded shouldn't we add 0..unbounded on the producer reference
WV: No interface is defined for producer reference
DH: Not convinced we are gaining much here. It is dead simple what an optional subscription EPR means. If we get into 0..unbounded you introduce parameters/policy, you have other questions but it is a difference between dead simple. Opt for 0..1 as opposed to 0..unbounded.
WV: Show of hands on the current proposal:
0..unbounded - 5 people
0..1 - 6 people
About 50-50
MC: Why unbounded makes sense
IS: Against 0..unbounded. 0..1 is reasonable. 0..unbounded complexity is unnecessary. Solve the 80% case. Boxcaring is totally orthogonal to the issue at hand. How do you know the subscription.
SP: Uncomfortable with putting the admin on the consumer. The original idea of separating the consumer and subscriber was a split of operational and administrative. Against entire proposal. Stick with consumer and subscriber model. The consumer coordinates with the subscriber for administration.
Identify subscriber interface for this administrative role.
IS: Clarification. What makes you think there is a trust?
SP: The main problem is if the consumer gets unwanted subscriptions.
WV: Clarify Sanjay's counter.
AW: As proposal of query mgmt interface I would not like to use this mechanism as per Sanjay's proposal. Minimize out of band mechanisms.
The proposal solves the issue for me
SP: Optional does not solve the issue
WV: straw poll
For proposal - 13
Sanjay's proposal or something else - 1
Go back to other proposal thread
MC: (at whiteboard)
0..1 Subscription EPR
Subdispatch of message is the same for 0..1 or 0..unbounded
SG: sending 2 identical subscribe requests will cause generation of two separate subscriptions
AK: Not sure what the delta is between 0..1 or 0..unbounded. Very similar fan out. Having said that the important part is having the identity in the message. Why is this more complicated?
DH: What would the unoptimized message look like? Let's focus on that. One notification per subscription on event generation. We should support the ability to put more then one notification message into one physical message. There is some per message overhead. Subscription EPR should be optional. RECOMMEND that it be there.
Do not get in the optimization business in general. 0..unbounded against.
SG: During the development of this we did not have the boxcar. If we had the NotificationMessage+ we could use same message format for response of poll.
WV: Whether 0..1 or 0..unbounded. Not a big deal either way. Not a high stake issue. Prefer simpler approach.
SG: Against star but for 0..1. Implication of how NotificationProducer knows how to do bundling. Uncomfortable with consumer comparison.
DS: Whole discussion about inserting EPR addresses requirement for administration of subscription. Coorelation of subscriptions on server side not addressed. Line 393-396 of spec covers.
IS: Do you have many messages or one? For every message you want to fire some work. Forcing requirement to look into the message is not good. Arguing that multiple subscription EPR (0..unbounded) is not good.
A: No good answer why this is more difficult.
IS: Can no longer use SAX parser for this message.
AK: Start using pull parser better performance :-)
MC: I'll go with prevailing side.
WV: Strawpoll
0..1 - 9
0..unbounded - 3
AW: Does the spec permit single notify to go to multiple consumers?
Group: Still does not allow that.
Resolution:
In notify message we put EPR that can be used to pause, resume, cancel, etc for the subscription. The EPR in the notify message refers to the same subscription returned by the Subscribe MEP.
Notify
NotificationMessage+
SubscriptionEPR?
Topic
ProducerReference?
Message
Issue is forwarded to editors for action
· New motion to open issue to revisit the "MUST implement the IRP" before issuing next public draft.
No opposition. New issue.
· WSN 2.19 - Soften the wording for Subscribe operation
PN: Do we want to just accept proposed recommendation?
AK: Just create or fault?
MC: Upon successful completion you must return….
AW: Need to explain the faults.
WV: Any concerns on accepting proposed recommendation?
Proposed recommendation accepted.
Issue is forwarded to editors for action using proposed recommendations
· WSN 2.13 - Bindings often the wording for Subscribe operation
This may depend on IRP work to be done in WS-RF TC.
Mechanism the Notification Producer uses to create EPR for the subscription reference is an implementation issue, which is not subject to standardization.
This issue remains unresolved
· WSN 2.20 - QOS for change of subscription properties
This issue is related to WS2.7 Updating resource properties via Set Resource Property. It is possible to modify any resource property of a resource using Set Resource Property in WS-RP spec.
Essence of this issue: if you change a subscription parameter "on the fly," e.g. termination time, how seamless will the transition be?
· Thank Fujitsu
DS: Comments please on things to improve to Dave