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

+1

On 26 Mar 2009, at 23:06, Gilbert Pilz wrote:

> Taking this logic a step further, it seems that the only reason WS- 
> Eventing might need a "Mode" switch is if the Subscriber wanted the  
> Notifications transmitted via some mechanism that was not  
> representable by an EPR; in other words a mechanism that fell  
> outside the boundary of "web services" (to use that term loosely).  
> Since such a mechanism would probably be out of scope for the WS-RA  
> WG, it seems that Dave's quest for a use-case that justifies the  
> need for a Mode switch is doomed to failure (which is not to say you  
> can't support such cases through the use of existing extension  
> mechanisms - only that WS-Eventing can't say anything about them  
> other than they may exist).
>
> - gp
>
> Doug Davis wrote:
>>
>>
>> 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
>>
>>

Take care:

     Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
     Fujitsu Laboratories of Europe Limited
     Hayes Park Central
     Hayes End Road
     Hayes, Middlesex  UB4 8FE
     Reg. No. 4153469

     +44-7590-293439 (Mobile)








______________________________________________________________________
                                        
 Fujitsu Laboratories of Europe Limited
 Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE
 Registered No. 4153469
 
 This e-mail and any attachments are for the sole use of addressee(s) and
 may contain information which is privileged and confidential. Unauthorised
 use or copying for disclosure is strictly prohibited. The fact that this
 e-mail has been scanned by Trendmicro Interscan and McAfee Groupshield does
 not guarantee that it has not been intercepted or amended nor that it is
 virus-free.