This use case suggests the idea of defining an "Outstanding Activities" choreography instance designed to support recovery after a catastrophic failure. The idea is that the Outstanding Activities choreography could be used after the failure of ANY choreography and is therefore generally applicable and so will benefit from standardization.
In this example the choreography is used by a Buyer to recover the processing of an order after the Buyer suffers a system crash.
Buyer
Process |Supplier Process
1. Send PO ---------> (using a RM protocol)
2. <--------- Send PO response (using a RM protocol)
3. Buyer loses the PO response in an internal system crash !!
The Buyer then recovers from crash and, as part of the process, makes inquiries on the current state of outstanding activities then continues with the original process ...
Buyer Recover Process |Supplier Recovery
Process
1. Outstanding activities inquiry ------->
2. <------ Outstanding activities inquiry response
3. Resend outstanding PO response ------>
... continue with the original process ...
Buyer
Process |Supplier Process
4. <----------- Send PO response (using a RM protocol)
5. Buyer continues from where he left off ...
In this particular scenario the choreography that was started in #1 is
carried to completion. When the buyer fails, the buyer asks the seller
(in fact all parties it talked to before failure) to perform recovery by
indicating last messages sent. It then requests that these messages be
sent in the original context, which causes all outstanding choreographies to
proceed on schedule.
Assaf Arkin contributed to this use case.