RE: issue 6432: proposal

Hi Doug,
One thought in all of this... why should we use MakeConnection, why not just use Transfer?

And a thought on the "should we remove the mode attribute in subscribe" question.  It seems to me that if you delete the mode attribute, you are really just turning the NotifyTo EPR into another "mode flag" anyway.  For example, the Event Source has to look at the NotifyTo EPR and, if it is a normal EPR, push events to it, if the EPR is a MakeConnection type EPR then it has to queue events up and wait for MakeConnection messages.
Cheers,
--Geoff


From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Tuesday, March 17, 2009 10:14 AM
To: Geoff Bullen
Cc: public-ws-resource-access@w3.org
Subject: RE: issue 6432: proposal


Hey Geoff,
  responses below...

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

yes that's what I had in mind.

> 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?

I'm not sure where you're looking. The MC spec has an example:
http://docs.oasis-open.org/ws-rx/wsmc/200702/wsmc-1.1-spec-os.html#_Toc162743915
and its a pub/sub example but it never uses MC in replyTo - it
uses it just in the NotifyTo-like EPR. To your specific
question, no, in response to a Subscribe you would not get back a
notification - you'd get back a SubscribeResponse.  There is no
difference in semantics.

> 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?

This isn't an MC question - what happens if two of them were ftp://...
and the event source doesn't support ftp?  No difference when using MC.

> 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?

Security is still established by the sender - the event source in this
case.  Just like in the async world, it will secure the message any
way it wants.  The MC message is totally independent of the notification,
so it can be secured independently.  The receiver of the MC message will
need to verify that it trusts that sender - the same way it will need to
decide if it trusts the subscriber.

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

Same as above - if the subscriber sends in an EPR with ftp://...
the event source should fault it or the event sink should expect
to never see a notification if the check is not performed during
subscribe time.  See: http://www.w3.org/Bugs/Public/show_bug.cgi?id=6696

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

No biggie - this is the same situation as the same addressable EPR
being used by two subscriptions.  You can reuse the exact same EPR
or if you want you can add ref-params to distinguish them.

One thing to point out here.... let's say you do reuse the same MCuri
in multiple subscriptions.  An MC message will allow ANY notification
from ANY of those subscriptions to flow.  This means that I only need
_one_ polling loop on the client for _all_ of the subscriptions.  In
situations where the subscriptions don't generate a ton of traffic this
saves you from having to poll once per subscription.  Its potentially
a really good performance boost.

> 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?

To the subscription manager - that's the only EPR we have to the subscription.

> 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?

Yes they are stored.  How many, how long... type of questions are
left as an implementation choice.  This is similiar to how does an
event source avoid overloading an event sink with too many messages?
There are lots of config knobs, in all types of delivery modes, we can add
but I think those are best left for an extension specification - after
we get some more real world experience.  Keep it simple for now.

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

MC works on a per-message basis. One incoming MC message allows one
message to flow back.  Remember, now that we have the Format element
the mechanism by which notifications are sent is independent of what
those notifications look like.  If people want to do batching then
they can do so but that true regardless of whether they're doing
push or pull style delivery.

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

A 202 is returned.  This question makes me think that perhaps I should
explain how MC is used because there might be some confusion around this
and its really actually a very simple concept - the key is to not
assume too much - its not trying to do anything except establish
a connection to a non-addressable endpoint and identify who that
endpoint is.  Nothing more.  In its most basic use-case MC is nothing
but a transport concept and doesn't know anything about the messages
flowing over the connection that is established.

Having said that, sure, a smart SubscriptionManager could look at
the incoming MC message and generate a Notification message on the
fly and not queue up anything.  This is an implementation choice and
something that might make sense for a primer.  But I don't think we
need to clutter up the spec with these details. Notice that nothing
in what I suggested for this issue talks about queuing or anything like
that - trying to keep it simple - and the key thing here is that
regardless of how the subscriptionMgr chooses to implement it - the
event sink doesn't know, or care.

> 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?

If there are no messages waiting to be sent then a 202 is returned.
I would also point out that just because the Subscription is dead
doesn't mean that no more messages need to be sent.  Perhaps the
subscription is dead but a final RM Close/TerminateSequence needs
to flow.  MC would allow those to be sent.  So related to your
next question... its not that easy to tie the life time of the MC
URI and the Subscription.  There could be lots of other infrastructural
things at play.  And this is true even in the async/addressable cases
too.

> 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?

Nope.  The MC URI has no knowledge of the application its being in.
Same as any addressable URI.  There is no "maintaining" needed.

> 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?

It can reuse the MC URI the same way it can reuse an addressable URI.

> 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 for details.
>
> thanks
> -Doug
> ______________________________________________________
> STSM |  Standards Architect  |  IBM Software Group
> (919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com