Re: Usecase 4: Asynch req-res -- polling style

David Hull wrote:
> Anish Karmarkar wrote:
> 
>> Hi David,
>>
>> I have not looked at the pull notification discussion in WS-N. Will do 
>> so, thx for the pointer.
>>
>> But, I am a little confused by the use of the term 'callback', which 
>> to me implies a 'push' style, whereas this usecase embodies a 'pull' 
>> style.
>> Perhaps I misunderstood what you were trying to say (very likely since 
>> I haven't read the discussion in WS-N).
> 
> 
> Sorry. S/callback/notification/.  In other words, this situation looks a 
> lot like pull notification, except that we expect exactly one 
> "notification" message (the reply) instead of zero or more in the normal 
> case of notification.
> 

Isn't that also the difference between "normal" notification and 
callback? One has zero or more messages sent whereas the other involves 
only one message (unless there is a failure).

IMHO: The important thing here is that asynch req-response (callback and 
poll style) are very simple and important usecases for which one should 
not have to require a complete notification infrastructure (which 
involves subscription mgmt) or BPEL.

Of course if there is commonality which can be leveraged/reused without 
requiring the complete infrastructure of BPEL/notification, it would 
make sense to do so.

> Does that help?
> 

Yes it does. Thx.

>>
>> -Anish
>> -- 
>>
>> David Hull wrote:
>>
>>> It occurs to me that this is very much like the scenario for "pull" 
>>> notification currently being discussed in WSN.  The only differences 
>>> I see are that we expect exactly one callback (as opposed to zero or 
>>> more), and the callback message will be referenced to a single reply 
>>> message.  I'm not sure exactly what commonality is to be captured 
>>> here, but I'm pretty sure there is some.  At the very least, any 
>>> mechanism for pull notification can handle this case.  It may well be 
>>> overkill, but it will work.  There may also be simpler mechanisms 
>>> that work for this case that aren't suitable for pull notification.
>>>
>>> Anish Karmarkar wrote:
>>>
>>>>
>>>> Usecase 4: Asynch req-res -- polling style
>>>> ---------------------------------------
>>>>
>>>> 1. Description of the scenario
>>>>
>>>> This usecase consists of two app-level/soap-level messages: m1 and m2.
>>>> Message m1 is sent by node A to node B over transport t1. Message m2 
>>>> is sent by
>>>> node B back to node A over transport t2. Transport t1 and t2 may be 
>>>> of the same
>>>> type/protocol. Both messages m1 and m2 are initiated by node A using 
>>>> the
>>>> underlying transport t1 and t2. Node A polls for message m2 from 
>>>> node B. If m2
>>>> is ready then node B sends m2 to node A upon a "query" by node A. If 
>>>> m2 is not
>>>> ready then node B informs node A that the message is not ready.
>>>>
>>>> ------       m1     ------
>>>> node A     ----->   node B
>>>> ------              ------
>>>>              m11
>>>> t1         ----->   t1
>>>>            <-----
>>>> ------       m12    ------
>>>>
>>>> m11: transport level request/connection initiation from node A to 
>>>> node B. This
>>>>      message carries m1 as the payload
>>>> m12: transport level response from node B to node A with location of 
>>>> the soap
>>>>      level response to poll for. There is no payload.
>>>> [note there may be more than two transport-level messages, the 
>>>> figure above
>>>> uses the simplest case]
>>>>
>>>>
>>>> ------       m2     ------
>>>> node A     <-----   node B
>>>> ------              ------
>>>>              m21
>>>> t2         ----->   t2
>>>>            <-----
>>>> ------       m22    ------
>>>>
>>>> m21: transport level request/query/connection initiation from node A 
>>>> to node B.
>>>>      This message does not carry any payload.
>>>> m22: transport level response back to node A from node B which 
>>>> either says
>>>>      "try-again" with no payload or carries m2 as the payload. If it 
>>>> says
>>>>      "try-again" then node A may keep polling for m2.
>>>> [note there may be more than two transport-level messages, the 
>>>> figure above
>>>> uses the simplest case]
>>>>
>>>> For this usecase both t1 and t2 are assumed to be synchronous 
>>>> transports
>>>> (like HTTP). I suppose it would be possible to use asynch transport to
>>>> implement this usecase, but I'm assuming that the lower water-mark for
>>>> declaring success in this case would be if we enable this using SOAP 
>>>> over HTTP.
>>>>
>>>>
>>>> 2. Can we achieve this case now with the current specs?  With how much
>>>>    "squinting"?
>>>>
>>>> a) For SOAP 1.1 over HTTP
>>>> No we cannot achieve this using the current specs.
>>>>
>>>> b) For SOAP 1.2 over HTTP
>>>> Yes it is possible to do this using existing specs.
>>>> There is minimal squinting required to do this (details below).
>>>>
>>>> c) For WSDL 1.1
>>>> No we cannot achieve this using the current specs.
>>>>
>>>> d) For WSDL 2.0
>>>>
>>>> Yes it is possible to do this in existing spec with a minor tweak.
>>>>
>>>> 3. What is the minimal change that would be necessary to what 
>>>> spec(s) in
>>>>    order to achieve this case?
>>>>
>>>> a) For SOAP 1.1 over HTTP
>>>> Message m1 can be sent using SOAP1.1/HTTP binding using the 
>>>> clarification made
>>>> by WS-I Basic Profile 1.0/1.1 -- but this will require additional 
>>>> clarification
>>>> along the lines suggested by Marc (see thread starting at [1]).
>>>> Message m2 cannot be sent using SOAP1.1/HTTP binding currently used 
>>>> as it does
>>>> not allow a SOAP message to be received in HTTP response without a 
>>>> SOAP message
>>>> in the HTTP request. The SOAP 1.1/HTTP binding will have to be 
>>>> modified to
>>>> achieve this.
>>>>
>>>> b) For SOAP 1.2 over HTTP
>>>> See the thread starting at [1].
>>>> i) Specify somewhere how this is done (as outlined in [1])
>>>> ii) Clarify ambiguity wrt to the next state of a HTTP requestor when 
>>>> a 3XX
>>>> status code is received in the case of SOAP1.2/HTTP binding. This 
>>>> could perhaps
>>>> be done as SOAP 1.2 errata.
>>>>
>>>> c) For WSDL 1.1
>>>> One clarification (very little squinting) and one invention is needed:
>>>> i) clarification - how 303 status code is handled along with
>>>> Location/Retry-After HTTP headers
>>>> ii) Invention/modification - modify the exiting binding or invent a new
>>>> extensibility element that says that something like SOAP 1.2 
>>>> Response MEP is
>>>> used in conjunction with SOAP one-way.
>>>>
>>>> In addition if there is a requirement to allow for t1 != t2 then 
>>>> this will
>>>> require an additional invention, as the transport that is specified on
>>>> soap:binding element applies to both the input and output message.
>>>>
>>>> d) For WSDL 2.0
>>>> This will have to be expressed as a single WSDL operation which 
>>>> implements two
>>>> SOAP MEPs.  Currently WSDL 2.0 does not allow this for wsoap:mep 
>>>> attribute on
>>>> the wsdl20:operation element. Either the value of wsoap:mep should 
>>>> be changed
>>>> to type 'list of URIs' or allow wsoap:mep per message (message) in 
>>>> the binding.
>>>> I prefer the 1st solution.
>>>>
>>>> 4. What would be the "ideal" solution if we could change anything to 
>>>> get
>>>>    this case covered?
>>>>
>>>> a) For SOAP 1.1 over HTTP
>>>> i) Clarify/specify that SOAP 1.1/HTTP binding can be used to support
>>>> SOAP-response MEP (along the lines of SOAP 1.2) and how this is done 
>>>> (backport
>>>> SOAP 1.2 SOAP-response MEP to SOAP 1.1)
>>>> ii) rules around status code 303 and Location/Retry-After HTTP 
>>>> headers (work
>>>> common to SOAP 1.2 and SOAP 1.1)
>>>>
>>>> b) For SOAP 1.2 over HTTP
>>>> Ideal solution is to make the clarification(s) in 3.b as SOAP 1.2 
>>>> errata.
>>>> The next best solution is to make the clarification(s) in 3.b in the
>>>> SOAP1.2/HTTP binding in WSDL.
>>>>
>>>> c) For WSDL 1.1
>>>> see 3.c above
>>>>
>>>> d) For WSDL 2.0
>>>> see 3.d above
>>>>
>>>>
>>>> -Anish
>>>> -- 
>>>>
>>>> [1] 
>>>> http://lists.w3.org/Archives/Public/public-ws-async-tf/2005Feb/0005.html 
>>>>
>>>>
>>>
>

Received on Monday, 21 February 2005 18:29:05 UTC