Re: [service-orientated-architecture] Re: Orchestration, Choreography , and Composition

[Ashley at Metamaxim]

Patrick wrote:   > If the expected message sequence were A, B, C, D and message D arrived > before A, would you expect the mechanism to hold on to D until A, B, > and C arrived and were correctly processed?   > What is the window of time such a mechanism should wait? Are we > talking seconds, hours, weeks?   In priciple this problem can be solved using the following algorithm:   You need two processes: a Buffering Process (BP) and an Unbuffering Process (UP) that work together with the main process (MP) that consumes the messages.   BP receives the messages for MP as there are delivered by the environment and places them in a buffer, in order of receipt.   When MP reaches a point in its execution where it expects an input message (a "receive") it invokes UP which searches the buffer to find the earliest messsage that satisfies the "receive". It unbuffers this message and passes it to MP. MP continues execution until it reaches a "receive" for which UP is unable to find a satisfying message. MP then suspends until a new message is available in the buffer (this new message may or may not satisy the "receive" -- if the latter, UP will again not be able to find a message and MP wil suspend again).   This algorithm would hold the "D" until "A", "B", and "C" had been received and processed.   I have used an algorithm like this (albeit in a rather different context, although one that had to handle a mismatch between the order in which messages arrived and the order in which the consuming process was able to handle them) and it worked fine.   Obviously it only handles ordering problems. It would not be able to handle the situation in which, for instance, MP never reached a point where it could consume the "D". In thiscase, the "D" would remain in the buffer for ever.   Whether this approach is suitable or appropriate in the business processes context I do not know.   Rgds Ashley   ----- Original Message ----- From: patrickdlogan To: service-orientated-architecture@yahoogroups.com Sent: Tuesday, July 25, 2006 12:39 AM Subject: [service-orientated-architecture] Re: Orchestration, Choreography , and Composition > There is an orthogonal discussion about how additional runtime QoS > help to make orchestrations fit together: E.g. reliable messaging > may buffer message B at site of P4 until message A is consumed by P4 > and then pass B to P4 etc etc. That's neither "reliable messaging" nor "quality of service" according to any definitions I am aware of. That seems more like "prescient messaging". How would the mechanism doing message ordering know to do this? Why would that mechanism not consider the arrival of B before A an error in the first place? If the expected message sequence were A, B, C, D and message D arrived before A, would you expect the mechanism to hold on to D until A, B, and C arrived and were correctly processed? What is the window of time such a mechanism should wait? Are we talking seconds, hours, weeks? -Patrick __._,_.___ SPONSORED LINKS Computer software Computer security software Computer software program Computer fax software Computer virus software Discount computer software YAHOO! GROUPS LINKS  Visit your group "service-orientated-architecture" on the web.    To unsubscribe from this group, send an email to:  [EMAIL PROTECTED]    Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. __,_._,___