Re: The role of transfer protocols

Comments inline.

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.
>  
>
Noted.

What option would you suggest for the use case I had in mind?  Recall, I
need acknowledgment that the ultimate recipient got the message, not
that a particular HTTP server got the message (I'm not going to hold an
HTTP connection open until the receiver comes back on line, so it can't
act as the HTTP server, even via proxy), or that my SMTP server got the
message (since that says nothing at all about whether my receiver got
the message).

>> 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.
>  
>
Would you see these as being individually addressable via URI?  If so,
whatever for?  If not, haven't we left REST-land?

>> 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.
>  
>
Hmm ... suppose I POST a copy of this email to some site.  Later, you
GET a copy.  Then you send me an email that says "Hey, I got your
message."  Is this in violation of some architectural principle?  I'm
going to assume not.

Now suppose I POST a copy of this email to some site, expecting you to
retrieve it and email me when you get it.  You GET a copy and email me
acknowledgment.  Are we still on safe ground?

Now suppose I've devised an end-to-end protocol whereby (in a particular
deployment) I POST an XML document to a forwarding agent, someone else
GETs that document and emails back an XML document as an
acknowledgment.  Still OK?

What if the message, the acknowledgment or both happen to be SOAP envelopes?

In any case, "the SOAP HTTP binding is a *transfer* protocol" is a
conclusion, not a premise.  It's definitely not a shared premise, and I
don't take it as proof per se that there is an incorrect layering at
work (or of anything else, really).

I'm more interested in the statement that "[A] message produced by this
binding has application semantics that are a function of information in
*both* the HTTP and SOAP envelopes.", particularly if we can define
"application semantics" carefully enough to separate end-to-end
acknowledgment from other forms.  At first blush, though,  this seems a
bit tricky.  A significant portion of HTTP's usefulness stems from its
use of TCP (or other reliable transport).  Shall we also say that HTTP
is an extension of TCP (or another reliable transport) and not layered
on top of it, since the (application-level?) semantics depend on
information in both HTTP and TCP envelopes?

This is why I would rather talk about what messages flow where and not
worry so much about what's a transfer protocol, what's application
semantics, what's layering and so forth.  Such terms are only useful
when they provide an unambiguous shorthand in a given context.  That's
pretty clearly not happening here.

>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.
>  
>
I'm pretty sure you're confusing levels here or otherwise
misunderstanding the case in point.  What exact breakage did you see?

>So, in general, I'm objecting to any proposal for new SOAP-related
>work which is premised on the SOAP/HTTP relationship being layered.
>  
>
As far as I can tell, "the SOAP/HTTP relationship being layered" is a
somewhat subjective and ambiguous notion.

>Cheers,
>
>Mark.
>
>  
>