RE: T is for Transfer

On Thu, 28 Mar 2002, Mountain, Highland M wrote:

> Given the reality of the industry, we need to find the best resolution to
> both sides of the transport/transfer argument. SOAP envelopes will be "sent"
> via HTTP, BUT we also need to preserve SOAP's protocol neutrality.  I like
> Joe's PDU view of the SOAP envelope sitting on top of HTTP(see snip below),
> but HTTP does provide features we should not ignore.  Concerns addressed by
> Scott Cantor (and others) should be addressed by separate HTTP Bindings.

Consider a situation where a message from processor X is expected to
be processed in four steps, by processors A, B, C, D.  Assume further
that the message is passed along the line using HTTP, except between
one pair.  Diagramatically:

	X --> A --> B ==> C --> D

Between B and C, in this instance, some other protocol is used for
transfer/transport.

It should actually make no difference at all between which pair the
non-HTTP underlying protocol is used.  The result should be the same,
and it should be the same whether the process fails at any step or is
successful.

This would seem to severely constrain the degree to which information
from the HTTP protocol layer is useful.  Presumably if there is a
fault, it needs to be communicated back to X identically whether it
occurs before or after the non-HTTP link (the ==>).

Consider another chain of processors

	X --> A --> B --> C1 -->
	              ==> C2 --> D

In this case B has two or more logically equivalent 'C' processors, at
least one of which is reached over an HTTP link (C1) and at least one
of which is reached over a non-HTTP link (C2).  We might be doing this
for resiliency or to improve performance.

This illustrates the same principle.  If SOAP is to make any sense,
C1 and C2 should return exactly the same information to B.  The more
HTTP is blurred together with SOAP, the more difficult this is going
to be.  But it should be utterly simple.  Whoever is coding up what
happens at B should not have to know whether the data from C is
actually coming from C1 or C2.

In particular if there is a fault at C1 or C2, it should look exactly
the same at B, A, and X.

--
Jim Dixon  jdd@dixons.org   tel +44 117 982 0786  mobile +44 797 373 7881
---------- THAT'S A CHANGE OF ADDRESS: I'm no longer jdd@vbc.net --------

Received on Friday, 29 March 2002 15:49:09 UTC