Re: R: Issue 6692 (re-send for the list)

Wu,
Yes, I am guessing that you meant 6432, no worries.

Here is some of what I think might be blocking a consensus on this  
issue.  There may be more, but this is my guess.

1)
It is my understanding that in order to receive a notification, one  
must subscribe.
That would make all notifications solicited, doesn't it?  Are you  
anticipating out-of-band communication of EPRs to which the  
Subscription Manager might send notifications?

2)
The definition of Push Mode
"A delivery mechanism where the source sends event messages to the  
sink as individual, unsolicited, asynchronous SOAP messages."

There are two issues with this definition I think.
a) unsolicited: well, see above, there exists a subscription, so the  
notification have been solicited.
b) Asynchronous:  Asynchronous with respect to what?  The underlying  
protocol back channel? Other activity? It is a very difficult term and  
needs MUCH clarification before it has meaning.

So when the above (in the minds of many who have been through the WS- 
Addressing debates and other protocols based on WS-Addressing, the  
definition of push mode becomes:
"A delivery mechanism where the source sends event messages to the  
sink as individual, SOAP messages."

Now this might be contrasted with a hypothetical "Pull Mode"  
definition, which is not defined, but I will make an attempt:
Pull Mode
"A delivery mechanism where a client retrieves a notification by  
querying the Subscription Manager"
However, the spec has not defined a message that might retrieve a  
notification, but if it did, then the replyTo in that message might be  
wsa:anonymous, in which case the response would be expected on the  
transport back-channel, or maybe if replyTo were a full addressable  
uri, then the message would be returned to that address.  This is what  
a lot of folks think of as an asynchronous message, it is asynchronous  
with respect to the connection that contained the request, or as  
sometimes described, asynchronous with respect to the underlying  
transport.
But, we have not defined it, but note that it does change the behavior  
and add constraints and demands to the subscription manager.  It is  
conceivable that queueing behavior of this hypothetical pull mode  
might be implementation specific with no protocol defined quality of  
service defined to allow for the broadest possible scope of  
implementation.

At this point Eventing has really defined only one mode. which is  
labeled push, and nowhere is there defined anything (yet) concerning  
queueing behavior.

Now suppose we deal with the issue concerning a non-addressable  
notification destination and suppose that we might try to achieve that  
by composition with MC.  MC usually is implemented in conjunction with  
WS-Addressing.  Usually the higher level protocol is unaware of the  
use of MC, it just sits on top of it. much the way that the higher  
level protocol is unaware that it is sitting on on any particular  
implementation of tcp/ip or http for that matter.  It is just a form  
of transport that has the effect of making communication with non- 
addressable endpoints possible.  It is true that it works by polling,  
but it does it by polling MC, not the higher-level protocol.  There is  
no quality of service guarantee and yes, MC does require a fifo  
implementation within it, but size and other characteristics are  
implementation specific.
The client protocol would see a notification just as if it were  
receiving it without MC, it is just that MC polled for it.
So in this regard, there is no difference between "Push" mode to an  
addressable endpoint and this method of dealing with non-addressable  
endpoint with MC.

I have a few observations concerning the debate:
A) Li is correct, that the delivery would not be instantaneous, but it  
is not instantaneous with http over tcp/ip either since the speed of  
transport, the distance latency or even the number of re-tries are  
unknown.  I can imagine deep-space notifications where the time would  
be on the order of months
B) polling is like sampling, you have to poll at a rate high enough to  
keep up with the anticipated message rate.  There is no way around  
this unless several notifications are sent in one message.  One  
possible difficulty with this is that eventing today states that there  
are no constraints on notification messages.  What would happen if  
successive messages had different mime types? http allows for only  
one.  So in that case, unless constraints are imposed, messages need  
to be sent one by one anyway.
C) Anything other than the one form of notification delivery we have  
defined will probably require additional protocol messages and indeed  
extend the protocol in a behavioral sense.
D) There are very few ways to send messages to a non-addressable  
endpoint.   The two main techniques are polling and tunneling.  It  
might be most convenient that we allow users to pick whichever they  
choose.

To accommodate current implementations that have a push mode defined,  
I might suggest that we add an extensibility point in place of that  
attribute to allow for use of it, but I don't think the protocol cares.

I hope that this is helpful
-bob




On Mar 25, 2009, at 3:26 PM, Chou, Wu (Wu) wrote:

> Bob,
>
> I would like to share my thoughts and clarify the point I made in  
> the WG call regarding issue 6692 (removing "mode") and the use cases  
> of non-push mode event delivery,
>
> Issue 6542 (makeConnect) is a concrete use case of non-push mode  
> event delivery. Since it won't fit in WS-E push mode definition, it  
> proposes/needs to change WS-E push mode definition/semantics. As  
> discussed extensively by Doug, Li, Geoff, etc. as well as the  
> question you raised, makeConnect needs to pull event from source and  
> it is not WS-E push mode, e.g. it is not an "unsolicited" event  
> delivery that controlled solely by the event source as specified by  
> WS-E push mode specification.
>
> "Push" and "pull" are two distinct concepts with well defined  
> semantics. This is even more so in WS-E with its definitive push  
> mode semantics specified in the specs (Section 2.2 Terminology),  
> e.g. it must be [unsolicited], [individual], [soap binding],  
> [asynchronous], [notification] to send event from source to the sink.
>
> I am sure there are many other cases that won't fit into WS-E push  
> mode. The point I would like to make is: "redundancy" issues should  
> be dealt with after we finish all proposals with new semantics to WS- 
> E, since redundancy won't hurt the validity/applications of the  
> specs. We need to see the whole tree before trimming a branch off,  
> because "redundancy" may change as new semantics being added.
>
> Moreover, we should deal "redundancy" with the sensitivity that WS-E  
> has been widely implemented. It influences many standards from  
> various standard bodies. Unless it is absolutely painful and  
> necessary, I would hope to avoid minor redundancy changes which have  
> no impact to application semantics.
>
> Many thanks,
>
> - Wu Chou.
>
> Wu Chou, IEEE Fellow, Ph.D. | Director |Avaya Labs Research | AVAYA  
> | 233 Mt. Airy Road| Rm. 2D48 | Basking Ridge, NJ 07920 | Voice/Fax:  
> 908-696-5198 / 908-696-5401 | wuchou@avaya.com
>