[graap-wg] Re: More async/asymmetry comments

[Karl Czajkowski]

On Feb 23, Karl Czajkowski loaded a tape reading:
...
> Additionally, I am persuaded that as a practical matter, it may be
> worth rendering the asymmetric (client-server) interface to support
> asynchronous (post+poll) messaging because of limitations in the
> binding and tooling world today.

I should add that two specific SOAP/HTTP limitations have changed my
mind (I am sorry I had forgotten about these in earlier discussions):

  1) In/out message exchanges are correlated by HTTP post/response
     ordering and so would block up an HTTP socket until done.  I was
     wrongly thinking that an out message could be delayed while other
     exchanges continued on the same socket.

  2) HTTP post pipelining is discouraged in the HTTP spec, so even 
     the "in" half gets blocked as opposed to just blocking responses
     until the slow one occurs.

So in practice, every concurrent blocking in/out exchange will result
in another socket from the client to whomever he is invoking.

A much better HTTP-based binding solution would allow two sockets to
handle any number of outstanding requests by:

  1) Allowing pipelining of posts and having simple empty responses
     for acknowledgement of receipt on one socket, with additional
     correlating message headers.

  2) Having pipelined gets to retrieve the responses on another
     socket, in what ever order they are produced and using the
     correlation headers to sort them out.

But obviously that is not a solution today.

karl

-- 
Karl Czajkowski
karlcz at univa.com