Re: The role of transfer protocols

On 1/9/06, David Hull <[email protected]> wrote:
> Rewinding back to the beginning of the thread, your
> objection seems to be to treating a "transfer protocol" as a "transport
> protocol," but I'm having a hard time understanding what particular sin that
> entails.  For example, a particular scenario I mentioned involved my sending
> a message to a forwarding agent, the recipient retrieving that message
> arbitrarily later, and my receiving an acknowledgment.  This seems harmless
> enough, and I'm afraid I still don't see how it becomes more harmful if one
> or more of those three steps involves HTTP.  Will incorrect behavior result?
>  If so, what and how?

Incorrect behaviour won't result, of course.

My concern is purely with *how* application protocols are used; there
are ways to use them which are consistent with the architectures of
their respective systems, and there are ways to use them which are
inconsistent, and I contend, in the general case and when the option
is available, that the consistent use is best.  I also contend that,
in practice, the option is available most of the time.

>  I would also like a bit of clarification as to what sort of "state" you're
> focusing on, as "state-transfer" could apply to any distributed system at
> all depending on what you choose to call the "state".  In the market data
> example, what state would you say is being transferred?

Market data.  Bids.  Orders.

>  It's quite possible that we are largely in what an old colleague of mine
> would called "violent agreement".  Certainly I would respond to several of
> the responses below with "Right, didn't I just say that?".  However, rather
> than go that quite probably tedious route, I would prefer to spend more
> effort understanding just where we stand and how that plays out in terms of
> moving SOAP envelopes and other data around with various protocols.

I'm confident we're not in agreement.

In your initial WSRX/MEP post to which I responded, you were making an
incorrect assumption about the relationship between SOAP and HTTP.  In
particular, you were assuming a layered relationship (i.e. the same as
the relationship between, say, HTTP and TCP, or TCP/IP and Ethernet). 
But as I've pointed out, the SOAP 1.2 HTTP binding is a *transfer*
binding, with SOAP playing the role of an HTTP *extension*.  This
means that a message produced by this binding has application
semantics that are a function of information in *both* the HTTP and
SOAP envelopes.

So, when you say things like "A request-response operation may be
realized as more than one transport-level exchange", I object because
it's the HTTP envelope portion of the SOAP/HTTP message which
determines what is and what isn't a request or a response.  You made
at least one other incorrect statement in our discussion too about
message reordering not impacting HTTP intermediaries; it also seemed
to be based on this same assumption.

So, in general, I'm objecting to any proposal for new SOAP-related
work which is premised on the SOAP/HTTP relationship being layered.

Cheers,

Mark.