Re: issue 6432: proposal

Folks,

On 20 Mar 2009, at 16:14, Geoff Bullen wrote:

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

This is my bit to comment on: Yes to some extent you are right, but we 
are not cluttering this spec with extra knobs when those knobs already 
exist. Putting aside the right or wrong of MakeConnection, it is not 
the only solution. I could implement a WS-Notification-like PullPoint 
and solve the problem that way. Mode would not be needed and might 
even prevent my doing it this way. Without mode, I just set up the 
pieces and let it go.

> 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

Take care:

     Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
     Fujitsu Laboratories of Europe Limited
     Hayes Park Central
     Hayes End Road
     Hayes, Middlesex  UB4 8FE
     Reg. No. 4153469

     +44-7590-293439 (Mobile)








______________________________________________________________________
                                       
 Fujitsu Laboratories of Europe Limited
 Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE
 Registered No. 4153469

 This e-mail and any attachments are for the sole use of addressee(s) and
 may contain information which is privileged and confidential. Unauthorised
 use or copying for disclosure is strictly prohibited. The fact that this
 e-mail has been scanned by Trendmicro Interscan and McAfee Groupshield does
 not guarantee that it has not been intercepted or amended nor that it is
 virus-free.