RE: [R6xx, R7xx] Application of XP requirements to SOAP 1.1

>>>R600 - transport protocol neutrality
>>>
>>>SOAP 1.1 has an implicit dependency on a synchronous request/response
>>>transport protocol to achieve correlation. It has a further implicit
>>>dependency on SOAP processor endpoint information being transport
>>>protocol endpoint information.
>>
>>SOAP is fundamentally a one-way message so it doesn't know about
>>correlation and therefore doesn't really have an implicit dependency on
>>a request/response protocol. Of course, what you get when you use a
>>request/response protocol is some kind of correlation but there is there
>>a reason why one couldn't do that as a SOAP header (XML protocol
>>module)?

>In principle I don't think there is a reason why one couldn't, but one would
>then be faced with a choice. If I send say an RPC request with SOAP over
>HTTP there would have to be some means of either the sender or receiver (of
>the request) indicating that either an immediate synchronous response was
>required or that a separate message needs to be returned and where it ought
>to be sent.

Yes but I would think that this is because HTTP defines who is the client and
who is the server and defined a request/response message exchange pattern
(let's keep the word 'RPC' out as this is a different discussion altogether
:).

As an example, one can imagine sticking a SOAP message into a mail message in
which case it takes on the store and forward message exchange pattern of SMTP.

In other words, because both HTTP and SMTP define message exchange patterns,
SOAP messages can not avoid taking on those patterns unless one wants to
totally override the underlying protocol in which case I can't see any reason
to use that protocol in the first place.

So, yes, I do agree that one faces a choice - but I am not sure it is not a
choice of whether SOAP can do one-way or request/response but rather which
underlying protocol one picks.

>If you go down the SOAP is fundementally one-way I think your driven to a
>position for SOAP over HTTP where in general SOAP/HTTP installation need to
>supply both HTTP client and HTTP server - to balance out the aysmmetry
>intrinsic in HTTP.

Yes, I don't believe that is possible. The only mechanism that HTTP hints at
is the 202 "Accepted" status code but it still doesn't prevent a response from
being generated. However, it allows the server to say that it knows that it is
not ready to send any other response.

>If the domainant installation configuration for SOAP/HTTP
>is SOAP/HTTP client at the sending end and SOAP/HTTP server at the receiving
>end it feels more like a request/response model as Oisin suggests and the
>one-way capability (by virtue of a null response) feels more like one-way
>single direction.
>
>I like the one-way view... after-all that's the model for most of the LANs
>etc. that underly all this stuff... but it only really rings true for me if
>your ability to send (at all) is not constrained by the operation of the
>underlying protocol.

What we really have to evaluate here is whether it is possible to send SOAP on
top of a transport that doesn't enforce any message exchange pattern - like
TCP for example - although we don't have to define such a binding.

Henrik

Received on Wednesday, 31 January 2001 14:21:40 UTC