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

In thinking about this discussion I'd like to compare this to a 
hypothetical situation...

Let's say that when WS-Addressing was first created, instead of a single 
wsa:ReplyTo EPR/Header the authors created two of them - one for async 
responses and one for sync responses.  After all, they are very different 
message exchange patterns - in one case you need a real (addressable) URI, 
in the other you don't, you'll always use the current transport's 
back-channel.  So, let's say we had this:
<wsa:AsyncResponse>
  <wsa:Address> xs:anyURI </wsa:Address>
  <wsa:Ref-Params...>
  ...
</wsa:AsyncResponse>
and
<wsa:SyncResponse>
  ...
</wsa:SyncResponse>

If we had this situation and then someone suggested that we combine them I 
could hear a lot of the same comments being made.  We're overloading too 
many things. How can I tell what's going on?  The semantics of these two 
things are so different, you can't possibly combine them.  The application 
must know how the messages are being sent. 

And yet we do have these two very different message transport mechanisms 
combined into one.  The concept of an EPR handles both of these situations 
very well.  It even deals with other messaging patterns.  For example, in 
WSDD we see it dealing with broadcasting.  Composing in with MC we allow 
for polling-style delivery.  Making the uri something like 
"java:myClassName" (in some soap stacks) will invoke local services and 
never hit the wire.  And there are probably others.  The point in this is 
that the EPR was designed to convey the notion of not just where to send a 
message but how to send a message.  And this single entity manages to do 
this well for all other WS-* specs and for all types of messages being 
sent (including WS-Notification).  This entity allows for the application 
(assuming it wants to) to remain totally unaware of the details of the 
target service- all it needs to do is pass around an EPR and some 
lower-level piece of code (the WS-Addressing layer) will automagically 
deal with the details of how to actually interact with the target service.

So, I still come back to the same questions I had on this week's call:
- why is WS-Eventing so special that it can't reuse the EPR as is?  Why 
does it need a "mode" attribute when no one else seems to?
- what is fundamentally different between NotifyTo and ReplyTo ?  Any 
message exchange pattern that I would want to do with one of them I can 
imagine a case for it being used in the other. 

Wu,
  And I'd ask you to look at the AcksTo EPR in WS-ReliableMessaging [1]. 
It is not an EPR where "Responses" go. Its meant to be used for new 
(one-way) messages being sent by a service - basically the same thing as 
PushMode+NotifyTo.  And in that specification that had to deal with sync, 
async, addressable and  non-addressable destinations - the same way 
WS-Eventing does.  They managed to solve it by reusing the EPR concept - 
as is.

[1]  http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.2-spec-os.html

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.



Bob Freund <bob.freund@hitachisoftware.com> 
Sent by: public-ws-resource-access-request@w3.org
03/25/2009 05:55 PM

To
"Chou, Wu (Wu)" <wuchou@avaya.com>
cc
public-ws-resource-access@w3.org
Subject
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