posted by ![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
sbisson at 09:01am on 05/07/2002
sbisson at 09:01am on 05/07/2002I'm currently sitting in the main hall at TechEd, filling in the gap between the first and second parts of Don Box's 3 part extravaganza presentation. He's talking about the problems that can arise when using web services to handle distributed computing - and thinking about the solutions...
One key point is the concept of idempotent messages: messages that can be sent many times with the same effect - so there is no difference in the result between message 1 and message n.
To explain a bit further, this can be very important if you're in the middle of a transaction and a send-action-response sequence fails to send the response, so you resend, only to trigger another instance of the action... Leaving you to deal with the consequences of send-action-send-action-send-action-response - where the response only reports the last send-action pair...
Now, the idea's clear... but the implementation? Something that could need quite a bit of thought, but one option is the obvious inclusion of a sequence header in the XML message.
One key point is the concept of idempotent messages: messages that can be sent many times with the same effect - so there is no difference in the result between message 1 and message n.
To explain a bit further, this can be very important if you're in the middle of a transaction and a send-action-response sequence fails to send the response, so you resend, only to trigger another instance of the action... Leaving you to deal with the consequences of send-action-send-action-send-action-response - where the response only reports the last send-action pair...
Now, the idea's clear... but the implementation? Something that could need quite a bit of thought, but one option is the obvious inclusion of a sequence header in the XML message.
tired
(no subject)
into a named sequence which you can then commit.
The server can then "buffer" the sequence until it's (a) contiguous (b) matches
the rules of the start of sequence message (c) gets the end sequence/commit message
...
The end sequence or start sequence would contain the "bundling" rules for any of the messages that return data, and send back a single response composed of the results bundle.
If it returns "incomplete sequence, missing x", the protocol would resend x, and
try to close the sequence again. Repeat until all sequence rules are met or until an action raises a fatal error which forces the abandoning of the sequence. This process of course would be hidden from the coder.
(no subject)
(no subject)
(no subject)
(no subject)
It's fascinating stuff. I've been having some interesting thoughts about the issues as a result of those sessions. Really made the conference for me, in fact...