W3C home > Mailing lists > Public > public-ws-async-tf@w3.org > February 2005

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

From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
Date: Wed, 16 Feb 2005 11:38:52 -0800
Message-ID: <4213A14C.1010907@oracle.com>
To: David Hull <dmh@tibco.com>
CC: public-ws-async-tf@w3.org

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).

-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 19:48:00 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Wednesday, 16 February 2005 19:48:00 GMT