W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2001

SOAP over TCP/IP

From: Oisin Hurley <ohurley@iona.com>
Date: Wed, 18 Jul 2001 20:33:40 +0100
To: <xml-dist-app@w3.org>
Message-ID: <AGECJKEBCGNJBAPDAFIEIEEECBAA.ohurley@iona.com>
In a moment of weakness, I volunteered to write up a list of 
SOAP delivery 'invariants' with respect to HTTP and TCP/IP.
The intention here is to extract from the current HTTP binding
use of protocol features that are not available from TCP/IP
and so must be explicitly provided to communicate using that
protocol. The point of the exercise is to take a step in the
direction of producing a useful (if not 100% complete) notion
of what binding may do to enable the delivery of SOAP messages
over various carrier protocols.

This is not exhaustive, please contribute your own points and
I will summarize...

1. Request/response correlation
This is a familiar topic to the readers of this list. HTTP 
provides an implicit correlation by enforcing a synchronous
same-connection request/response turnaround. This means that
HTTP requests can be pipelined in-order but cannot be 
interleaved. On the other hand, TCP/IP does not enforce any
high-level message pattern, so messaging/RPC over TCP/IP
needs to provide its own correlation.

2. Request/response message delimiting
When an HTTP request is sent, there is delimiter information
in the form of CR/LFs (or alternatively a Content-Length
header). This is something that will have to be added for 
use over TCP/IP

3. Endpoint identification
HTTP has the concept of an endpoint above and beyond the simple
host/port approach - a URL fragment context is used to point to
what is effectively a logical endpoint within a HTTP server.
This endpoint identification would have to be supplied by a 
TCP/IP binding.

4. Error framework
HTTP provides an error framework - there are fixed error codes 
for specific semantics. There is some talk that SOAP faults will
take advantage of this to indicate a that a HTTP response contains
a SOAP fault. TCP/IP does not have the notion of this framework
and so cannot provide this facility - and it's probably not a 
good idea to add, IMHO :)

There are two very interesting issues that the whole binding
thing brings up:

 . application of binding information, in-band or out-of-band?
 . possible negotiation of binding semantics

We should really discuss these too - to make sure that if we
manage to solidify the binding concept that any bindings are
actually useful!

Comments,

 --oh
Received on Wednesday, 18 July 2001 15:31:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:02 GMT