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

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.

Does that help?

>
> -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 Wednesday, 16 February 2005 20:03:25 UTC