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

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.  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"?  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?

- 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 Thursday, 17 February 2005 15:11:45 UTC