RE: issue 6432: proposal

I'll leave the Mode question to the discussion of Dave's issue.

As for using Transfer... I don't see how that can work since the Transfer 
response has its own action, body, semantics... and the notification 
messages pulled back from MC could be anything and would look/act/smell... 
nothing like a TransferResponse message.

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog.



Geoff Bullen <Geoff.Bullen@microsoft.com> 
03/20/2009 12:14 PM

To
Doug Davis/Raleigh/IBM@IBMUS
cc
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Subject
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