Re: Issue 59: A use case -- out-of-phase HTTP

Under the framework I sent, I think, most of the work that PAOS does is
already done.  In particular, the exact state transitions are already
defined for a request/response operation.  The key (and very useful) bit
that PAOS adds is a standard way to get the ball rolling: by sending an
HTTP request with a PAOS header.

Once that's done, a conversation can happen.  For example, a series of
two requests to the mobile device looks like:

    * HTTP request with PAOS header
    * HTTP response with first SOAP request
    * HTTP request with first SOAP response
    * HTTP response with second SOAP request
    * HTTP request with second SOAP response
    * HTTP 202 response (PAOS says 200, but 202 would be consistent with
      what we've already discussed here).

or for another example, a request followed by a one-way message would
look like

    * HTTP request with PAOS header
    * HTTP response with SOAP request
    * HTTP request with SOAP response
    * HTTP response with SOAP one-way message

while if it happened in the other order, we would see

    * HTTP request with PAOS header
    * HTTP response with SOAP one-way message
    * HTTP request with PAOS header
    * HTTP response with SOAP request
    * HTTP request with SOAP response
    * HTTP 202 response

Finally, if the HTTP server doesn't have anything to send (e.g., doesn't
feel like requesting anything) we get

    * HTTP request with PAOS header
    * HTTP 202 response

There is no need to define a PAOS request/response and PAOS response MEP
per se.  Instead, you have

    * a generic WSDL request/response and a generic WSDL one-way
    * a SOAP over HTTP request binding
    * a SOAP over HTTP response binding (much like the existing "SOAP
      response" MEP)
    * a generic rule that an HTTP server should send a 202 response if
      it doesn't have anything else to send (the same rule covers
      several cases in the forward HTTP case, including one-way over
      HTTP request and async request/response initiated over HTTP)
    * a rule for sending a PAOS request in order to start a conversation.

All items but the last are reusable elsewhere, and the last is useful
for initiating any kind of conversation, not just request/response and
response.

John Kemp wrote:

> Hello David,
>
> ext David Hull wrote:
>
> >One of the use cases captured during the work of the async task force
> >involved a mobile phone or other such mobile device.  In this scenario,
> >the phone would send a dummy HTTP request to an HTTP server.  The HTTP
> >/response/ to that request would contain a SOAP /request /message.  The
> >phone would then process the request and make a second HTTP request to
> >the server.  This /request/ would contain the phone's SOAP /response
> >/message.
>
> >This uses a single protocol (HTTP), with multiple connections, and was
> >put forth as a scenario at least one party (Nokia, as I recall?) would
> >be interested in seeing supported.  Can this scenario be handled by any
> >of the present proposals?
>
>
> I have not yet seen a proposal that fully handles this case. The current
>  PAOS specification [1] uses non-WS-Addressing SOAP header blocks. I
> will note, however, that Dave Orchard did address PAOS in [2], providing
> for the presence of a paos:reverseBinding element in a WSDL document,
> and noting that the paos:reverseBinding would still need to be written.
>
>  If not, do we have a plausible theory about
>
> >how we would handle it?
>
>
> It seems to me that we would merely need to complete the definition of
> the paos:reverseBinding as mentioned in [2].
>
> Cheers,
>
> - JohnK
>
> [1] http://www.projectliberty.org/specs/liberty-paos-v1.1.pdf
> [2]
> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Nov/0014.html