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

Hi Henrik,

> -----Original Message-----
> From: Henrik Frystyk Nielsen [mailto:frystyk@microsoft.com]
> Sent: 25 January 2001 20:03
> To: Oisin Hurley; xml-dist-app@w3.org
> Subject: RE: [R6xx, R7xx] Application of XP requirements to SOAP 1.1
> 
> 
> Oisin,
> 
> Good start! Here are a few questions/comments...
> 

<snip/>

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

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

Regards

Stuart

Received on Monday, 29 January 2001 13:15:48 UTC