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

michael.eder@nokia.com wrote:
> Hi Anish,
> 
> I was thinking a bit about this problem.  I assume one reason you would do this
> is that node B would need to go off and do some processing and that
> is one reason the response could not be synchronous. 

Yes that is one of the reasons.

> Is there any reason that
> node A could not issue another, different request from node B before
> polling node B, or if node B came back with a "try-again"?  

I'm not sure I understand what you are asking.
Are you talking about the scenario where there are two outstanding 
requests (m1's) from node A to node B?

> Would this
> put any additional restraints on the SOAP of WSDL bindings?  I think
> the problem here is there needs to be something in the m21 to correlate
> it with the m11.  How would this work?
> 

I think the value of the "Location" HTTP header in m12 can be used to 
disambiguate the request (at node B). I.e., poll for different requests 
would use different URLs.

> - Michael Eder
> 
> -----Original Message-----
> From: public-ws-async-tf-request@w3.org
> [mailto:public-ws-async-tf-request@w3.org]On Behalf Of ext Anish
> Karmarkar
> Sent: February 16, 2005 04:17 AM
> To: public-ws-async-tf@w3.org
> Subject: Usecase 4: Asynch req-res -- polling style
> 
> 
> 
> 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:56:09 UTC