RE: Issue 6432: updated proposal

Geoff wrote:
> Doug,

Hey Geoff, 
During the last day of the f2f we talked about how much detail would
go into the WS-Eventing spec vs. into something like a Primer.  We
decided to start with something minimal for now. 

That being said, to your questions...

> This does not seem to address the problem of queuing.  Does the 
> Event Source store / queue events for delivery via MakeConnection? 

most of your questions are really an implementation choice.  For example,
one impl could have the SubMgr store/queue all of the outgoing 
notifications, 
waiting for an MC message.  Or it could use the incoming MC message as a 
trigger
to generate a notification - of course this works best when you're using 
WS-E
as more of an iterator over data rather than a message broker type of 
system.
Either way, from the protocol and client's point of view, it doesn't 
matter.
The end result on the wire is the same - which is the way it should be.
This, IMO, is really no different from how specs like RM are written. They
don't get into the details of queuing (which is clearly implied) and 
simply
focus on what the wire/xml looks like.

> Does it store an event queue for each separate subscription? 

Each NotifyTo can have its own MC-anonURI, in which case if there are 
queues,
then yes each subscription would have its own queue.  If the subscriber 
chose
to use the same MC-anonURI for multiple subscriptions, then they would all
share the same queue.  Which is what the client asked for - probably 
because
they wanted to have just a single polling loop to cover multiple 
subscriptions.

> There 
> seem to be a number of other areas here that need to be handled in 
> order to actually get a working implementation and interop, or am I 
> missing something?

Possible, but as I mention above, if we stick with just what the XML on 
the
wire looks like then I don't think we'll need to get into more details.
I'd be ok with adding more pros to the spec to help people get their head
around this, but in the end I doubt it'll lead to more normative text 
since a lot of the details I think you're worrying about are really 
implementation
choices that should not impact interop.

> Also, it is still not clear, when you send a MakeConenction to the 
> Event Source, if you can tell the difference between a response that
> indicates ?no events currently available? and one that indicates 
> ?the subscription is no longer available?.

In the "no events available" case you would clearly get a 202.
In the case of "the subscription is no longer available" you would either
get a 202 or an EndSubscription message - if you passed in an EndTo with 
that
same MCanonURI.   This is really no different from the normal async case.
If you don't get a notification for a long time is it because there are no
events or because the subscription is dead?  Same problem.  In both worlds
EndTo answers this for you.

> Cheers,
> --Geoff
> 
> From: public-ws-resource-access-request@w3.org [mailto:public-ws-
> resource-access-request@w3.org] On Behalf Of Doug Davis
> Sent: Monday, March 23, 2009 8:23 AM
> To: public-ws-resource-access@w3.org
> Subject: Issue 6432: updated proposal
> 
> 
> Updated proposal - keeping a minimalist approach in mind: 
> 
> Change the definition of Push Mode in section 3.3 from: 
>   A delivery mechanism where the source sends event messages to the 
> sink as individual, unsolicited, asynchronous SOAP messages. 
> to: 
>   A delivery mechanism where the source sends event messages to the 
> sink as individual, asynchronous SOAP messages. 
> 
> And in section 2.2, after: 
>  This specification defines a single delivery mode, called Push Mode, 
which 
> is simple asynchronous messaging. 
> 
> add the following text: 
> 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. 
> A subscriber 
> MAY also choose to a wsa:Address value that is a WS-MakeConnection 
> anonymous URI template which allows for events to be delivered to a non- 

> addressable endpoint via a connection that is initiated by the event 
sink. 
> See the WS-MakeConnection specification for more information, and an 
> example, of how this would work. 
> 
> 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.