Re: The role of transfer protocols

In my previous message, I stated that "In any case, 'the SOAP HTTP
binding is a *transfer* protocol' is a conclusion, not a premise."  This
is not quite what's going on.  Depending on what exact properties make a
protocol a "transfer protocol", the statement may be perfectly
reasonable, particularly since "transfer protocol" is the "TP" in HTTP.

The real problem comes from the unstated premise that transfer protocols
can't also be transport protocols, with the presumed definition of
"transport protocol" as one that serves strictly to move data around in
some larger context.  This is in fact one of the major points of
contention.  Arguing that there is some sort of incorrect assumption
about layering /because/ SOAP/HTTP is a transfer protocol is only valid
if we accept the hidden premise.

Sorry for any potential confusion.

Mark Baker wrote:

>On 1/9/06, David Hull <dmh@tibco.com> 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.
>
>  
>