- From: Oisin Hurley <ohurley@iona.com>
- Date: Wed, 18 Jul 2001 20:33:40 +0100
- To: <xml-dist-app@w3.org>
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 UTC