RE: issue 6432: proposal

Doug,
I am not sure that WS-MakeConnnection will work correctly, simply through composition, you may need more than that.  I would like to explore this further, if you don't mind.

I am assuming that you are considering it composing with Eventing something like this:

<Subscribe>
            ...

            <NotifyTo> <wsa:Address>MCAnonURI?uuid=...123<\ wsa:Address><\NotifyTo>

            ...

<\subscribe>



So some questions immediately come up:

1)     It is not clear to me what happens if there is an event waiting to be sent straight away.  Does it come back on the "back channel" to the subscribe?  I am assuming that is not what we want here.  MakeConnection examples all use ReplyTo, and this is not the case here, we are sending a separate EPR.  In fact you could want a different MakeConnection id for the ReplyTo of the Subscribe.  How would that then work?

2)     Continuing that theme for a minute, if both ReplyTo, EndTo and NotifyTo each used MakeConnection, and one of the addresses was valid, but the other two were not, what kind of fault would be returned?

3)     It is not clear how this will work securely. Especially if the Subscriber is NOT the one who is receiving the messages.  Can you explain how this will work in the case where the subscriber is not the Event Sink and security is required in order to get the events?

4)     What happens if the Event Source does not support MakeConnection, but the Subscriber tries to use it?

5)     What happens if the same MakeConnection id is used by two different Subscribe requests?



Moving on.  So now the Subscription has been somehow set up.  More questions come up...

6)     Who does the Event Sink send MakeConnection requests to: The Event Source or the Subscription Manager?  In the current WS-Eventing spec, the events could actually be coming from anywhere (i.e. not from the Event Source) - how could you handle that?

7)     Does using this type of mechanism "imply" that now events are "stored/queued" on the Event Source waiting for a MakeConnection to come and get them?  If not, how can this work?  If they are stored, for how long?  How many events are stored?  Can I, as a subscriber, alter this behavior?

8)     Does MakeConnection only get events one-at-a-time or all that are available/stored?

9)     What happens if the Event Sink does a MakeConnection and no events are available?



Moving on.  So now a subscription suddenly ends.  More questions...

10)  The Event Sink sends a MakeConnection and the subscription has already expired, what happens?

11)  Is the life time of the MakeConnection URI (provided by the Subscriber) tied to the lifetime of the subscription (provided by the Event Source)?  How is this maintained?

12)  If the Event Sink "knows" that the subscription has ended, can it use the same MakeConnection URI as it used before to start a new (maybe different) subscription, or does it have to use a different one?

Cheers,
Geoff


From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: Wednesday, March 11, 2009 9:36 PM
To: public-ws-resource-access@w3.org
Subject: issue 6432: proposal


Antoine asked for a Pull mode for WS-Eventing....

Proposal:
  Rather than defining a new Delivery Mode I propose that WS-Eventing simply state that the semantics of a pull-style delivery mode can be achieved through the composition of WS-MakeConnection.

Make the following changes to WS-Eventing:

Each spot in the WS-Eventing spec where the Delivery Mode "Push" is used, replace it with "EPRBased".  (looking for a better wording choice)

In section 2 modify:
  There are many mechanisms by which event sources may deliver events to event sinks. This specification provides an extensible way for subscribers to identify the delivery mechanism and format of the notifications they prefer.
and:
   While asynchronous <del>, pushed</del> delivery is defined here, the intent is that there should be no limitation or restriction on the delivery mechanisms capable of being supported by this specification.

In section 2.2 modify:
   This specification defines a single delivery mode, called EPRBased <del>Push</del> Mode, which is simple asynchronous messaging.
by adding the following text after it:
  By using this mode with a wse:NotifyTo EPR that contains an addressable wsa:Address value, a subscriber can ask for events to be delivered to the event sink via a connection that is initiated by the event source (typically referred to as Push mode).  By using a wse:NotifytoEPR that contains a wsa:Address value that is a WS-MakeConnection anonymous URI template, a subscriber can indicate that events will be delivered via a connection that is initiated by the event sink (typically referred to as Pull mode).  See the WS-MakeConnection specification for more information, and an example, of how this would work.

In section 3.3 delete the term "Push Mode"

In section 4.1, modify:
/s:Envelope/s:Body/*/wse:Delivery/@Mode
The delivery mode to be used for notification messages sent in relation to this subscription. Implied value is "http://www.w3.org/2009/02/ws-evt/DeliveryModes/EPRBased<del>Push</del>", which indicates that the wse:NotifyTo EPR will contain the destination to which notifications are sent.<del>Push Mode delivery should be used. </del>See 2.2 Delivery Modes<file:///D:\wstk\wsra\cvs\edcopies\wseventing.html#DeliveryModes> for details.

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com