> 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
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/