Re: Action Item - Part I: WSRX and MEP signaling on the wire

David,

On 1/5/06, David Hull <dmh@tibco.com> wrote:
>  Mark,
>
>  Sorry to have caused bleeding or other discomfort, but no matter how
> ironclad HTTP may be

I don't recall making any claim about HTTP being "ironclad".  In fact,
I only used HTTP as an example in my last message.  What I did say
though, is that you appear to require a transfer protocol (i.e.
something that provides application layer acknowledgement semantics of
document delivery), yet rather than using HTTP or other transfer
protocols (SMTP, FTP, ...) *as* transfer protocols, you're instead
treating them as transport protocols and then building a new transfer
protocol layer on top.

>  This may not be glatt kosher, but failure to conform to a given paradigm
> does not preclude a  pattern from being useful.  If I have a can of paint I
> need opened and I'm sitting in a room full of screwdrivers, I'm going to use
> a screwdriver and not make a trip to the hardware store for the "right" tool
> (which does exist).

I'm saying that transfer protocols *are* paint can openers.

>  If the concern is that HTTP is not an appropriate tool for sending a stream
> of notifications for which delivery (or transfer, if you prefer) entails
> non-trivial processing on the receiving end, then believe me, I'm
> sympathetic.  Nonetheless, SOAP/HTTP seems quite capable of handling the
> task.  The only problem appears to be that the resulting SOAP "request" and
> "response" messages aren't correlated in the usual manner
>
>  This problem, if it is a problem at all, is of no concern to anything that
> just looks at HTTP.

Quite the contrary.  It would most definitely be a problem for most
HTTP intermediaries, including firewalls and caches, because they rely
on the ordered, implicit correlation of request & responses to
guarantee correct behaviour for the tasks they perform (for better and
worse).  For example, a cache uses the URI in a GET request as part of
the key to store the representation returned in the corresponding
response, where the correlation between request and response assumes
ordering.  So if responses started arriving out-of-order, caches would
cease to function correctly as they would return erroneous responses.

>  Personally, I don't have a problem with using something that happens to
> work well as a transfer protocol in a particular area (synchronous
> request-response) as a transport protocol in the larger context of
> message-based distributed processing.  If that's abuse of notation, protocol
> or both, I'll return to the original point:  Whether successful transmission
> implies successful delivery depends on how you define delivery or,
> equivalently, what you assert that you're acknowledging.

Yes, and HTTP (and other transfer protocols) can signal a variety of
different kinds of successful (and otherwise) *delivery* semantics.

>  If you're ACKing "I got the message", then you don't need to do anything
> special.  Use POST to transfer the message.  If you're ACKing "I got the
> message and queued it for processing," it's almost certainly still OK to
> hold the HTTP response until the message is queued.  If you're ACKing "I got
> the message, established that the cell phone it's ultimately going to was in
> range, and then made sure that it got to said phone," then holding up the
> response may not be such a good idea.  Given the fluid nature of the
> boundary between OK to hold up the response and not OK, it seems useful to
> allow the same protocol to serve for both cases.

As most transfer protocols (including HTTP) do, by providing a
reasonable rich set of response semantics, but also by allowing for
response code extensions.  For example, an HTTP 202 response would
make a good response to your "queued" example above.  No need to treat
it as a transport protocol.

And BTW, the SOAP 1.2 HTTP binding does say[1] "This binding of SOAP
to HTTP is intended to make appropriate use of HTTP as an application
protocol", so I hope that continues to be the case (a quick glance
through DaveO's work suggests it is, but a "diff" document would be
nice to tell for sure).

 [1] http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#httpuse

Mark.
--
Mark Baker.  Ottawa, Ontario, CANADA.       http://www.markbaker.ca
Coactus; Web-inspired integration strategies  http://www.coactus.com

Received on Thursday, 5 January 2006 14:13:34 UTC