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@univa.com