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

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 13:53:44 UTC