Re: REST, Conversations and Reliability

David Orchard wrote:
> 
> I finally got around to this important proposal, apologies for the delay.

Ditto.

>...
> 
> On another easy one that's web architecture related, the conversation ID
> should be a URI, and probably an http: uri as per the work in the TAG.
> There is always the danger - just like namespaces names - that people will
> try to do something like a GET on an HTTP URI (as opposed to an HTTP URL),
> because you can't tell from an HTTP URI whether it's an identifier or a
> locator.  I think that's an issue that the TAG should be thinking about, but
> there's enough discussion going on about the range of http: currently :-)

Well-thought-out, public HTTP URIs are by definition both identifiers
and locators. The Web would come crashing to a halt if this were not the
case. 

http://lists.xml.org/archives/xml-dev/200208/msg00748.html
http://lists.xml.org/archives/xml-dev/200208/msg00759.html

And of course a central advantage of the REST proposal is that GET on a
conversation ID URI *should* return something useful to help a "lost" or
new participant realign themselves with the state of the conversation.

> Now the tricky bits.
> 
> 1. I was really surprised when you didn't suggest that the receiver should
> suggest a new "Content-Location" that incorporated the conv-id into the URL
> for receiver assigned.  foo.com/bar?cid=5532.  And sender assigned callbacks
> could have been bar.com/foo?cid=2238.  I have reasons for why we didn't do
> that, but I thought you were going to suggest it...  That seems like the
> most RESTful solution, everything needed to address the conversational
> resource in a URI.

I feel the right header is "Location", not "Content-Location". Otherwise
I agree. I wouldn't use the term "incorporated the conv-id" because I
think that the URI *is* the conversation ID. I don't yet feel there is a
need for an ID separate from the URI.

> 2. In general, the problem with your proposal is that it combines the logic
> of the application with the logic of the reliability (message ordering) and
> conversations.  

We've discussed this at length. Waldo says that application logic cannot
be separated from issues of failure. I agree with him. As I understand
it, you think that it is sufficient for the application to "know" that
it is dealing with a network without incorporating specific business
logic for handling failures. I think that this is incorrect.

> 4. There's a huge missing problem with your reliability proposal: it's
> missing all of the information about how to deal with messages that are
> transferred, or not transferred.  

If I recall
correctly, your orginal proposal did not deal with reliability at all
(not even by reference). Therefore I pointed out how my extensions to it
would improve reliability *compared to what you had described*. Not
compared to an as-yet undefined reliability solution that will undergird
the conversation ID system. I didn't mean to claim that my changes to
your protocol were sufficient to build fully reliable systems: just
*more* reliable systems than your protocol alone. 

I believe that I could prove that the REST version is strictly more
reliable than the pure-SOAP version. But whether it is reliable in
general ... it depends upon whether the conversation ID protocol concept
promotes reliability...my instinct is that it does not.

If I were setting out to solve a new problem I would probably not use a
"conversation ID" architecture whether it is REST-amended or not.
Basically the problem is that conversations and messages should not be
the things that services are talking *about* but only the things
services talk *with*. So for instance you ask: "how will you know if
message Y was received" but I don't care. I care about whether Purchase
Order XYZZY was received. And I can answer that question with a simple
GET to its URI. If it is there it was received (unless it was
subsequently deleted which doesn't make sense in this context). That is
the difference between reliable messaging and reliable systems built on
unreliable messaging. If the server has the state I want then I am
happy, whether 1 or 10 copies of a message got through. Ensuring that
the server gets the right state when 1 or 10 messages gets through is
feasible through proper resource design.

When you put your conversation ID proposal together with an application
protocol and a reliability proposal to solve some particular problem
then we can compare to a unified REST solution to the same problem. But
until then, my REST proposal is just an incremental improvement, not a
fix for all of the issues raised by the conversation ID paradigm.

> What's the result of the "GET" against the 
> conversation ID?   

If the conversation is about purchase orders then GET returns a list of
purchase orders.
If the conversation is an IM chat then the GET returns a scrolling log
of the discussion.
etc. etc.

In other words I think that instead of having first-class
"conversations" I would have collections of resources of types
applicable to my problem domain.

> ... There would need to be a format to specify states, (I've
> received msgs with ids x and z, in that order).   I see a whole outcomes
> exchange protocol appearing.  So the graph of state transitions/messages
> needs to be defined.  On both sides (I've sent msgs with ids x, y, z).  Your
> reliablity suggestion means that the components in a conversation would have
> to track all the messages they had ever received or sent.  

No, the list of messages sent or received is not important. The state of
resources is interesting.

> .... Imagine A sends
> x,y,z to B.  Let's say the y gets lost, but A doesn't know it (asynch
> request).  

A should not send "z" which depends on "y" unless it can guarantee that
"y" got through. HTTP (for example) disallows this explicitly. Any
application that depends upon this will be unreliable!

> ... It seems like
> they actually doing a distributed transaction, in that A and B are trying to
> synchronize the states of the messages that they got.  A and B have to know
> everything about the allowable and the actual message exchanges, right in
> the application protocol.  This doesn't seem simpler than defining an
> acknowledgement protocol with varying qualities of service and configurable
> parameters.

We're trying to compare something concrete with something that has not
yet been formally proposed (a "reliable acknowledgment protocol with
...."). I can't yet say whether it will be simpler or not. I am
confident that having the application keep track of which messages were
received or not will result in more reliable applications that handle
partial failure better. I think that's the most important thing. Because
REST applications (in practice) use HTTP, you can offload many of these
issues to standardized libraries that work across problem domains. But
you can only presume that the libraries will handle boring stuff like
retries and checking state. The app has to handle the failure logic.
--

Received on Friday, 16 August 2002 21:58:35 UTC