Re: draft 3 of WS-Eventing state tables

Li,

To be clear, I note that, from the Subscribers/Event Sinks point of 
view, a Subscription enters the "Created" state on receipt of the 
SubscribeResponse message so the question is really, "Is it possible for 
an Event Sink to receive a Notification before the SubscribeResponse is 
received?"

Yes, it *is* possible for an Event Sink to receive a Notification before 
the SubscribeResponse is received. This gets to your earlier point about 
the fact that we can't say/presume anything about the internals of 
anyone's implementation. It *could* be (indeed it seems likely) that an 
Event Source might process the Subscribe request on a separate thread 
from the thread that is executing the Notify logic. Suppose, then, that 
a Subscribe request is received at "the same time" that a Notification 
is being sent. You could have the following sequence of activities:

1.) The thread processing the Subscribe request adds the NotifyTo EPR to 
the "subscription table" for this Subscription and, shortly thereafter, 
is "swapped out" (i.e. the thread is suspended and another thread is run).

2.) The thread processing the Notification and proceeds to transmit a 
Notification to every NotifyTo EPR in the subscription table, including 
the one added by (1).

3.) The Subscribe thread resumes execution, marshals the 
SubscribeResponse, and transmits it to the Subscriber.

This is just one of the *many *ways in which a Notification could 
precede the SubscribeResponse. There are other scenarios that involve 
the use of non-anonymous URIs in the wsa:ReplyTo EPR of the Subscribe 
request and routing delays, etc. Ultimately we need to recognize that 
the SubscribeResponse and Notification messages are independent from one 
another and that, short of requiring *all* implementations of 
WS-Eventing to use WS-RM (with an InOrder Delivery Assurance no less), 
there is no way to force any particular ordering between them. Note this 
applies to the SubscriptionEnd message as well.

The upshot for the Subscriber/Event Sink is that you need to have your 
NotifyTo and EndTo listeners set up and ready *before* you send the 
Subscribe request.

BTW, thank you for asking this question. This is just the sort of 
discussion I was hoping the state tables would foster!

- gp

On 9/17/2009 12:12 PM, Li, Li (Li) wrote:
>
> Gil,
>
>  
>
> The following statement helps:
>
>  
>
> Again, by "state" I mean "What messages can the Subscriber/Event Sink 
> expect to send and receive in relation to this Subscription?"
>
>  
>
> According to this definition, I wonder why there is an entry in the 
> Notification/Creating cell in the first table:
>
> [Creating]
> {5}
>
>  
>
> This means the event sink can receive notifications related to a 
> subscription before it is created?
>
> Thanks,
>
> Li Li
>  
>
> ------------------------------------------------------------------------
>
> *From:* Gilbert Pilz [mailto:gilbert.pilz@oracle.com]
> *Sent:* Wednesday, September 16, 2009 3:46 PM
> *To:* Li, Li (Li)
> *Cc:* public-ws-resource-access@w3.org
> *Subject:* Re: draft 3 of WS-Eventing state tables
>
>  
>
> I don't think these tables define "internal states" so much as 
> "expectation states" with regards to the messages that the consumer 
> and the provider can expect to send and receive. For example, an Event 
> Source cannot expect to send a successful wse:Unsubscribe message for 
> a Subscription unless that Subscription is in the "Created" state.
>
> The information in these tables is supposed to duplicate the 
> information that is contained in the normative text of the spec but 
> present it in a manner that can be easily consumed by developers. A 
> desired side-effect of the process of constructing these state tables 
> is to flush out any areas where the spec is unclear about the effects 
> of particular messages. For example, if a Subscriber sends a 
> wse:Unsubscribe message and receives a wse:EventSourceUnableToProcess 
> fault in response, what is the state of the Subscription in question? 
> Again, by "state" I mean "What messages can the Subscriber/Event Sink 
> expect to send and receive in relation to this Subscription?" Can it 
> assume that Notifications for this Subscription will continue to be 
> transmitted by the Event Source?
>
> - gp
>
> On 9/16/2009 7:34 AM, Li, Li (Li) wrote:
>
> Gil,
>  
> Thanks for updating the tables. As I understood it, the purpose of this
> proposal is to enhance interoperability between WS-E web services
> without getting into any implementation details. Since these tables
> define internal states of SOAP endpoints that are apparently outsides
> the scope of web service interfaces, how do you expect these tables be
> followed by implementations? In other words, what information in these
> tables is not already in or implied by the WS-E spec?
>  
> Thanks,
>  
> Li Li
>  
>  
>  
>